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一樣，透過託管程式碼的方式來擴充套件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管道中。

 

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

 

 

 

 

 

 

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

蔣金楠 著

電子工業出版社出版