ASP.NET是一個(gè)非常強(qiáng)大的構(gòu)建Web應(yīng)用的平臺(tái)，它提供了極大的靈活性和能力以致于可以用它來構(gòu)建所有類型的Web應(yīng)用。
絕大多數(shù)的人只熟悉高層的框架如： WebForms 和 WebServices --這些都在ASP.NET層次結(jié)構(gòu)在最高層。

這 篇文章的資料收集整理自各種微軟公開的文檔，通過比較 IIS5、IIS6、IIS7 這三代 IIS 對請求的處理過程， 讓我們熟悉 ASP.NET的底層機(jī)制 并對請求(request)是怎么從Web服務(wù)器傳送到ASP.NET運(yùn)行時(shí)有所了解。通過對底層機(jī)制的了解，可以讓我們對 ASP.net 有更深的理解。

IIS 5 的 ASP.net 請求處理過程

對圖的解釋：

IIS 5.x 一個(gè)顯著的特征就是 Web Server 和真正的 ASP.NET Application 的分離。作為 Web Server 的IIS運(yùn)行在一個(gè)名為 InetInfo.exe 的進(jìn)程上，InetInfo.exe 是一個(gè)Native Executive，并不是一個(gè)托管的程序，而我們真正的 ASP.NET Application 則是運(yùn)行在一個(gè)叫做 aspnet_wp 的 Worker Process 上面，在該進(jìn)程初始化的時(shí)候會(huì)加載CLR，所以這是一個(gè)托管的環(huán)境。

ISAPI：  指能夠處理各種后綴名的應(yīng)用程序。 ISAPI 是下面單詞的簡寫 ：Internet Server Application Programe Interface，互聯(lián)網(wǎng)服務(wù)器應(yīng)用程序接口。

IIS 5 模式的特點(diǎn)：

1、 首先，同一臺(tái)主機(jī)上在同一時(shí)間只能運(yùn)行一個(gè) aspnet_wp 進(jìn)程，每個(gè)基于虛擬目錄的 ASP.NET Application 對應(yīng)一個(gè) Application Domain ，也就是說每個(gè) Application 都運(yùn)行在同一個(gè) Worker Process 中，Application之間的隔離是基于 Application Domain 的，而不是基于Process的。

2、其 次，ASP.NET  ISAPI 不但負(fù)責(zé)創(chuàng)建 aspnet_wp Worker Process，而且負(fù)責(zé)監(jiān)控該進(jìn)程，如果檢測到 aspnet_wp 的 Performance 降低到某個(gè)設(shè)定的下限，ASP.NET  ISAPI 會(huì)負(fù)責(zé)結(jié)束掉該進(jìn)程。當(dāng) aspnet_wp 結(jié)束掉之后，后續(xù)的 Request 會(huì)導(dǎo)致ASP.NET ISAPI 重新創(chuàng)建新的 aspnet_wp Worker Process。

3、 最后，由于 IIS 和 Application 運(yùn)行在他們各自的進(jìn)程中，他們之間的通信必須采用特定的通信機(jī)制。本質(zhì)上 IIS 所在的 InetInfo 進(jìn)程和 Worker Process 之間的通信是同一臺(tái)機(jī)器不同進(jìn)程的通信（local interprocess communications），處于Performance的考慮，他們之間采用基于Named pipe的通信機(jī)制。ASP.NET ISAPI和Worker Process之間的通信通過他們之間的一組Pipe實(shí)現(xiàn)。同樣處于Performance的原因，ASP.NET ISAPI 通過異步的方式將Request 傳到Worker Process 并獲得 Response，但是 Worker Process 則是通過同步的方式向 ASP.NET ISAPI 獲得一些基于 Server 的變量。

IIS6 的 ASP.net 請求處理過程

對圖的解釋：

IIS 5.x 是通過 InetInfo.exe 監(jiān)聽 Request 并把Request分發(fā)到Work Process。換句話說，在IIS 5.x中對Request的監(jiān)聽和分發(fā)是在User Mode中進(jìn)行，在IIS 6中，這種工作被移植到kernel Mode中進(jìn)行，所有的這一切都是通過一個(gè)新的組件：http.sys 來負(fù)責(zé)。

注：為了避免用戶應(yīng)用程序訪問或者修改關(guān)鍵的操作 系統(tǒng)數(shù)據(jù)，windows提供了兩種處理器訪問模式：用戶模式（User Mode）和內(nèi)核模式（Kernel Mode）。一般地，用戶程序運(yùn)行在User mode下，而操作系統(tǒng)代碼運(yùn)行在Kernel Mode下。Kernel Mode的代碼允許訪問所有系統(tǒng)內(nèi)存和所有CPU指令。

在User Mode下，http.sys接收到一個(gè)基于 aspx 的http request，然后它會(huì)根據(jù)IIS中的 Metabase 查看該基于該 Request 的 Application 屬于哪個(gè)Application Pool， 如果該Application Pool不存在，則創(chuàng)建之。否則直接將 request 發(fā)到對應(yīng)Application Pool 的 Queue中。

