|
|
- ASP.NET Process Model之一：IIS 和 ASP.NET ISAPI
- ASP.NET Process Model之二：ASP.NET Http Runtime Pipeline[上篇]
- ASP.NET Process Model之二：ASP.NET Http Runtime Pipeline[下篇]
前幾天有一個(gè)朋友在MSN上問(wèn)我“ASP.NET 從最初的接收到Http request到最終生成Response的整個(gè)流程到底是怎樣的？”我覺(jué)得這個(gè)問(wèn)題涉及到IIS和ASP.NETASP.NET Runtime的處理模型的問(wèn)題，并不是三言兩語(yǔ)就能說(shuō)清楚的，所以決定寫(xiě)這樣一篇介紹IIS和ASP.NET Runtime Process Model的文章，談?wù)勎覍?duì)此的一個(gè)粗淺的認(rèn)識(shí)，如果有什么不對(duì)的地方，希望大家及時(shí)指正。
這篇文章大體分為兩個(gè)部分，第一部分我將談?wù)処IS的兩個(gè)不同的版本—IIS 5.x 和 IIS 6（雖然IIS 7已經(jīng)Release很長(zhǎng)時(shí)間了，而且較之前兩個(gè)版本發(fā)生了非常大的變化，由于本人缺乏對(duì)IIS 7深入的了解，所以在這里就不再介紹了，不過(guò)以后我將這方面的內(nèi)容補(bǔ)上）的處理模型：IIS如何監(jiān)聽(tīng)來(lái)自外界的Http request，如何根據(jù)ISAPI Extension Mapping將對(duì)于不同Resource的請(qǐng)求分發(fā)給不同的ISAPI Extension，基于ASP.NET Resource的ASP.NET ISAPI如何將Request傳遞給ASP.NET Runtime 環(huán)境。第二部分將著重介紹在一個(gè)托管的ASP.NET Runtime 環(huán)境對(duì)傳入的Http request的處理過(guò)程。我們先來(lái)看看IIS 5.x和IIS 6的處理過(guò)程。
一、IIS 5.x based Process Model
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)境。我們接下來(lái)將談?wù)?a href=/itjie/ASPjishu/ target=_blank class=infotextkey>ASPNET_wp如何創(chuàng)建，ASPNET_wp和INETInfo.exe如何進(jìn)行通信，以及簡(jiǎn)單介紹在ASPNET_wp中，如何將Request 導(dǎo)入ASP.NET Rutime Pipeline。
我們通過(guò)創(chuàng)建虛擬目錄將資源Host到IIS下，原則上，我們可以通過(guò)IIS訪問(wèn)置于虛擬目錄下的所有Resource，這部?jī)H僅包含一些靜態(tài)資源文件，比如圖片、純Html文件、CSS、JS等等，也包含一些需要?jiǎng)討B(tài)執(zhí)行的文件，比如ASPx，asmx等等，我們還可以將Remoting和WCF Service Host到IIS下。對(duì)于這些靜態(tài)的文件，IIS直接提取對(duì)應(yīng)的文件將其作為Http Response返回給Client，但是對(duì)于這些需要進(jìn)一步處理的動(dòng)態(tài)執(zhí)行的文件，IIS必須將Request進(jìn)一步傳遞給對(duì)應(yīng)的處理程序，待處理程序執(zhí)行完畢獲得最終的Http Response通過(guò)IIS返回給Client。對(duì)于IIS來(lái)說(shuō)，這些處理程序通過(guò)ISAPI Extension來(lái)體現(xiàn)。對(duì)于基于ASP.NET的Resource，其對(duì)應(yīng)的ISAPI Extension為ASP.NET ISAPI，通過(guò)一個(gè)ASPNET_isapi.dll承載。IIS的Metadata database維護(hù)著一個(gè)稱為ISAPI Extension Mapping的數(shù)據(jù)表，負(fù)責(zé)將不同類型的Resource影射到對(duì)應(yīng)的ISAPI Extension。
上圖像我們展示了IIS 5.x如何處理一個(gè)基于ASP.NET Resource（以ASPx為例）的Http Request的大體流程。首先用戶通過(guò)Browser請(qǐng)求一個(gè)ASPx page，Brower向?qū)τ诘肳eb Server，也就是目標(biāo)主機(jī)的IIS。在上面我們提到過(guò)，IIS運(yùn)行在一個(gè)稱為INETInfo.exe的進(jìn)程中，INETInfo.exe是一個(gè)Native Executive，并非一個(gè)托管的程序。IIS分析Request的目標(biāo)資源文件的擴(kuò)展名（這里是ASPx），通過(guò)ISAPI Extension Mapping獲知對(duì)應(yīng)的ISPAI為ASP.NET ISAPI,于是加載ASPNET_isapi.dll。到此為止，該Request的處理交由ASP.NET ISAPI,處理。ASP.NET ISAPI會(huì)創(chuàng)建一個(gè)叫做ASPNET_wp.exe的Worker Process（如果該進(jìn)程不存在的話），在ASPNET_wp.exe初始化的時(shí)候會(huì)加載CLR，從而為ASP.NET Application創(chuàng)建一個(gè)托管的運(yùn)行環(huán)境，在CLR初始化的使用會(huì)加載兩個(gè)重要的dll：AppManagerAppDomainFactory和ISAPIRuntime。通過(guò)AppManagerAppDomainFactory的Create方法為Application創(chuàng)建一個(gè)Application Domain；通過(guò)ISAPIRuntime的ProcessRequest處理Request，進(jìn)而將流程拖入到ASP.NET Http Runtime Pipeline的范疇，ASP.NET Http Runtime Pipeline對(duì)Http Request的處理是一個(gè)相對(duì)復(fù)雜的過(guò)程，相關(guān)的介紹會(huì)放在本篇文章的下一部份。在這里我們可以把它看成是一個(gè)黑盒，它接管Request，最終生成Html。
這基本上就是整個(gè)處理流程，很簡(jiǎn)單。不過(guò)在這里有幾點(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的變量。
二、IIS 6 based Process Model
Reliability 和Performance永遠(yuǎn)不我們從事軟件開(kāi)發(fā)不變的主題。作為Host 基于Http Application的IIS來(lái)說(shuō)，這兩方面就顯得尤為重要了。我們從IIS 5.x到IIS 6 的演變，不難看出IIS 6在前一個(gè)版本基礎(chǔ)上所作的改進(jìn)也是基于這兩個(gè)方面。在介紹IIS 6的處理模型之前，我們先看看IIS 5.x都什么樣缺陷：
1. 首先從Performance上看，IIS和application運(yùn)行在不同的進(jìn)程中，雖然他們之間采用了基于Named Pipe的異步通信方式，但是一個(gè)基于進(jìn)程之間的通信對(duì)性能的影響確實(shí)不能從根本上解決。
2. 其次，從Reliability來(lái)考慮，一臺(tái)機(jī)器上只能運(yùn)行一個(gè)worker process，每個(gè)Application運(yùn)行在同一個(gè)進(jìn)程中，雖然基于Application Domain的隔離能提供一定的Reliability，但是一旦真?zhèn)€進(jìn)程崩潰，所有的Application都受影響。所以我們有時(shí)候需要提供一個(gè)基于Process的隔離性。
基于Reliability的改進(jìn)，IIS 6引入了Application Pool。顧名思義，Application Pool就是一個(gè)application的容器，在IIS 6中，我們可以創(chuàng)建若干Application Pool，在創(chuàng)建Web Application的時(shí)候，我們?yōu)樗付ㄒ粋€(gè)既定的application pool。在運(yùn)行的時(shí)候，一個(gè)Application對(duì)應(yīng)一個(gè)Worker Process：w3wp.exe。也就是說(shuō)，和前一個(gè)版本的IIS不同的是，對(duì)于IIS 6來(lái)說(shuō)，同一臺(tái)機(jī)器上可以同時(shí)運(yùn)行多個(gè)Worker Process，每個(gè)Worker Process中的每個(gè)Application domain對(duì)應(yīng)一個(gè)Application。這樣，Application之間不但能提供Application Domain級(jí)別的隔離，你也可以將不同的Application置于不同的Application Pool中，從而基于Process級(jí)別的隔離。對(duì)于Host 一些重要的Application來(lái)說(shuō)，這樣的方式可以提供很好的Reliability。
在Performance方面，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指令。關(guān)于User Mode和Kernel Mode以及一些Windows底層的一些內(nèi)容，推薦大家看看《Microsoft Windows Internal》Four Edition， Authored by Mark E.Russinovich & David A. Solomon。
上圖基本上演示了IIS 6整個(gè)處理過(guò)程。在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中。我上面已經(jīng)說(shuō)了，每個(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。
對(duì)IIS Process Model部分就介紹到這里，在下部分中，我將介紹ASP.NET Http Runtime Pipeline。
NET技術(shù)：ASP.NET Process Model之一：IIS 和 ASP.NET ISAPI，轉(zhuǎn)載需保留來(lái)源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
