ASP.NET是一個(gè)非常強大的構建Web應用的平臺，它提供了極大的靈活性和能力以致于可以用它來(lái)構建所有類(lèi)型的Web應用。
絕大多數的人只熟悉高層的框架如： WebForms 和 WebServices --這些都在A(yíng)SP.NET層次結構在最高層。
這篇文章的資料收集整理自各種微軟公開(kāi)的文檔，通過(guò)比較 IIS5、IIS6、IIS7 這三代 IIS 對請求的處理過(guò)程， 讓我們熟悉ASP.NET的底層機制 并對請求(request)是怎么從Web服務(wù)器傳送到ASP.NET運行時(shí)有所了解。通過(guò)對底層機制的了解，可以讓我們對ASP.net 有更深的理解。
IIS 5 的 ASP.net 請求處理過(guò)程
對圖的解釋?zhuān)?/p>
IIS5.x 一個(gè)顯著(zhù)的特征就是 Web Server 和真正的 ASP.NET Application 的分離。作為 Web Server的IIS運行在一個(gè)名為 InetInfo.exe 的進(jìn)程上，InetInfo.exe 是一個(gè)NativeExecutive，并不是一個(gè)托管的程序，而我們真正的 ASP.NET Application 則是運行在一個(gè)叫做 aspnet_wp 的Worker Process 上面，在該進(jìn)程初始化的時(shí)候會(huì )加載CLR，所以這是一個(gè)托管的環(huán)境。
ISAPI： 指能夠處理各種后綴名的應用程序。 ISAPI 是下面單詞的簡(jiǎn)寫(xiě) ：Internet Server Application Programe Interface，互聯(lián)網(wǎng)服務(wù)器應用程序接口。
IIS 5 模式的特點(diǎn)：
1、首先，同一臺主機上在同一時(shí)間只能運行一個(gè) aspnet_wp 進(jìn)程，每個(gè)基于虛擬目錄的 ASP.NET Application 對應一個(gè)Application Domain ，也就是說(shuō)每個(gè) Application 都運行在同一個(gè) Worker Process中，Application之間的隔離是基于 Application Domain 的，而不是基于Process的。
2、其次，ASP.NET ISAPI 不但負責創(chuàng )建 aspnet_wp Worker Process，而且負責監控該進(jìn)程，如果檢測到aspnet_wp 的 Performance 降低到某個(gè)設定的下限，ASP.NET ISAPI 會(huì )負責結束掉該進(jìn)程。當 aspnet_wp結束掉之后，后續的 Request 會(huì )導致ASP.NET ISAPI 重新創(chuàng )建新的 aspnet_wp Worker Process。
3、最后，由于 IIS 和 Application 運行在他們各自的進(jìn)程中，他們之間的通信必須采用特定的通信機制。本質(zhì)上 IIS 所在的InetInfo 進(jìn)程和 Worker Process 之間的通信是同一臺機器不同進(jìn)程的通信（local interprocesscommunications），處于Performance的考慮，他們之間采用基于Named pipe的通信機制。ASP.NETISAPI和Worker Process之間的通信通過(guò)他們之間的一組Pipe實(shí)現。同樣處于Performance的原因，ASP.NETISAPI 通過(guò)異步的方式將Request 傳到Worker Process 并獲得 Response，但是 Worker Process則是通過(guò)同步的方式向 ASP.NET ISAPI 獲得一些基于 Server 的變量。
IIS6 的 ASP.net 請求處理過(guò)程
對圖的解釋?zhuān)?/p>
IIS5.x 是通過(guò) InetInfo.exe 監聽(tīng) Request 并把Request分發(fā)到Work Process。換句話(huà)說(shuō)，在IIS5.x中對Request的監聽(tīng)和分發(fā)是在User Mode中進(jìn)行，在IIS 6中，這種工作被移植到kernelMode中進(jìn)行，所有的這一切都是通過(guò)一個(gè)新的組件：http.sys 來(lái)負責。
注：為了避免用戶(hù)應用程序訪(fǎng)問(wèn)或者修改關(guān)鍵的操作系統數據，windows提供了兩種處理器訪(fǎng)問(wèn)模式：用戶(hù)模式（User Mode）和內核模式（KernelMode）。一般地，用戶(hù)程序運行在User mode下，而操作系統代碼運行在Kernel Mode下。KernelMode的代碼允許訪(fǎng)問(wèn)所有系統內存和所有CPU指令。
在User Mode下，http.sys接收到一個(gè)基于 aspx的http request，然后它會(huì )根據IIS中的 Metabase 查看該基于該 Request 的 Application屬于哪個(gè)Application Pool， 如果該Application Pool不存在，則創(chuàng )建之。否則直接將 request發(fā)到對應Application Pool 的 Queue中。
每個(gè) Application Pool 對應著(zhù)一個(gè)WorkerProcess：w3wp.exe，毫無(wú)疑問(wèn)他是運行在User Mode下的。在IIS Metabase 中維護著(zhù) ApplicationPool 和worker process的Mapping。WAS（Web Administrativeservice）根據這樣一個(gè)mapping，將存在于某個(gè)Application Pool Queue的request 傳遞到對應的workerprocess(如果沒(méi)有，就創(chuàng )建這樣一個(gè)進(jìn)程)。在 worker process 初始化的時(shí)候，加載ASP.NET ISAPI，ASP.NETISAPI 進(jìn)而加載CLR。最后的流程就和IIS 5.x一樣了：通過(guò)AppManagerAppDomainFactory 的Create方法為 Application 創(chuàng )建一個(gè)Application Domain；通過(guò) ISAPIRuntime 的ProcessRequest處理Request，進(jìn)而將流程進(jìn)入到ASP.NET Http Runtime Pipeline。
IIS 7 的 ASP.net 請求處理過(guò)程
IIS7 站點(diǎn)啟動(dòng)并處理請求的步驟如下圖：
步驟 1 到 6 ，是處理應用啟動(dòng)，啟動(dòng)好后，以后就不需要再走這個(gè)步驟了。
上圖的8個(gè)步驟分別如下：
1、當客戶(hù)端瀏覽器開(kāi)始HTTP 請求一個(gè)WEB 服務(wù)器的資源時(shí)，HTTP.sys 攔截到這個(gè)請求。
2、HTTP.sys contacts WAS to obtain information from the configuration store.
3、WAS 向配置存儲中心請求配置信息。applicationHost.config。
4、WWW 服務(wù)接受到配置信息，配置信息指類(lèi)似應用程序池配置信息，站點(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、客戶(hù)端接受到處理結果信息。
W3WP.exe 進(jìn)程中又是如果處理得呢？？ IIS 7 的應用程序池的托管管道模式分兩種： 經(jīng)典和集成。 這兩種模式下處理策略各不相通。
本文作者：郭紅俊 http://blog.joycode.com/ghj
IIS 6 以及 IIS7 經(jīng)典模式的托管管道的架構
在IIS7之前，ASP.NET 是以 IIS ISAPI extension 的方式外加到 IIS，其實(shí)包括 ASP 以及PHP，也都以相同的方式配置（PHP 在 IIS 采用了兩種配置方式，除了 IIS ISAPI extension 的方式，也包括了 CGI的方式，系統管理者能選擇 PHP 程序的執行方式），因此客戶(hù)端對 IIS 的 HTTP 請求會(huì )先經(jīng)由 IIS 處理，然后 IIS根據要求的內容類(lèi)型，如果是 HTML 靜態(tài)網(wǎng)頁(yè)就由 IIS 自行處理，如果不是，就根據要求的內容類(lèi)型，分派給各自的 IIS ISAPIextension；如果要求的內容類(lèi)型是 ASP.NET，就分派給負責處理 ASP.NET 的 IIS ISAPI extension，也就是aspnet_isapi.dll。下圖是這個(gè)架構的示意圖。
IIS 7 應用程序池的 托管管道模式 經(jīng)典 模式也是這樣的工作原理。 這種模式是兼容IIS 6 的方式， 以減少升級的成本。
IIS6 的執行架構圖，以及 IIS7 應用程序池配置成經(jīng)典模式的執行架構圖
IIS 7 應用程序池的 托管管道模式 集成模式
而 IIS 7 完全整合 .NET 之后，架構的處理順序有了很大的不同（如下圖），最主要的原因就是 ASP.NET 從 IIS插件（ISAPI extension）的角色，進(jìn)入了 IIS 核心，而且也能以 ASP.NET 模塊負責處理 IIS 7 的諸多類(lèi)型要求。這些ASP.NET 模塊不只能處理 ASP.NET 網(wǎng)頁(yè)程序，也能處理其他如 ASP 程序、PHP 程序或靜態(tài) HTML 網(wǎng)頁(yè)，也因為ASP.NET 的諸多功能已經(jīng)成為 IIS 7 的一部份，因此 ASP 程序、PHP 程序或靜態(tài) HTML網(wǎng)頁(yè)等類(lèi)型的要求，也能使用像是Forms認證（Forms Authentication）或輸出緩存（Output Cache）等ASP.NET 2.0 的功能（但須修改 IIS 7 的設定值）。也因為 IIS 7 允許自行以 ASP.NET API 開(kāi)發(fā)并加入模塊，因此ASP.NET 網(wǎng)頁(yè)開(kāi)發(fā)人員將更容易擴充 IIS 7 和網(wǎng)站應用程序的功能，甚至能自行以 .NET 編寫(xiě)管理 IIS 7 的程序（例如以程控IIS 7 以建置網(wǎng)站或虛擬目錄）。
IIS 7 的執行架構圖（集成托管信道模式下的架構）
小結
IIS5 到 IIS6 的改進(jìn)，主要是 HTTP.sys 的改進(jìn)。
IIS6 到 IIS7 的改進(jìn)，主要是 ISAPI 的改進(jìn)。
聯(lián)系客服
