99久久婷婷,日本免费在线观看,xxx在线观看

　　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的底層機(jī)制并對請求(request)是怎么從Web 服務(wù)器傳送到ASP.NET運行時有所了解。通過對底層機(jī)制的了解，可以讓我們對 ASP.NET 有更深的理解。

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

　　對圖的解釋：

　　IIS 5.x 一個顯著的特征就是 Web Server 和真正的 ASP.NET Application 的分離。作為 Web Server 的IIS運行在一個名為 INETInfo.exe 的進(jìn)程上，INETInfo.exe 是一個Native Executive，并不是一個托管的程序，而我們真正的 ASP.NET Application 則是運行在一個叫做 ASP NET_wp 的 Worker Process 上面，在該進(jìn)程初始化的時候會加載CLR，所以這是一個托管的環(huán)境。

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

　　IIS 5 模式的特點：

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

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

　　3、最后，由于 IIS 和 Application 運行在他們各自的進(jìn)程中，他們之間的通信必須采用特定的通信機(jī)制。本質(zhì)上 IIS 所在的 INETInfo 進(jìn)程和 Worker Process 之間的通信是同一臺機(jī)器不同進(jìn)程的通信（local interprocess communications），處于 Performance 的考慮，他們之間采用基于 Named pipe 的通信機(jī)制。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 中進(jìn)行，在IIS 6中，這種工作被移植到 Kernel Mode中進(jìn)行，所有的這一切都是通過一個新的組件 — 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 中維護(hù)著 Application Pool 和 Worker Process 的Mapping。WAS（Web Administrative Service）根據(jù)這樣一個 mapping，將存在于某個 Application Pool Queue 的 request 傳遞到對應(yīng)的 Worker Process (如果沒有，就創(chuàng)建這樣一個進(jìn)程)。在 Worker Process 初始化的時候，加載 ASP.NET ISAPI，ASP.NET ISAPI 進(jìn)而加載 CLR。最后的流程就和 IIS 5.x 一樣了：通過 AppManagerAppDomainFactory 的 Create 方法為 Application 創(chuàng)建一個 Application Domain；通過 ISAPIRuntime 的 ProcessRequest 處理 Request，進(jìn)而將流程進(jìn)入到 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 聯(lián)系 WAS 獲取配置信息。

　　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 進(jìn)程中又是如果處理的呢？ IIS 7 的應(yīng)用程序池的托管管道模式分兩種：經(jīng)典和集成。這兩種模式下處理策略各不相同。

　　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，也就是 ASP NET_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）的角色，進(jìn)入了 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ā)人員將更容易擴(kuò)充 IIS 7 和網(wǎng)站應(yīng)用程序的功能，甚至能自行以 .NET 編寫管理 IIS 7 的程序（例如以程序控制 IIS 7 建置網(wǎng)站或虛擬目錄）。