IIS5IIS6IIS7的ASP.net請求處理過程比較

2010-08-28 10:53:37來源:西部e網(wǎng)作者:

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

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

  這篇文章的資料收集整理自各種微軟公開的文檔,通過比較IIS5、IIS6、IIS7這三代IIS對請求的處理過程,讓我們熟悉ASP.NET的底層機制并對請求(request)是怎么從Web服務(wù)器傳送到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,所以這是一個托管的環(huán)境。

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

  IIS 5 模式的特點:

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

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

  3、最后,由于IIS和 Application運行在他們各自的進程中,他們之間的通信必須采用特定的通信機制。本質(zhì)上IIS所在的InetInfo進程和Worker Process之間的通信是同一臺機器不同進程的通信(local interprocess communications),處于Performance的考慮,他們之間采用基于Named pipe的通信機制。ASP.NET ISAPI和Worker Process之間的通信通過他們之間的一組Pipe實現(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中進行,在IIS 6中,這種工作被移植到kernel Mode中進行,所有的這一切都是通過一個新的組件:http.sys來負(fù)責(zé)。

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

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

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

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

  IIS7站點啟動并處理請求的步驟如下圖:

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


  上圖的8個步驟分別如下:

  1、當(dāng)客戶端瀏覽器開始HTTP請求一個WEB服務(wù)器的資源時,HTTP.sys攔截到這個請求。

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

  3、WAS向配置存儲中心請求配置信息。applicationHost.config。

  4、WWW服務(wù)接受到配置信息,配置信息指類似應(yīng)用程序池配置信息,站點配置信息等等。

  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進程中又是如果處理得呢?? 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,其實包括ASP以及PHP,也都以相同的方式配置(PHP在 IIS采用了兩種配置方式,除了IIS ISAPI extension的方式,也包括了CGI的方式,系統(tǒng)管理者能選擇PHP程序的執(zhí)行方式),因此客戶端對IIS的 HTTP請求會先經(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ò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)的角色,進入了IIS核心,而且也能以ASP.NET模塊負(fù)責(zé)處理IIS 7 的諸多類型要求。這些ASP.NET模塊不只能處理ASP.NET網(wǎng)頁程序,也能處理其他如ASP程序、PHP程序或靜態(tài)HTML網(wǎng)頁,也因為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è)定值)。也因為IIS 7 允許自行以ASP.NET API開發(fā)并加入模塊,因此ASP.NET網(wǎng)頁開發(fā)人員將更容易擴充IIS 7 和網(wǎng)站應(yīng)用程序的功能,甚至能自行以.NET編寫管理IIS 7 的程序(例如以程控IIS 7 以建置網(wǎng)站或虛擬目錄)。


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

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

  IIS6到 IIS7的改進,主要是ISAPI的改進。、

  來源:http://blog.joycode.com/ghj/archive/2008/07/25/115200.aspx

關(guān)鍵詞:ASP.net

贊助商鏈接: