WCF技術剖析之二：再談IIS與ASP.NET管道

IIS 5.x與ASP.NET

我們先來看看IIS 5.x是如何處理基於ASP.NET資源（比如.aspx,.asmx等）請求的，整個過程基本上可以通過圖1體現。

IIS 5.x運行在進程InetInfo.exe中，在該進程中一個最重要的服務就是名為World Wide Web Publishing Service（簡稱W3SVC）的Windows Service。W3SVC的主要功能包括HTTP請求的監聽、背景工作處理序的管理以及組態管理（通過從Metabase中載入相關配置資訊）等。

當檢測到某個HTTP Request後，先根據副檔名判斷請求的是否是靜態資源（比如.html,.img,.txt,.xml等），如果是則直接將檔案內容以HTTP Response的形式返回。如果是動態資源（比如.aspx,asp,php等等），則通過副檔名從IIS的指令碼影射（Script Map）找到相應的ISAPI Dll。

圖1 IIS 5.x與ASP.NET

ISAPI是Internet伺服器API（Internet Server Application Programming Interface）的縮寫，是一套本地的（Native）Win32 API，具有較高的執行效能,是IIS和其他動態Web應用或者平台之間的紐帶。比如ASP ISAPI橋接IIS與ASP，而ASP.NET ISAPI則串連著IIS與ASP.NET。ISPAI定義在一個Dll中，ASP.NET ISAPI對應的Dll為Aspnet_isapi.dll,你可以在目錄“%windir%\Microsoft.NET\Framework\{version no}\”中找到該Dll。

ISAPI支援ISAPI擴充（ISAPI Extension）和ISAPI篩選（ISAPI Filter），前者是真正處理HTTP請求的介面，後者則可以在HTTP請求真正被處理之前查看、修改、轉寄或者拒絕請求，比如IIS可以利用ISAPI篩選進行請求的驗證（Authentication）。

如果我們請求的是一個基於ASP.NET的資源類型，比如：.aspx Web Page、 .asmx Web Service或者.svc WCF Service等，Aspnet_isapi.dll會被載入，ASP.NET ISAPI擴充會建立ASP.NET的背景工作處理序（如果該進程尚未啟動），對於IIS 5.x來說，該背景工作處理序為aspnet.exe。IIS進程與背景工作處理序之間通過具名管道（Named Pipes）進程通訊，以獲得最好的效能。

在背景工作處理序初始化過程中，.NET 運行時（CLR）被載入，從而構建了一個託管的環境。對於某個Web應用的初次請求，CLR會為其建立一個AppDomain。在此AppDomain中，HTTP運行時（HTTP Runtime）被載入並用以建立相應的應用。對於寄宿於IIS 5.x的所有Web 應用程式都運行在同一個進程（背景工作處理序Aspnet_wp.exe）的不同AppDomain中。

IIS 6與ASP.NET

通過上面的介紹，我們可以看出IIS 5.x至少存在著如下兩個方面的不足：

ISAPI Dll被載入到InetInfo.exe進程中，它和背景工作處理序之間是一種典型的跨進程通訊方式，儘管採用效能最好的具名管道，但是仍然會帶來效能的瓶頸；

所有的ASP.NET應用，運行在相同的進程（aspnet_wp.exe）中的不同的應用程式定義域（AppDomain）中，基於應用程式定義域的隔離等級不能從根本上解決一個應用程式對另一個程式的影響，在更多的時候，我們需要不同的Web應用運行在不同的進程中。

在IIS 6.0中，為瞭解決第一個問題，ISAPI.dll被直接載入到背景工作處理序中。為瞭解決第2個問題，引入了應用程式集區（Application Pool）的機制。我們可以為一個或者多個Web應用建立應用程式集區，每一個應用程式集區對應一個獨立的背景工作處理序，從而為運行在不同應用程式集區中的Web應用提供基於進程的隔離等級。IIS 6.0的背景工作處理序名稱為w3wp.exe。

當然，除了上面兩點改進之外，IIS 6.0還有其他一些值得稱道的地方，其中最重要的一點就是建立了一個新的HTTP監聽器：HTTP協議棧（HTTP Protocol Stack，HTTP.SYS）。HTTP.SYS運行在Windows的核心模式（Kernel Mode）下，作為驅動程式而存在。它是Windows 2003的TCP/IP網路子系統的一部分，從結構上，它屬於TCP之上的一個網路驅動程式。嚴格地說，HTTP.SYS已經不屬於IIS的範疇了，所以HTTP.SYS的配置資訊並不儲存在IIS的中繼資料庫（Metabase），而是定義在註冊表中。HTTP.SYS的登錄機碼位於下面的路徑中：HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/HTTP。HTTP.SYS能夠帶來如下的好處：

持續監聽：由於HTTP.SYS是一個網路驅動程式，始終處於運行狀態，對於使用者的HTTP請求，能夠及時作出反應；

更好的穩定性：HTTP.SYS運行在作業系統核心模式下，並不執行任何使用者代碼，所以其本身不會受到Web應用、背景工作處理序和IIS進程的影響；

核心模式下資料緩衝：如果某個資源被頻繁請求，HTTP.SYS會把響應的內容進行緩衝，緩衝的內容可以直接響應後續的請求。由於這是基於核心模式的緩衝，不存在核心模式和使用者模式的切換，響應速度將得到極大的改進。

圖2體現了IIS的結構和處理HTTP請求的流程。從中可以看出，與IIS 5.x不同，W3SVC從InetInfo.exe進程脫離出來（對於IIS6.0來說，InetInfo.exe基本上可以看作單純的IIS管理進程），運行在另一個進程SvcHost.exe中。不過W3SVC的準系統並沒有發生變化，只是在功能的實現上作了相應的改進。與IIS 5.x一樣，中繼資料庫（Metabase）依然存在於InetInfo.exe進程中。

圖2 IIS 6與ASP.NET

當HTTP.SYS監聽到使用者的HTTP請求後，將其分發給W3SVC。W3SVC解析出請求的URL，並根據從Metabase擷取的URL與Web應用之間的映射關係得到目標應用，並進一步得到目標應用啟動並執行應用程式集區或者背景工作處理序。如果背景工作處理序不存在（尚未建立或者被回收），則為該請求建立新的背景工作處理序，背景工作處理序的這種建立方式被稱為請求式建立。在背景工作處理序的初始化過程中，相應的ISAPI.dll被載入，對於ASP.NET應用來說，被載入的ISAPI.dll為Aspnet_ispai.dll。ASP.NET ISAPI再負責進行CLR的載入、AppDomain建立、Web Application的初始化等。