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 模式的特點:
首先,同一臺主機上在同一時間只能運行一個 aspnet_wp 進程,每個基于虛擬目錄的 ASP.NET Application 對應(yīng)一個 Application Domain ,也就是說每個 Application 都運行在同一個 Worker Process 中,Application之間的隔離是基于 Application Domain 的,而不是基于Process的。 其次,ASP.NET ISAPI 不但負責(zé)創(chuàng)建 aspnet_wp Worker Process,而且負責(zé)監(jiān)控該進程,如果檢測到 aspnet_wp 的 Performance 降低到某個設(shè)定的下限,ASP.NET ISAPI 會負責(zé)結(jié)束掉該進程。當(dāng) aspnet_wp 結(jié)束掉之后,后續(xù)的 Request 會導(dǎo)致ASP.NET ISAPI 重新創(chuàng)建新的 aspnet_wp Worker Process。 最后,由于 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 來負責(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中。
新聞熱點
疑難解答
圖片精選