新版本URL-rewrite module for IIS 7.0的發(fā)布了，ASP.NET Routing組件隨著.NET Framework 3.5 SP1的發(fā)布，并在.NET Framework 4.0 Beta中進(jìn)一步成熟。作為ASP.NET 開發(fā)人員，我們不免會對這兩個功能相近的組件抱有許多疑問，諸如“它們有什么異同？”“分別適用于什么環(huán)境？”等等。本文旨在描述這兩者之間的異同，并為開發(fā)人員提供什么時候使用哪一種解決方案的建議。

　　從表面上看來，這兩種技術(shù)似乎提供了非常相似的功能：為網(wǎng)站提供用戶友好的、搜索引擎友好的Url。然而，在這兩種技術(shù)在原理上卻有著本質(zhì)的區(qū)別，需要深入理解才能在選擇應(yīng)用時做出正確的決策。為了幫助大家理解這兩種技術(shù)，我們首先從他們的運作原理開始講起。

　　本文翻譯自IIS官方網(wǎng)站，針對國內(nèi)慣用的術(shù)語進(jìn)行了部分調(diào)整。

　　URL重寫(URL Rewriting)

　　URL Rewriting已經(jīng)不是什么新技術(shù)了，大約在10年前就已經(jīng)在Apache服務(wù)器上廣泛應(yīng)用。由于它被公認(rèn)為是web管理員和開發(fā)人員的法寶，許多流行的基于Apache的網(wǎng)站都依賴于Url重寫來提供“優(yōu)雅”的Url。

　　簡單的說，URL重寫的理念非常簡單：當(dāng)一個客戶端向服務(wù)端請求一個特定的URL時，URL重寫模塊會分析所請求的URL并把請求更改，指向同一Web服務(wù)器上的另一個URL。在web請求周期中插入URL重寫模塊（如通過HttpModule）非常簡單，所以，它能夠在服務(wù)器處理請求之前來修改所請求的URL。而服務(wù)端的處理程序會根據(jù)重寫后的URL來生成一個Response到客戶端瀏覽器。由于重寫過程發(fā)生在服務(wù)端，所以客戶端瀏覽器根本看不到重寫后的URL，在客戶端看來，他所收到的Response來自原來所請求的URL。

　　在IIS 7.0的架構(gòu)中，這個過程可以由下圖來展示：

　　微軟所提供的URL重寫模塊(URL-rewrite module)是一個native-code的模塊，插入web請求處理過程的Pre-begin Request 或 Begin Request 階段，然后通過所配置的一系列重寫規(guī)則來進(jìn)行URL重寫。每一個重寫規(guī)則對URL進(jìn)行正則分析，判斷是否當(dāng)前所請求的URL滿足重寫規(guī)則所定義的條件，如果滿足，就根據(jù)規(guī)則將原來的URL重寫成一個新的URL。當(dāng)所有的重寫規(guī)則都過了一遍之后，URL重寫模塊會生成一個最終的URL路徑，傳遞給剩余的請求處理過程。也就是說IIS管道中的請求處理程序所處理的是在URL重寫模塊所寫后的URL。

　　ASP.NET路由(ASP.NET Routing)

　　從本質(zhì)上來說，ASP.NET路由是一種請求調(diào)度機(jī)制，它允許開發(fā)者將符合指定規(guī)則的URL關(guān)聯(lián)給一個能夠處理這個請求的Handler來進(jìn)行處理。這種關(guān)聯(lián)通過注冊定義了URL映射關(guān)系的“Routes”來完成。當(dāng)一個請求到達(dá)服務(wù)端時，ASP.NET路由模塊會查找已經(jīng)注冊的Routes表，如果匹配到了某個Route，那么Route相應(yīng)的Handler就會被調(diào)用來處理這個請求。

　　在IIS 7.0的架構(gòu)中，這個過程可以由下圖來展示：

