优化网站设计(十一):避免重定向

前言

网站设计的优化是一个很大的话题,有一些通用的原则,也有针对不同开发平台的一些建议。这方面的研究一直没有停止过,我在不同的场合也分享过这样的话题。

作为通用的原则,雅虎的工程师团队曾经给出过35个最佳实践。这个列表请参考  Best Practices for Speeding Up Your Web Site  http://developer.yahoo.com/performance/rules.html,同时,他们还发布了一个相应的测试工具Yslowhttp://developer.yahoo.com/yslow/

我强烈推荐所有的网站开发人员都应该学习这些最佳实践,并结合自己的实际项目情况进行应用。 接下来的一段时间,我将结合ASP.NET这个开发平台,针对这些原则,通过一个系列文章的形式,做些讲解和演绎,以帮助大家更好地理解这些原则,并且更好地使用他们。

准备工作

为了跟随我进行后续的学习,你需要准备如下的开发环境和工具

  1. Google Chrome 或者firefox ,并且安装 Yslow这个扩展组件.请注意,这个组件是雅虎提供的,但目前没有针对IE的版本。
    1. https://chrome.google.com/webstore/detail/yslow/ninejjcohidippngpapiilnmkgllmakh
    2. https://addons.mozilla.org/en-US/firefox/addon/yslow/
    3. 你应该对这些浏览器的开发人员工具有所了解,你可以通过按下F12键调出这个工具。
  2. Visaul Studio 2010 SP1 或更高版本,推荐使用Visual Studio 2012
    1. http://www.microsoft.com/visualstudio/eng/downloads
  3. 你需要对ASP.NET的开发基本流程和核心技术有相当的了解,本系列文章很难对基础知识做普及。

本文要讨论的话题

这一篇我和大家讨论第十一条原则:Avoid Redirects (避免重定向)。

重定向的意思是,用户的原始请求(例如请求A)被重定向到其他的请求(例如请求B)。这是HTTP世界中本来就存在的技术和现象,它本身没有所谓的好和坏,它的存在也确实有其理由,为此HTTP协议中,规定了两个状态码来标识这种场景。它们分别是:

  1. 301 Moved Permanently , 这个状态码标识用户所请求的资源被移动到了另外的位置,客户端收到此响应后,需要发起另外一个请求去下载所需的资源。这个状态码,日后可能会和另外一个状态码 308 (308 Permanent Redirect (approved as experimental RFC)[12])有些关联(这个还没有最终确定为标准)
  2. 302 Found ,这个状态码标识用户所请求的资源被找到了,但不在原始位置,服务器会回复其他的一个地址,客户端收到此响应后,也需要发起另外一个请求去下载所需的资源。这个状态码,日后可能会和另外两个状态码有关联。
    • 303 See Other (since HTTP/1.1)
    • 307 Temporary Redirect (since HTTP/1.1)

目前,我们一直只要区分301和302即可。它们本质上的区别到底是什么呢?其实也不难:301表示永久重定向,302表示临时重定向。对于一般的用户而言,可能你还无法体会出来他们的区别,因为横竖都是要重定向的。但对于搜索引擎而言意义就非凡。我们都知道,搜索引擎是需要不定期对网站资源进行爬网,以便完善对应的索引结构的。当某个资源被永久重定向(301),搜索引擎会聪明地知道,在索引中应该记录就是永久重定向之后的新地址,而不是老地址,这样就可以避免用户通过搜索引擎来查询的时候,每次还需要先到老地址,再重定向到新地址。而对于临时重定向(302),则不会这么做。

 

重定向会有什么影响

说了这么多理论知识,我们还是通过一个实例来看看具体重定向是如何发生的吧

我们首先请求的是default.aspx页面,出于某种原因,这个请求需要被重定向到另外一个页面,Product.aspx。所以,服务器首先为default.aspx这个请求返回302的状态码,表示说这里需要临时重定向。然后,在响应的头部(Header)中,还包含了新的地址:Product.aspx。(如下图所示)。在响应的正文(Body)中,则是空白的。

