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 的應用程序池的托管管道模式分兩種： 經典和集成。 這兩種模式下處理策略各不相通。

?

?

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 以建置網站或虛擬目錄）。

IIS 7 的執行架構圖（集成托管信道模式下的架構）

?

小結

IIS5 到 IIS6 的改進，主要是 HTTP.sys 的改進。

IIS6 到 IIS7 的改進，主要是 ISAPI 的改進。

參考資料：

ASP.NET Process Model之一：IIS 和 ASP.NET ISAPI

http://www.cnblogs.com/artech/archive/2007/09/09/887528.html

ASP.NET Internals – IIS and the Process Model

http://dotnetslackers.com/articles/iis/ASPNETInternalsIISAndTheProcessModel.aspx

模組化的IIS 7 與.NET 能力整合

http://www.microsoft.com/taiwan/technet/columns/profwin/33-iis7-componentization-integration.mspx

Introduction to IIS 7.0 Architecture

http://learn.iis.net/page.aspx/101/introduction-to-iis7-architecture/

?

http://www.cnblogs.com/Slxj/archive/2011/10/19/2217612.html

轉載于:https://www.cnblogs.com/Areas/archive/2012/07/10/2584311.html

總結

以上是生活随笔為你收集整理的IIS 内部运行机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。