新版本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。
