優化網站設計（十一）：避免重定向

前言

網站設計的優化是一個很大的話題,有一些通用的原則,也有針對不一樣開發平臺的一些建議。這方面的研究一直沒有中止過，我在不一樣的場合也分享過這樣的話題。

做爲通用的原則，雅虎的工程師團隊曾經給出過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的機制來定義別名，而不是強制地重定向來實現