浏览器收到了这个回复之后,再重新发起一个请求,Product.aspx,这个请求被正常地处理了,返回200的状态码。

事情就是这样。这样的问题在于:这样做显然增加了浏览器到服务器的往返次数,这违背了另外一个原则:Make Fewer HTTP Requests 。

 

重定向是如何发生的

事实上,重定向是经常发生的。有两种主要的情况下会发生重定向

  1. 服务器本身的一些行为(针对某类请求)
  2. 程序中明确地做了重定向

第一种情况很有意思,不同的服务器可能在处理的时候表现也是不一样的。例如我们来看下面这个请求

http://cnblogs.com

通过监控我们发现,首先会有一个301的重定向,然后才是真正的请求(返回200),此时地址是 http://www.cnblogs.com

这是为什么呢?如果有网站开发经验的朋友一定知道,域名都是需要解析的,实际上向用户提供的服务,是互联网上面的某个网络主机。做得比较好的网站,同时会考虑用户希望访问网站的不同的方式,上例中,用户既可以访问cnblogs.com 也可以访问www.cnblogs.com,区别在于前者多一次重定向请求。

 

如果你就此认为是理所应当的,那么你就错了。我们再来看一下“著名”的12306.cn 吧

你如果这样访问的时候,直接就失败了。你必须完整地输入www.12306.cn 才能访问。试问,这是多么简单、低级的问题。

其实要做到这个很简单,牺牲了一点点性能,对于用户来说,提高了用户体验。这里留一个疑问:有人可以解释一下,到底如何实现这样的效果(cnblogs.com => www.cnblogs.com )吗?

这是一种典型的重定向,这个无需任何代码就能实现。实际上是属于服务器的功能。当然,我们完全应该尽可能地使用www.cnblogs.com 这种方式(例如给人们邮件中的链接,尽量是使用这个路径)。但提供了另外一个方式,是很好的设计。

 

还有一种典型的重定向,我们来看下面这个例子,请在浏览器中输入google.com

我们最终看到的页面是 http://www.google.com.hk/

你会发现,会有几次重定向

第一次重定向是301,从google.com 重定向到www.google.com

第二次重定向是302,从www.google.com 重定向到 http://www.google.com.hk/url?sa=p&hl=zh-CN&pref=hkredirect&pval=yes&q=http://www.google.com.hk/&ust=1367722843791916&usg=AFQjCNEzkTX2uE5Jlo3NkA1vSHdwoCnnZQ

第三次重定向是302,从http://www.google.com.hk/url?sa=p&hl=zh-CN&pref=hkredirect&pval=yes&q=http://www.google.com.hk/&ust=1367722843791916&usg=AFQjCNEzkTX2uE5Jlo3NkA1vSHdwoCnnZQ 重定向到http://www.google.com.hk

 

同样的做法,我们从bing.com中也能看到。我们输入bing.com ,但实际看到的页面是cn.bing.com

实际上,这里也发生了一次重定向

 

为什么Google和Microsoft都会这样设计搜索引擎的主界面呢?原因在于他们想给用户提供更加有个性化的本地服务,所以针对不同国家和地区的用户,实际上有独立的主机来进行处理。

Microsoft的做法有点不一样,他们使用了统一的域名bing.com,只是为不同的国家和地区准备了不同的主机,例如cn.bing.com, hk.bing.com 。

 

还有一种容易比我们忽视的重定向。请参考下面的实例

在这个示例网站中,有一个文件夹,叫做Products,里面会有很多页面,例如至少会有一个Default.aspx。我们都知道,通常Default.aspx是所谓的默认页面,也就是说,要访问这个页面的话,并不需要输入Default.aspx这个部分,而是直接通过访问文件夹名称即可,例如下面这样

http://localhost:9071/Products

