ASP.NET是一個非常強大的構建Web應用的平臺，它提供了極大的靈活性和能力以致于可以用它來構建所有類型的Web應用。
絕大多數的人只熟悉高層的框架如： WebForms和 WebServices --這些都在ASP.NET層次結構在最高層。
這篇文章的資料收集整理自各種微軟公開的文檔，通過比較IIS5、IIS6、IIS7這三代IIS對請求的處理過程，讓我們熟悉ASP.NET的底層機制并對請求(request)是怎么從Web服務器傳送到ASP.NET運行時有所了解。通過對底層機制的了解，可以讓我們對ASP.net有更深的理解。
IIS 5 的 ASP.net 請求處理過程
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，所以這是一個托管的環境。
ISAPI：指能夠處理各種后綴名的應用程序。 ISAPI是下面單詞的簡寫：Internet Server Application Programe Interface，互聯網服務器應用程序接口。
IIS 5 模式的特點：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的變量。
IIS6 的 ASP.net 請求處理過程
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下，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 7 的 ASP.net 請求處理過程IIS7站點啟動并處理請求的步驟如下圖：
步驟1 到6 ，是處理應用啟動，啟動好后，以后就不需要再走這個步驟了。
上圖的8個步驟分別如下：
1、當客戶端瀏覽器開始HTTP請求一個WEB服務器的資源時，HTTP.sys攔截到這個請求。
2、HTTP.sys contacts WAS to obtain information from the configuration store.
3、WAS向配置存儲中心請求配置信息。applicationHost.config。
4、WWW服務接受到配置信息，配置信息指類似應用程序池配置信息，站點配置信息等等。
5、WWW服務使用配置信息去配置HTTP.sys處理策略。
6、WAS starts a worker process for the application pool to which the request was made.
7、The worker process processes the request and returns a response to HTTP.sys.
8、客戶端接受到處理結果信息。
W3WP.exe進程中又是如果處理得呢?? IIS 7 的應用程序池的托管管道模式分兩種：經典和集成。這兩種模式下處理策略各不相通。
本文http://blog.joycode.com/ghj
IIS 6 以及 IIS7 經典模式的托管管道的架構在IIS7之前，ASP.NET是以IIS ISAPI extension的方式外加到IIS，其實包括ASP以及PHP，也都以相同的方式配置(PHP在 IIS采用了兩種配置方式，除了IIS ISAPI extension的方式，也包括了CGI的方式，系統管理者能選擇PHP程序的執行方式)，因此客戶端對IIS的 HTTP請求會先經由IIS處理，然后IIS根據要求的內容類型，如果是HTML靜態網頁就由IIS自行處理，如果不是，就根據要求的內容類型，分派給各自的IIS ISAPI extension;如果要求的內容類型是ASP.NET，就分派給負責處理ASP.NET的 IIS ISAPI extension，也就是aspnet_isapi.dll。下圖是這個架構的示意圖。
IIS 7 應用程序池的托管管道模式經典模式也是這樣的工作原理。這種模式是兼容IIS 6 的方式，以減少升級的成本。
IIS6的執行架構圖，以及IIS7應用程序池配置成經典模式的執行架構圖
IIS 7 應用程序池的 托管管道模式 集成模式而IIS 7 完全整合.NET之后，架構的處理順序有了很大的不同(如下圖)，最主要的原因就是ASP.NET從 IIS插件(ISAPI extension)的角色，進入了IIS核心，而且也能以ASP.NET模塊負責處理IIS 7 的諸多類型要求。這些ASP.NET模塊不只能處理ASP.NET網頁程序，也能處理其他如ASP程序、PHP程序或靜態HTML網頁，也因為ASP.NET的諸多功能已經成為IIS 7 的一部份，因此ASP程序、PHP程序或靜態HTML網頁等類型的要求，也能使用像是Forms認證(Forms Authentication)或輸出緩存(Output Cache)等ASP.NET 2.0的功能(但須修改IIS 7 的設定值)。也因為IIS 7 允許自行以ASP.NET API開發并加入模塊，因此ASP.NET網頁開發人員將更容易擴充IIS 7 和網站應用程序的功能，甚至能自行以.NET編寫管理IIS 7 的程序(例如以程控IIS 7 以建置網站或虛擬目錄)。
IIS5到 IIS6的改進，主要是HTTP.sys的改進。
IIS6到 IIS7的改進，主要是ISAPI的改進。、
來源：http://blog.joycode.com/ghj/archive/2008/07/25/115200.aspx