优化网站设计（十一）：避免重定向

前言

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

做为通用的原则，雅虎的工程师团队曾经给出过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属性的时候，尽可能使用最完整的、直接的地址。例如
   • 使用www.cnblogs.com 而不是cnblogs.com
   • 使用cn.bing.com 而不是bing.com
   • 使用www.google.com.hk 而不是google.com
   • 使用www.mysite.com/products/ 而不是 www.mysite.com/products
2. 在使用Response.Redirect的时候，设置第二个参数为false
   • 考虑是否可用Server.Execute代替
   • 考虑Respone.RedirectPermanent
3. 若是涉及到从测试环境到生产环境的迁移，建议经过DNS中的CNAME的机制来定义别名，而不是强制地重定向来实现