各版本IIS下ASP.net請求處理過程分析第1/3頁

絕大多數的人只熟悉高層的架構如： 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。