　　ASP.NET路由是由托管代碼來實現(xiàn)的，作為插件嵌入到IIS請求處理管道的Resolve Cache步驟(PostResolveRequestCache 事件)和Map Handler 步驟(PostMapRequestHandler)中。ASP.NET路由會被配置為對Web Application全局的請求都生效。

　　在PostResolveRequestCache事件過程中，路由模塊會查找一個路由表（一個route對象的集合），來查找匹配所請求URL的Route。如果找到了匹配的Route，ASP.NET路由模塊會獲取一個處理這個Route的handler，并把這個handler的引用保存到當(dāng)前的HttpContext中去。當(dāng)然，這個handler可以是實現(xiàn)了System.Web.IHttpHandler接口的任何類（比如Page類）。如果沒能夠找到匹配的Route，那么ASP.NET路由模塊就什么也不做，任由這個請求走完剩下的處理過程（通常會映射到一個硬盤文件如XX.ASPx）。

　　在PostMapRequestHandler事件過程中，路由模塊會檢查當(dāng)前的HttpContext是否包含一個handler的信息，如果有的話，ASP.NET路由模塊就會把當(dāng)前HttpContext的Handler屬性設(shè)置成所找到的handler。這樣就讓IIS在Execute Handler步驟中執(zhí)行路由模塊所選中的handler。如果沒有的話，ASP.NET路由模塊就什么也不做，讓IIS來選擇一個handler處理這個URL請求。

　　URL 重寫和ASP.NET 路由的區(qū)別

　　基于上面的說明，我們可以看出，URL重寫和ASP.NET路由在概念上的差別有如下幾點：

1. URL重寫用來在Web服務(wù)器處理請求之前處理URL。URL重寫模塊不知道究竟什么handler會被用來處理重寫后的URL，相同，這個最終的handler也不知道這個URL是否被重寫過了。
2. ASP.NET路由用來根據(jù)URL來為一個請求指派相應(yīng)的處理程序（handler），與URL重寫相反，路由組件知道相關(guān)的handler，并且親自選擇handler來處理所請求的URL。鑒于此點，我們也可以把ASP.NET路由想作是一個高級的處理映射(handler-mapping)機(jī)制。

　　除了概念上的差別，URL重寫和ASP.NET路由在功能上也有如下幾點差別：

1. IIS URL重寫模塊可以用于任何類型的web應(yīng)用程序，包括ASP.NET, php, ASP甚至靜態(tài)文件。而ASP.NET路由則只能處理基于.NET Framework的web應(yīng)用程序。
2. IIS URL重寫模塊在集成（integrated）和經(jīng)典（classic） IIS管道模式的應(yīng)用程序池中的運行是一樣的。而ASP.NET路由則偏向于應(yīng)用集成（integrated）管道模式。ASP.NET路由也可以在經(jīng)典（classic） 模式下運行，但這時程序中的URL必須包含文件擴(kuò)展名，或者程序在IIS中必須配置一個”*”的handler映射。
3. URL重寫模塊可以通過域名、Http頭信息、服務(wù)器變量來決定是否進(jìn)行重寫。而默認(rèn)的情況下，ASP.NET路由只能通過URL路徑和Http頭信息中的HTTP-Method信息來決定是否進(jìn)行路由。
4. 除了URL重寫，IIS URL重寫模塊還可以來做HTTP跳轉(zhuǎn)、設(shè)置自定義的IIS狀態(tài)代碼，甚至終止請求。而ASP.NET路由不能做這些。
5. IIS URL重寫模塊在目前的版本中是不能擴(kuò)展的，而ASP.NET路由則是完全可擴(kuò)展、可定制的。

　　我們該如何選擇?

　　知道了這些異同，我們應(yīng)該怎樣在應(yīng)用中挑選合適的URL優(yōu)化方案呢？我們將在下節(jié)中來探討。

NET技術(shù)：IIS URL Rewriting 和 ASP.NET routing（上），轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。