前幾天有一個朋友在MSN上問我“ASP.NET 從最初的接收到Http request到最終生成Response的整個流程到底是怎樣的？”我覺得這個問題涉及到IIS和ASP.NETASP.NET Runtime的處理模型的問題，并不是三言兩語就能說清楚的，是以決定寫這樣一篇介紹IIS和ASP.NET Runtime Process Model的文章，談談我對此的一個粗淺的認識，如果有什麼不對的地方，希望大家及時指正。
這篇文章大體分為兩個部分，第一部分我将談談IIS的兩個不同的版本—IIS 5.x 和 IIS 6（雖然IIS 7已經Release很長時間了，而且較之前兩個版本發生了非常大的變化，由于本人缺乏對IIS 7深入的了解，是以在這裡就不再介紹了，不過以後我将這方面的内容補上）的處理模型：IIS如何監聽來自外界的Http request，如何根據ISAPI Extension Mapping将對于不同Resource的請求分發給不同的ISAPI Extension，基于ASP.NET Resource的ASP.NET ISAPI如何将Request傳遞給ASP.NET Runtime 環境。第二部分将着重介紹在一個托管的ASP.NET Runtime 環境對傳入的Http request的處理過程。我們先來看看IIS 5.x和IIS 6的處理過程。
1． 一、IIS 5.x based Process Model
IIS 5.x一個顯著的特征就是Web Server和真正的ASP.NET Application的分離。作為Web Server的IIS運作在一個名為InetInfo.exe的程序上，InetInfo.exe是一個Native Executive，并不是一個托管的程式，而我們真正的ASP.NET Application則是運作在一個叫做aspnet_wp的Worker Process上面，在該程序初始化的時候會加載CLR，是以這是一個托管的環境。我們接下來将談論aspnet_wp如何建立，aspnet_wp和InetInfo.exe如何進行通信，以及簡單介紹在aspnet_wp中，如何将Request 導入ASP.NET Rutime Pipeline。
我們通過建立虛拟目錄将資源Host到IIS下，原則上，我們可以通過IIS通路置于虛拟目錄下的所有Resource，這部僅僅包含一些靜态資源檔案，比如圖檔、純Html檔案、CSS、JS等等，也包含一些需要動态執行的檔案，比如aspx，asmx等等，我們還可以将Remoting和WCF Service Host到IIS下。對于這些靜态的檔案，IIS直接提取對應的檔案将其作為Http Response傳回給Client，但是對于這些需要進一步處理的動态執行的檔案，IIS必須将Request進一步傳遞給對應的處理程式，待處理程式執行完畢獲得最終的Http Response通過IIS傳回給Client。對于IIS來說，這些處理程式通過ISAPI Extension來展現。對于基于ASP.NET的Resource，其對應的ISAPI Extension為ASP.NET ISAPI，通過一個aspnet_isapi.dll承載。IIS的Metadata database維護着一個稱為ISAPI Extension Mapping的資料表，負責将不同類型的Resource影射到對應的ISAPI Extension。
上圖像我們展示了IIS 5.x如何處理一個基于ASP.NET Resource（以aspx為例）的Http Request的大體流程。首先使用者通過Browser請求一個aspx page，Brower向對于得Web Server，也就是目标主機的IIS。在上面我們提到過，IIS運作在一個稱為InetInfo.exe的程序中，InetInfo.exe是一個Native Executive，并非一個托管的程式。IIS分析Request的目标資源檔案的擴充名（這裡是aspx），通過ISAPI Extension Mapping獲知對應的ISPAI為ASP.NET ISAPI,于是加載aspnet_isapi.dll。到此為止，該Request的處理交由ASP.NET ISAPI,處理。ASP.NET ISAPI會建立一個叫做aspnet_wp.exe的Worker Process（如果該程序不存在的話），在aspnet_wp.exe初始化的時候會加載CLR，進而為ASP.NET Application建立一個托管的運作環境，在CLR初始化的使用會加載兩個重要的dll：AppManagerAppDomainFactory和ISAPIRuntime。通過AppManagerAppDomainFactory的Create方法為Application建立一個Application Domain；通過ISAPIRuntime的ProcessRequest處理Request，進而将流程拖入到ASP.NET Http Runtime Pipeline的範疇，ASP.NET Http Runtime Pipeline對Http Request的處理是一個相對複雜的過程，相關的介紹會放在本篇文章的下一部份。在這裡我們可以把它看成是一個黑盒，它接管Request，最終生成Html。
這基本上就是整個處理流程，很簡單。不過在這裡有幾點需要特别指出的。
1. 首先，同一台主機上再同一時間隻能運作一個aspnet_wp程序，每個基于虛拟目錄的ASP.NET Application對應一個Application Domain，也就是說每個Application都運作在同一個Worker Process中，Application之間的隔離是基于Application Domain的，而不是基于Process的。
2. 其次，ASP.NET ISAPI不但負責建立aspnet_wp Worker Process，而且負責監控該程序，如果檢測到aspnet_wp的Performance降低到某個設定的下限，ASP.NET ISAPI會負責結束掉該程序。當aspnet_wp結束掉之後，後續的Request會導緻ASP.NET ISAPI重新建立新的aspnet_wp Worker Process。
3. 最後，由于IIS和Application運作在他們各自的程序中，他們之間的通信必須采用特定的通信機制。本質上IIS所在的InetInfo程序和Worker Process之間的通信是同一台機器不同程序的通信（local interprocess communications），處于Performance的考慮，他們之間采用基于Named pipe的通信機制。ASP.NET ISAPI和Worker Process之間的通信通過他們之間的一組Pipe實作。同樣處于Performance的原因，ASP.NET ISAPI通過異步的方式将Request 傳到Worker Process并獲得Response，但是Worker Process則是通過同步的方式向ASP.NET ISAPI獲得一些基于Server的變量。
2． 二、IIS 6 based Process Model
Reliability 和Performance永遠不我們從事軟體開發不變的主題。作為Host 基于Http Application的IIS來說，這兩方面就顯得尤為重要了。我們從IIS 5.x到IIS 6 的演變，不難看出IIS 6在前一個版本基礎上所作的改進也是基于這兩個方面。在介紹IIS 6的處理模型之前，我們先看看IIS 5.x都什麼樣缺陷：
1. 首先從Performance上看，IIS和application運作在不同的程序中，雖然他們之間采用了基于Named Pipe的異步通信方式，但是一個基于程序之間的通信對性能的影響确實不能從根本上解決。
2. 其次，從Reliability來考慮，一台機器上隻能運作一個worker process，每個Application運作在同一個程序中，雖然基于Application Domain的隔離能提供一定的Reliability，但是一旦真個程序崩潰，所有的Application都受影響。是以我們有時候需要提供一個基于Process的隔離性。
基于Reliability的改進，IIS 6引入了Application Pool。顧名思義，Application Pool就是一個application的容器，在IIS 6中，我們可以建立若幹Application Pool，在建立Web Application的時候，我們為它指定一個既定的application pool。在運作的時候，一個Application對應一個Worker Process：w3wp.exe。也就是說，和前一個版本的IIS不同的是，對于IIS 6來說，同一台機器上可以同時運作多個Worker Process，每個Worker Process中的每個Application domain對應一個Application。這樣，Application之間不但能提供Application Domain級别的隔離，你也可以将不同的Application置于不同的Application Pool中，進而基于Process級别的隔離。對于Host 一些重要的Application來說，這樣的方式可以提供很好的Reliability。
在Performance方面，IIS 5.x是通過InetInfo.exe監聽Request并把Request分發到Work Process。換句話說，在IIS 5.x中對Request的監聽和分發是在User Mode中進行，在IIS 6中，這種工作被移植到kernel Mode中進行，所有的這一切都是通過一個新的元件：http.sys來負責。
注：為了避免使用者應用程式通路或者修改關鍵的作業系統資料，windows提供了兩種處理器通路模式：使用者模式（User Mode）和核心模式（Kernel Mode）。一般地，使用者程式運作在User mode下，而作業系統代碼運作在Kernel Mode下。Kernel Mode的代碼允許通路所有系統記憶體和所有CPU指令。關于User Mode和Kernel Mode以及一些Windows底層的一些内容，推薦大家看看《Microsoft Windows Internal》Four Edition， Authored by Mark E.Russinovich & David A. Solomon。
上圖基本上示範了IIS 6整個處理過程。在User Mode下，http.sys接收到一個基于aspx的http request，然後它會根據IIS中的Metabase檢視該基于該Request的Application屬于哪個Application Pool，如果該Application Pool不存在，則建立之。否則直接将request發到對應Application Pool的Queue中。我上面已經說了，每個Application Pool對應着一個Worker Process：w3wp.exe，毫無疑問他是運作在User Mode下的。在IIS Metabase中維護着Application Pool和worker process的Mapping。WAS（Web Administrative service）根據這樣一個mapping，将存在于某個Application Pool Queue的request 傳遞到對應的worker process(如果沒有，就建立這樣一個程序)。在worker process初始化的時候，加載ASP.NET ISAPI，ASP.NET ISAPI進而加載CLR。最後的流程就和IIS 5.x一樣了：通過AppManagerAppDomainFactory的Create方法為Application建立一個Application Domain；通過ISAPIRuntime的ProcessRequest處理Request，進而将流程進入到ASP.NET Http Runtime Pipeline。
對IIS Process Model部分就介紹到這裡，在下部分中，我将介紹ASP.NET Http Runtime Pipeline。
Reference:
The ASP.NET HTTP Runtime
ASP.NET Internals – IIS and the Process Model
ASP.NET Internals - The bridge between ISAPI and Application Domains
Microsoft® Windows® Internals, Fourth Edition: Microsoft Windows Server™ 2003, Windows XP, and Windows 2000
ASP.NET Process Model
[原創]ASP.NET Process Model之一：IIS 和 ASP.NET ISAPI
[原創]ASP.NET Process Model之二：ASP.NET Http Runtime Pipeline - Part I
[原創]ASP.NET Process Model之二：ASP.NET Http Runtime Pipeline - Part II