IIS 7.0與ASP.NET

IIS 7.0在請求的監聽和分發機制上又進行了革新性的改進，主要體現在對于Windows進程激活服務（Windows Process Activation Service，WAS）的引入，將原來（IIS 6.0）W3SVC承載的部分功能分流給了WAS。通過上面的介紹，我們知道對于IIS 6.0來說W3SVC主要承載著3大功能。

HTTP請求接收：接收HTTP.SYS監聽到的HTTP請求。

配置管理：從元數據庫（Metabase）中加載配置信息對相關組件進行配置。

進程管理：創建、回收、監控工作進程。

IIS 7.0將后兩組功能實現到了WAS中，接收HTTP請求的任務依然落在W3SVC頭上。WAS的引入為IIS 7.0提供了對非HTTP協議的支持。WAS通過監聽器適配器接口（Listener Adapter Interface）抽象出不同協議監聽器。具體來說，除了基于網絡驅動的HTTP.SYS提供HTTP請求監聽功能外還提供了TCP監聽器、命名管道監聽器和MSMQ監聽器以提供基于TCP、命名管道和MSMQ傳輸協議的監聽支持。

與此3種監聽器相對的是3種監聽適配器，它們提供監聽器與WAS中的監聽器適配器接口之間的適配。從這個意義上講，IIS 7.0中的W3SVC更多地為HTTP.SYS起著監聽適配器的作用。這3種非HTTP監聽器和監聽適配器定義在程序集SMHost.exe中，我們可以在目錄%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\中找到它們。

WCF提供的這3種監聽器和監聽適配器最終以Windows 服務的形式體現。雖然它們定義在一個程序集中，我們依然可以通過服務工作管理器對其進行單獨的啟動、終止和配置。SMHost.exe提供了4個重要的Windows Service。

NetTcpPortSharing：為WCF提供TCP端口共享。關于端口共享在WCF中的應用，本人拙著《WCF全面解析》（上冊）對此有詳細的介紹。

NetTcpActivator：為WAS提供基于TCP的激活請求，包含TCP監聽器和對應的監聽適配器。

NetPipeActivator：為WAS提供基于命名管道的激活請求，包含命名管道監聽器和對應的監聽適配器。

NetMsmqActivator：為WAS提供基于MSMQ的激活請求，包含MSMQ監聽器和對應的監聽適配器。

圖1-7為上述的4個Windows 服務在服務控制管理器中的呈現。

圖1-8揭示了IIS 7.0的整體構架及整個請求處理流程。無論是從W3SVC接收到的HTTP請求，還是通過WCF提供的監聽適配器接收到的請求，最終都會傳遞到WAS。如果相應的工作進程（或者應用程序池）尚未創建，則創建它，否則將請求分發給對應的工作進程進行后續的處理。WAS在進行請求處理過程中，通過內置的配置管理模塊加載相關的配置信息，并對相關的組件進行配置。與IIS 5.x和IIS 6.0基于Metabase的配置信息存儲不同的是，IIS 7.0大都將配置信息存放于XML形式的配置文件中，基本的配置存放在applicationHost.config中。

ASP.NET集成

從上面對IIS 5.x和IIS 6.0的介紹中，我們不難發現IIS與ASP.NET是兩個相互獨立的管道（Pipeline）。在各自管轄范圍內，它們各自具有自己的一套機制對HTTP請求進行處理。兩個管道通過ISAPI實現“連通”，IIS是第一道屏障，當對HTTP請求進行必要的前期處理（比如身份驗證等）時，通過ISAPI將請求分發給ASP.NET管道。當ASP.NET在自身管道范圍內完成對HTTP請求的處理時，處理后的結果再返回到IIS，IIS對其進行后期處理（比如日志記錄、壓縮等），最終生成HTTP響應。圖1-9反映了IIS 6.0與ASP.NET之間的橋接關系。

從另一個角度講，IIS運行在非托管的環境中，而ASP.NET管道則是托管的，ISAPI還是連接非托管環境和托管環境的紐帶。IIS 5.x和IIS 6.0把兩個管道進行隔離至少帶來了下面的一些局限與不足：

相同操作的重復執行：IIS與ASP.NET之間具有一些重復的操作，比如身份驗證。

動態文件與靜態文件處理的不一致：因為只有基于ASP.NET動態文件（比如.aspx、.asmx、.svc等）的HTTP請求才能通過ASP.NET ISAPI進入ASP.NET管道，而對于一些靜態文件（比如.html、.xml、.img等）的請求則由IIS直接響應，那么ASP.NET管道中的一些功能將不能用于這些基于靜態文件的請求，比如我們希望通過Forms認證應用于基于圖片文件的請求就做不到。

IIS難以擴展：對于IIS的擴展基本上就體現在自定義ISAPI，但是對于大部分人來說，這不是一件容易的事情。因為ISAPI是基于Win32的非托管的API，并非一種面向應用的編程接口。通常我們希望的是諸如定義ASP.NET的HttpModule和HttpHandler一樣，通過托管代碼的方式來擴展IIS。

對于Windows平臺下的IIS來講，ASP.NET無疑是一等公民，它們之間不應該是“井水不犯河水”，而應該是“你中有我，我中有你”的關系，為此在IIS 7.0中實現了兩者的集成，通過集成可以獲得如下的好處。

允許通過本地代碼（Native Code）和托管代碼（Managed Code）兩種方式定義IIS Module，這些IIS Module注冊到IIS中形成一個通用的請求處理管道。由這些IIS Module組成的這個管道能夠處理所有的請求，不論請求基于怎樣的資源類型。比如，可以將FormsAuthenticationModule提供的Forms認證應用到基于.aspx、CGI和靜態文件的請求。

將ASP.NET提供的一些強大的功能應用到原來難以企及的地方，比如將ASP.NET的URL重寫功能置于身份驗證之前。

采用相同的方式去實現、配置、檢測和支持一些服務器特性（Feature），比如Module、Handler映射、定制錯誤配置（Custom Error Configuration）等。

圖1-10演示了在ASP.NET集成模式下，IIS整個請求處理管道的結構。可以看到，原來ASP.NET提供的托管組件可以直接應用在IIS管道中。

本文節選自《ASP.NET MVC 4 框架揭秘》

蔣金楠 著

電子工業出版社出版