建站
咨詢
售后
建站咨詢
新聞中心
絕大多數(shù)的人只熟悉高層的框架如： WebForms 和 WebServices --這些都在ASP.NET層次結(jié)構(gòu)在最高層。
成都創(chuàng)新互聯(lián)公司服務(wù)項(xiàng)目包括香洲網(wǎng)站建設(shè)、香洲網(wǎng)站制作、香洲網(wǎng)頁(yè)制作以及香洲網(wǎng)絡(luò)營(yíng)銷策劃等。多年來(lái)，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，香洲網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到香洲省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
這篇文章的資料收集整理自各種微軟公開(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)：
- 首先，同一臺(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的。
- 其次，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。
- 最后，由于 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。
當(dāng)前1/3頁(yè)
123下一頁(yè)
名稱欄目：各版本IIS下ASP.net請(qǐng)求處理過(guò)程分析第1/3頁(yè)
當(dāng)前地址：http://www.5511xx.com/article/dpeishi.html
