IIS 7.0與ASP.NET

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-7  定義在SMHost.exe中的Windows Service

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

 

圖1-8  IIS 7.0與ASP.NET

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之間的橋接關係。

 

圖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一樣，通過Managed 程式碼的方式來擴充IIS。

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

允許通過本地代碼（Native Code）和Managed 程式碼（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管道中。

 

圖1-10  基於IIS 7.0與ASP.NET整合式管線設計

 

 

 

 

 

 

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

蔣金楠 著

電子工業出版社出版