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

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

　　本文翻譯自IIS官方網站，針對國內慣用的術語進行了部分調整。

　　URL重寫(URL Rewriting)

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

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

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

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

　　ASP.NET路由(ASP.NET Routing)

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

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

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

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

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

　　URL 重寫和ASP.NET 路由的區別

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

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

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

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

　　我們該如何選擇?

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