Response.Redirect(),Server.Transfer(),Server.Execute()的區別與網站優化

時間 2020-09-12

標籤 response.redirect response redirect server.transfer server transfer server.execute execute 區別網站優化欄目網站開發简体版

原文原文鏈接

一、Response.Redirect():
Response.Redirect方法致使瀏覽器連接到一個指定的URL。當Response.Redirect()方法被調用時，它會建立一個應答，應答頭中指出了狀態代
碼302（表示目標已經改變）以及新的目標URL。瀏覽器從服務器收到該應答，利用應答頭中的信息發出一個對新URL的請求。

這就是說，使用Response.Redirect方法時重定向操做發生在客戶端，總共涉及到兩次與服務器的通訊（兩個來回）：第一次是對原始頁面html

的請求，獲得一個302應答，第二次是請求302應答中聲明的新頁面，獲得重定向以後的頁面。web

二、Server.Transfer

Server.transfer是IIS 5.0新增長的一個功能。它解決了
Response.Redirect的兩個重要的缺陷：
1）在Response.Redirect中，咱們得不到任何第一頁的輸出
2）Response.Redirect會丟失request中的全部屬性，固然咱們能夠經過一些其餘的辦
法，好比session來搞定，但是，有些頁的參數是在request中傳過來的，這樣的話，就不行了
3) Response.Redirect須要client端再發起一個請求。
server.transfer就很好地解決了這些問題。它是從server端直接向下一頁發起請求，不須要client再次發送請求.
若是你的網頁很是依賴response.redirect,這個小小的改變能夠提升將近25%的效率。（根據微軟文檔）.chrome

Server.Transfer方法把執行流程從當前的ASPX文件轉到同一服務器上的另外一個ASPX頁面。調用Server.Transfer時，當前的ASPX頁面終止數據庫

執行，執行流程轉入另外一個ASPX頁面，但新的ASPX頁面仍使用前一ASPX頁面建立的應答流。

若是用Server.Transfer方法實現頁面之間的導航，瀏覽器中的URL不會改變，由於重定向徹底在服務器端進行，瀏覽器根本不知道服務器api

已經執行了一次頁面變換。

默認狀況下，Server.Transfer方法不會把表單數據或查詢字符串從一個頁面傳遞到另外一個頁面，但只要把該方法的第二個參數設置成True瀏覽器

，就能夠保留第一個頁面的表單數據和查詢字符串。

同時，使用Server.Transfer時應注意一點：目標頁面將使用原始頁面建立的應答流，這致使ASP.NET的機器驗證檢查（Machine服務器

Authentication Check，MAC）認爲新頁面的ViewState已被篡改。所以，若是要保留原始頁面的表單數據和查詢字符串集合，必須把目標頁面網絡

Page指令的 EnableViewStateMac屬性設置成False。session

server.Transfer()有一個不足就是:當用戶在a.aspx中提交了一個表單,而後用Server.Transfer()進入 b.aspx，這時若是用戶刷新一下頁面，app

瀏覽器便會問用戶是否「重試」發送表單，若是用戶點擊「是」，那麼，表單中的數據被從新發送到服務器。如發送表單的做用就是爲了向數

據庫中插入一條記錄，結果導不但願發生的事——同一表單被屢次加入到數據庫中。

三、Server.Execute

Server.Execute方法容許當前的ASPX頁面執行一個同一Web服務器上的指定ASPX頁面，當指定的ASPX頁面執行完畢，控制流程從新返回原頁

面發出Server.Execute調用的位置。

這種頁面導航方式相似於針對ASPX頁面的一次函數調用，被調用的頁面可以訪問發出調用頁面的表單數據和查詢字符串集合，因此要把被

調用頁面Page指令的EnableViewStateMac屬性設置成False。

4.
erver.Execute("another.aspx")和Server.Transfer("another.aspx")區別:
Execute是從當前頁面轉移到指定頁面,並將執行返回到當前頁面
Transfer是將執行徹底轉移到指定頁面

總結：
在網絡狀態較好的狀況下,Redirect(url)方法效率最高!! 可重定向到同一臺或非同一臺服務器上的aspx或非aspx（html）資源
Server.Transfer方法和Server.Execute方法最靈活!! 但只能轉到同一Application目錄下，也有可能致使不指望的結果發生
Server.Execute方法佔用資源最多.

前言

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

做爲通用的原則，雅虎的工程師團隊曾經給出過35個最佳實踐。這個列表請參考 Best Practices for Speeding Up Your Web Site http://developer.yahoo.com/performance/rules.html，同時，他們還發布了一個相應的測試工具Yslow http://developer.yahoo.com/yslow/

我強烈推薦全部的網站開發人員都應該學習這些最佳實踐，並結合本身的實際項目狀況進行應用。接下來的一段時間，我將結合ASP.NET這個開發平臺，針對這些原則，經過一個系列文章的形式，作些講解和演繹，以幫助你們更好地理解這些原則，而且更好地使用他們。

準備工做

爲了跟隨我進行後續的學習，你須要準備以下的開發環境和工具

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鍵調出這個工具。
Visaul Studio 2010 SP1 或更高版本，推薦使用Visual Studio 2012
1. http://www.microsoft.com/visualstudio/eng/downloads
你須要對ASP.NET的開發基本流程和核心技術有至關的瞭解，本系列文章很難對基礎知識作普及。

本文要討論的話題

這一篇我和你們討論第十一條原則：Avoid Redirects （避免重定向）。

重定向的意思是，用戶的原始請求（例如請求A）被重定向到其餘的請求（例如請求B）。這是HTTP世界中原本就存在的技術和現象，它自己沒有所謂的好和壞，它的存在也確實有其理由，爲此HTTP協議中，規定了兩個狀態碼來標識這種場景。它們分別是：

301 Moved Permanently , 這個狀態碼標識用戶所請求的資源被移動到了另外的位置，客戶端收到此響應後，須要發起另一個請求去下載所需的資源。這個狀態碼，往後可能會和另一個狀態碼 308 （308 Permanent Redirect (approved as experimental RFC)^[12]）有些關聯（這個尚未最終肯定爲標準）
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 。

重定向是如何發生的

事實上，重定向是常常發生的。有兩種主要的狀況下會發生重定向

服務器自己的一些行爲（針對某類請求）
程序中明確地作了重定向

第一種狀況頗有意思，不一樣的服務器可能在處理的時候表現也是不同的。例如咱們來看下面這個請求

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 有以下幾種方式來作重定向

Response.Redirect http://msdn.microsoft.com/EN-US/library/08za4s98(v=VS.110,d=hv.2).aspx

這個會進行臨時重定向，也就是返回302

Response.RedirectPermanent http://msdn.microsoft.com/EN-US/library/dd322058(v=VS.110,d=hv.2).aspx （這是新增的方法）

這個會進行永久性重定向，也就是返回301

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.