| 導購 | 订阅 | 在线投稿
分享
 
 
 

IIS5 IIS6 IIS7的ASP.net 請求處理過程比較(1)

來源:互聯網  2008-08-01 06:24:15  評論

asp.net是一個非常強大的構建Web應用的平台,它提供了極大的靈活性和能力以致于可以用它來構建所有類型的Web應用。

絕大多數的人只熟悉高層的框架如: WebForms和 WebServices --這些都在ASP.NET層次結構在最高層。

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

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

IIS5 IIS6 IIS7的ASP.net 請求處理過程比較(1)

對圖的解釋:

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,所以這是一個托管的環境。

ISAPI:指能夠處理各種後綴名的應用程序。 ISAPI是下面單詞的簡寫:Internet Server Application Programe Interface,互聯網服務器應用程序接口。

IIS 5 模式的特點:

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

2、其次,ASP.NET ISAPI不但負責創建aspnet_wp Worker Process,而且負責監控該進程,如果檢測到aspnet_wp的 Performance降低到某個設定的下限,ASP.NET ISAPI會負責結束掉該進程。當aspnet_wp結束掉之後,後續的Request會導致ASP.NET ISAPI重新創建新的aspnet_wp Worker Process。

3、最後,由于IIS和 Application運行在他們各自的進程中,他們之間的通信必須采用特定的通信機制。本質上IIS所在的InetInfo進程和Worker Process之間的通信是同一台機器不同進程的通信(local interprocess communications),處于Performance的考慮,他們之間采用基于Named pipe的通信機制。ASP.NET ISAPI和Worker Process之間的通信通過他們之間的一組Pipe實現。同樣處于Performance的原因,ASP.NET ISAPI通過異步的方式將Request傳到Worker Process並獲得Response,但是Worker Process則是通過同步的方式向ASP.NET ISAPI獲得一些基于Server的變量。

IIS6 的 ASP.net 請求處理過程

IIS5 IIS6 IIS7的ASP.net 請求處理過程比較(1)

對圖的解釋:

IIS 5.x是通過InetInfo.exe監聽Request並把Request分發到Work Process。換句話說,在IIS 5.x中對Request的監聽和分發是在User Mode中進行,在IIS 6中,這種工作被移植到kernel Mode中進行,所有的這一切都是通過一個新的組件:http.sys來負責。

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

在User Mode下,http.sys接收到一個基于aspx的http request,然後它會根據IIS中的Metabase查看該基于該Request的 Application屬于哪個Application Pool,如果該Application Pool不存在,則創建之。否則直接將request發到對應Application Pool的 Queue中。

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

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

  asp.net是一個非常強大的構建Web應用的平台,它提供了極大的靈活性和能力以致于可以用它來構建所有類型的Web應用。   絕大多數的人只熟悉高層的框架如: WebForms和 WebServices --這些都在ASP.NET層次結構在最高層。   這篇文章的資料收集整理自各種微軟公開的文檔,通過比較IIS5、IIS6、IIS7這三代IIS對請求的處理過程,讓我們熟悉ASP.NET的底層機制並對請求(request)是怎麽從Web服務器傳送到ASP.NET運行時有所了解。通過對底層機制的了解,可以讓我們對ASP.net有更深的理解。   IIS 5 的 ASP.net 請求處理過程 [url=/bbs/detail_1804869.html][img]http://image.wangchao.net.cn/it/1323407599209.gif[/img][/url]   對圖的解釋:   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,所以這是一個托管的環境。   ISAPI:指能夠處理各種後綴名的應用程序。 ISAPI是下面單詞的簡寫:Internet Server Application Programe Interface,互聯網服務器應用程序接口。   IIS 5 模式的特點:   1、首先,同一台主機上在同一時間只能運行一個aspnet_wp進程,每個基于虛擬目錄的ASP.NET Application對應一個Application Domain ,也就是說每個Application都運行在同一個Worker Process中,Application之間的隔離是基于Application Domain的,而不是基于Process的。   2、其次,ASP.NET ISAPI不但負責創建aspnet_wp Worker Process,而且負責監控該進程,如果檢測到aspnet_wp的 Performance降低到某個設定的下限,ASP.NET ISAPI會負責結束掉該進程。當aspnet_wp結束掉之後,後續的Request會導致ASP.NET ISAPI重新創建新的aspnet_wp Worker Process。   3、最後,由于IIS和 Application運行在他們各自的進程中,他們之間的通信必須采用特定的通信機制。本質上IIS所在的InetInfo進程和Worker Process之間的通信是同一台機器不同進程的通信(local interprocess communications),處于Performance的考慮,他們之間采用基于Named pipe的通信機制。ASP.NET ISAPI和Worker Process之間的通信通過他們之間的一組Pipe實現。同樣處于Performance的原因,ASP.NET ISAPI通過異步的方式將Request傳到Worker Process並獲得Response,但是Worker Process則是通過同步的方式向ASP.NET ISAPI獲得一些基于Server的變量。   IIS6 的 ASP.net 請求處理過程 [url=/bbs/detail_1804869.html][img]http://image.wangchao.net.cn/it/1323407599948.gif[/img][/url]   對圖的解釋:   IIS 5.x是通過InetInfo.exe監聽Request並把Request分發到Work Process。換句話說,在IIS 5.x中對Request的監聽和分發是在User Mode中進行,在IIS 6中,這種工作被移植到kernel Mode中進行,所有的這一切都是通過一個新的組件:http.sys來負責。   注:爲了避免用戶應用程序訪問或者修改關鍵的操作系統數據,windows提供了兩種處理器訪問模式:用戶模式(User Mode)和內核模式(Kernel Mode)。一般地,用戶程序運行在User mode下,而操作系統代碼運行在Kernel Mode下。Kernel Mode的代碼允許訪問所有系統內存和所有CPU指令。   在User Mode下,http.sys接收到一個基于aspx的http request,然後它會根據IIS中的Metabase查看該基于該Request的 Application屬于哪個Application Pool,如果該Application Pool不存在,則創建之。否則直接將request發到對應Application Pool的 Queue中。   每個Application Pool對應著一個Worker Process:w3wp.exe,毫無疑問他是運行在User Mode下的。在IIS Metabase中維護著Application Pool和worker process的Mapping。WAS(Web Administrative service)根據這樣一個mapping,將存在于某個Application Pool Queue的request傳遞到對應的worker process(如果沒有,就創建這樣一個進程)。在worker process初始化的時候,加載ASP.NET ISAPI,ASP.NET ISAPI進而加載CLR。最後的流程就和IIS 5.x一樣了:通過AppManagerAppDomainFactory的 Create方法爲Application創建一個Application Domain;通過ISAPIRuntime的 ProcessRequest處理Request,進而將流程進入到ASP.NET Http Runtime Pipeline。   IIS 7 的 ASP.net 請求處理過程
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
王朝網路微信公眾號
微信掃碼關註本站公眾號 wangchaonetcn
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有