每個(gè) Application Pool 對應(yīng)著一個(gè)Worker Process：w3wp.exe，毫無疑問他是運(yùn)行在User Mode下的。在IIS Metabase 中維護(hù)著 Application Pool 和worker process的Mapping。WAS（Web Administrative service）根據(jù)這樣一個(gè)mapping，將存在于某個(gè)Application Pool Queue的request 傳遞到對應(yīng)的worker process(如果沒有，就創(chuàng)建這樣一個(gè)進(jìn)程)。在 worker process 初始化的時(shí)候，加載ASP.NET ISAPI，ASP.NET ISAPI 進(jìn)而加載CLR。最后的流程就和IIS 5.x一樣了：通過AppManagerAppDomainFactory 的 Create方法為 Application 創(chuàng)建一個(gè)Application Domain；通過 ISAPIRuntime 的 ProcessRequest處理Request，進(jìn)而將流程進(jìn)入到ASP.NET Http Runtime Pipeline。

IIS 7  的 ASP.net 請求處理過程

IIS7 站點(diǎn)啟動(dòng)并處理請求的步驟如下圖：

步驟 1 到 6 ，是處理應(yīng)用啟動(dòng)，啟動(dòng)好后，以后就不需要再走這個(gè)步驟了。

上圖的8個(gè)步驟分別如下：

1、當(dāng)客戶端瀏覽器開始HTTP 請求一個(gè)WEB 服務(wù)器的資源時(shí)，HTTP.sys 攔截到這個(gè)請求。
2、HTTP.sys contacts WAS to obtain information from the configuration store.

3、WAS 向配置存儲(chǔ)中心請求配置信息。applicationHost.config。
4、WWW 服務(wù)接受到配置信息，配置信息指類似應(yīng)用程序池配置信息，站點(diǎn)配置信息等等。
5、WWW 服務(wù)使用配置信息去配置 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、客戶端接受到處理結(jié)果信息。

W3WP.exe 進(jìn)程中又是如果處理得呢？？ IIS 7 的應(yīng)用程序池的托管管道模式分兩種： 經(jīng)典和集成。 這兩種模式下處理策略各不相通。

本文作者：郭紅俊 http://blog./ghj

IIS 6 以及 IIS7 經(jīng)典模式的托管管道的架構(gòu)

       在IIS7之前，ASP.NET 是以 IIS ISAPI extension 的方式外加到 IIS，其實(shí)包括 ASP 以及 PHP，也都以相同的方式配置（PHP 在 IIS 采用了兩種配置方式，除了 IIS ISAPI extension 的方式，也包括了 CGI 的方式，系統(tǒng)管理者能選擇 PHP 程序的執(zhí)行方式），因此客戶端對 IIS 的 HTTP 請求會(huì)先經(jīng)由 IIS 處理，然后 IIS 根據(jù)要求的內(nèi)容類型，如果是 HTML 靜態(tài)網(wǎng)頁就由 IIS 自行處理，如果不是，就根據(jù)要求的內(nèi)容類型，分派給各自的 IIS ISAPI extension；如果要求的內(nèi)容類型是 ASP.NET，就分派給負(fù)責(zé)處理 ASP.NET 的 IIS ISAPI extension，也就是 aspnet_isapi.dll。下圖是這個(gè)架構(gòu)的示意圖。

IIS  7 應(yīng)用程序池的 托管管道模式  經(jīng)典  模式也是這樣的工作原理。 這種模式是兼容IIS 6 的方式， 以減少升級的成本。

IIS6 的執(zhí)行架構(gòu)圖，以及 IIS7  應(yīng)用程序池配置成經(jīng)典模式的執(zhí)行架構(gòu)圖

IIS  7 應(yīng)用程序池的 托管管道模式  集成模式

       而 IIS 7 完全整合 .NET 之后，架構(gòu)的處理順序有了很大的不同（如下圖），最主要的原因就是 ASP.NET 從 IIS 插件（ISAPI extension）的角色，進(jìn)入了 IIS 核心，而且也能以 ASP.NET 模塊負(fù)責(zé)處理 IIS 7 的諸多類型要求。這些 ASP.NET 模塊不只能處理 ASP.NET 網(wǎng)頁程序，也能處理其他如 ASP 程序、PHP 程序或靜態(tài) HTML 網(wǎng)頁，也因?yàn)?ASP.NET 的諸多功能已經(jīng)成為 IIS 7 的一部份，因此 ASP 程序、PHP 程序或靜態(tài) HTML 網(wǎng)頁等類型的要求，也能使用像是Forms認(rèn)證（Forms Authentication）或輸出緩存（Output Cache）等 ASP.NET 2.0 的功能（但須修改 IIS 7 的設(shè)定值）。也因?yàn)?IIS 7 允許自行以 ASP.NET API 開發(fā)并加入模塊，因此 ASP.NET 網(wǎng)頁開發(fā)人員將更容易擴(kuò)充 IIS 7 和網(wǎng)站應(yīng)用程序的功能，甚至能自行以 .NET 編寫管理 IIS 7 的程序（例如以程控 IIS 7 以建置網(wǎng)站或虛擬目錄）。

IIS 7 的執(zhí)行架構(gòu)圖（集成托管信道模式下的架構(gòu)）

小結(jié)

IIS5 到 IIS6 的改進(jìn)，主要是 HTTP.sys 的改進(jìn)。

IIS6 到 IIS7 的改進(jìn)，主要是 ISAPI 的改進(jìn)。