ASP.NET是一個(gè)非常強(qiáng)大的構(gòu)建Web應(yīng)用的平臺(tái)，它提供了極大的靈活性和能力以致于可以用它來(lái)構(gòu)建所有類型的Web應(yīng)用。

　　絕大多數(shù)的人只熟悉高層的框架如： WebForms和 WebServices --這些都在ASP.NET層次結(jié)構(gòu)在最高層。

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

　　IIS 5 的 ASP.net 請(qǐng)求處理過(guò)程
　　對(duì)圖的解釋：

　　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是下面單詞的簡(jiǎn)寫(xiě)：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對(duì)應(yīng)一個(gè)Application Domain ，也就是說(shuō)每個(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)程，如果檢測(cè)到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之間的通信通過(guò)他們之間的一組Pipe實(shí)現(xiàn)。同樣處于Performance的原因，ASP.NET ISAPI通過(guò)異步的方式將Request傳到Worker Process并獲得Response，但是Worker Process則是通過(guò)同步的方式向ASP.NET ISAPI獲得一些基于Server的變量。

　　IIS6 的 ASP.net 請(qǐng)求處理過(guò)程
　　對(duì)圖的解釋：

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

　　注：為了避免用戶應(yīng)用程序訪問(wèn)或者修改關(guān)鍵的操作系統(tǒng)數(shù)據(jù)，windows提供了兩種處理器訪問(wèn)模式：用戶模式(User Mode)和內(nèi)核模式(Kernel Mode)。一般地，用戶程序運(yùn)行在User mode下，而操作系統(tǒng)代碼運(yùn)行在Kernel Mode下。Kernel Mode的代碼允許訪問(wèn)所有系統(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ā)到對(duì)應(yīng)Application Pool的 Queue中。

　　每個(gè)Application Pool對(duì)應(yīng)著一個(gè)Worker Process：w3wp.exe，毫無(wú)疑問(wèn)他是運(yùn)行在User Mode下的。在IIS Metabase中維護(hù)著Application Pool和worker process的Mapping。WAS(Web Administrative service)根據(jù)這樣一個(gè)mapping，將存在于某個(gè)Application Pool Queue的request傳遞到對(duì)應(yīng)的worker process(如果沒(méi)有，就創(chuàng)建這樣一個(gè)進(jìn)程)。在worker process初始化的時(shí)候，加載ASP.NET ISAPI，ASP.NET ISAPI進(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 請(qǐng)求處理過(guò)程

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

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

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

　　1、當(dāng)客戶端瀏覽器開(kāi)始HTTP請(qǐng)求一個(gè)WEB服務(wù)器的資源時(shí)，HTTP.sys攔截到這個(gè)請(qǐng)求。

　　2、HTTP.sys contacts WAS to obtain information from the configuration store.

　　3、WAS向配置存儲(chǔ)中心請(qǐng)求配置信息。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.joycode.com/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í)行方式)，因此客戶端對(duì)IIS的 HTTP請(qǐng)求會(huì)先經(jīng)由IIS處理，然后IIS根據(jù)要求的內(nèi)容類型，如果是HTML靜態(tài)網(wǎng)頁(yè)就由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 的方式，以減少升級(jí)的成本。

　　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)頁(yè)程序，也能處理其他如ASP程序、PHP程序或靜態(tài)HTML網(wǎng)頁(yè)，也因?yàn)锳SP.NET的諸多功能已經(jīng)成為IIS 7 的一部份，因此ASP程序、PHP程序或靜態(tài)HTML網(wǎng)頁(yè)等類型的要求，也能使用像是Forms認(rèn)證(Forms Authentication)或輸出緩存(Output Cache)等ASP.NET 2.0的功能(但須修改IIS 7 的設(shè)定值)。也因?yàn)镮IS 7 允許自行以ASP.NET API開(kāi)發(fā)并加入模塊，因此ASP.NET網(wǎng)頁(yè)開(kāi)發(fā)人員將更容易擴(kuò)充IIS 7 和網(wǎng)站應(yīng)用程序的功能，甚至能自行以.NET編寫(xiě)管理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)。、

　　來(lái)源：http://blog.joycode.com/ghj/archive/2008/07/25/115200.aspx