和你想象的一样,这样的简写路径会返回Products目录中的Default.aspx页面的内容(这很不错,对吧)但是,通过监控我们发现,这样一个请求都会发生了一次重定向

有意思的是,它会将地址重定向到 http://localhost:9071/Products/ (只是比原始地址多了一个路径斜线),很神奇吗?但这是真的,凡是访问地址中,没有带文件名后缀的(例如aspx,asp等等),服务器都会尝试解析为一个文件夹,自动加上一个路径斜线,然后再查找内部的默认页面。

【备注】这个行为,在ASP.NET MVC中是不会存在的,因为ASP.NET MVC的请求处理是被路由处理的。

 

ASP.NET中的重定向

如果上述网站是用ASP.NET开发的(cnblogs.com 显然是的,而Google.com则显然不是的,bing.com 会是的吗?),那么会怎么样来实现上述所提到的重定向呢?

ASP.NET 4.0 有如下几种方式来做重定向

  1. Response.Redirect  http://msdn.microsoft.com/EN-US/library/08za4s98(v=VS.110,d=hv.2).aspx 
    • 这个会进行临时重定向,也就是返回302
  2. Response.RedirectPermanent http://msdn.microsoft.com/EN-US/library/dd322058(v=VS.110,d=hv.2).aspx (这是新增的方法)
    • 这个会进行永久性重定向,也就是返回301
  3. Server.Transfer http://msdn.microsoft.com/EN-US/library/y0w8173d(v=VS.110,d=hv.2).aspx
    • 这个不会产生301,也不会产生302,实际上,它直接返回200,浏览器根本不会知道发生了重定向,不会有多出来的一个请求
      • 听起来不错,不是吗?那么,请问,这样做有什么附加的问题吗

 

ASP.NET中重定向附加的问题

 

以上的三个方法,我相信大家至少对其中一两个很熟悉,但是很多人不清楚他们的代价。

实际上,不管是用Redirect还是Transfer方法,他们内部都会调用Response.End方法(这个很好理解,因为需要重定向了,所以当前的这个请求应该就不需要再提供响应了),但这个方法会导致与该请求有关的处理线程强制被中断掉,具体来说,这将引发一个异常(ThreadAbortException),通过Try…catch就能捕捉到。

我们都知道,异常处理在.NET中是由CLR来做的,异常处理的代价是较高的,所以如果过于频繁地抛出异常,会给性能带来显著的影响。

关于这个问题,以及如何改善,可以参考微软官方的文档

http://support.microsoft.com/kb/312629/en-us

我摘录解决方案的部分如下

To work around this problem, use one of the following methods:

  • For Response.End, call the HttpContext.Current.ApplicationInstance.CompleteRequest method instead of Response.End to bypass the code execution to the Application_EndRequest event.
  • For Response.Redirect, use an overload, Response.Redirect(String url, bool endResponse) that passes false for theendResponse parameter to suppress the internal call to Response.End. For example:

     

      Response.Redirect ("nextpage.aspx", false);
    						

    If you use this workaround, the code that follows Response.Redirect is executed.

  • For Server.Transfer, use the Server.Execute method instead.

 

如何尽可能避免重定向

从上面的实例和分析来看,重定向是无法完全避免的,适当地使用重定向能为网站提供更好的功能。(例如本地化,用户体验等方面)。

但是过多地进行重定向也肯定会给网站性能带来显著的影响。那么,有哪些方法可以作为我们改善这一点的参考呢

  1. 在定义链接地址的href属性的时候,尽量使用最完整的、直接的地址。例如
  2. 在使用Response.Redirect的时候,设置第二个参数为false
    • 考虑是否可用Server.Execute代替
    • 考虑Respone.RedirectPermanent
  3. 如果涉及到从测试环境到生产环境的迁移,建议通过DNS中的CNAME的机制来定义别名,而不是强制地重定向来实现

优化网站设计(十一):避免重定向,古老的榕树,5-wow.com

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。