IIS 處理.net頁面內部運行機制

　　ASP.NET是一個很是強大的構建Web應用的平臺，它提供了極大的靈活性和能力以至於能夠用它來構建全部類型的Web應用。

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

　　這篇文章的資料收集整理自各類微軟公開的文檔，經過比較 IIS五、IIS六、IIS7 這三代 IIS 對請求的處理過程， 讓咱們熟悉 ASP.NET的底層機制並對請求(request)是怎麼從Web服務器傳送到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，因此這是一個託管的環境。

　　ISAPI： 指可以處理各類後綴名的應用程序。 ISAPI 是下面單詞的簡寫 ：Internet Server Application Programe Interface，互聯網服務器應用程序接口。

　　IIS 5 模式的特色：

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

　　二、其次，ASP.NET  ISAPI 不但負責建立 aspnet_wp Worker Process，並且負責監控該進程，若是檢測到 aspnet_wp 的 Performance 下降到某個設定的下限，ASP.NET  ISAPI 會負責結束掉該進程。當 aspnet_wp 結束掉以後，後續的 Request 會致使 ASP.NET ISAPI 從新建立新的 aspnet_wp Worker Process。

　　三、最後，因爲 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 請求處理過程

　　對圖的解釋：

　　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 請求處理過程

　　IIS7 站點啓動並處理請求的步驟以下圖：　　

　　步驟 1 到 6 ，是處理應用啓動，啓動好後，之後就不須要再走這個步驟了。

　　上圖的8個步驟分別以下：

　　一、當客戶端瀏覽器開始 HTTP 請求一個WEB 服務器的資源時，HTTP.sys 攔截到這個請求。

　　二、HTTP.sys 聯繫 WAS 獲取配置信息。

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

　　四、WWW 服務接收到配置信息，配置信息指相似應用程序池配置信息，站點配置信息等等。

　　五、WWW 服務使用配置信息去配置 HTTP.sys 處理策略。

　　六、WAS starts a worker process for the application pool to which the request was made.

　　七、The worker process processes the request and returns a response to HTTP.sys.

　　八、客戶端接受處處理結果信息。

　　W3WP.exe 進程中又是若是處理的呢？ IIS 7 的應用程序池的託管管道模式分兩種： 經典和集成。這兩種模式下處理策略各不相同。

　　IIS 6 以及 IIS7 經典模式的託管管道的架構

　　在 IIS7 以前，ASP.NET 是以 IIS ISAPI extension 的方式外加到 IIS，其實包括 ASP 以及 PHP，也都以相同的方式配置（PHP 在 IIS 採用了兩種配置方式，除了 IIS ISAPI extension 的方式，也包括了 CGI 的方式，系統管理者能選擇 PHP 程序的執行方式），所以客戶端對 IIS 的 HTTP 請求會先經由 IIS 處理，而後 IIS 根據要求的內容類型，若是是 HTML 靜態網頁就由 IIS 自行處理，若是不是，就根據要求的內容類型，分派給各自的 IIS ISAPI extension；若是要求的內容類型是 ASP.NET，就分派給負責處理 ASP.NET 的 IIS ISAPI extension，也就是 aspnet_isapi.dll。下圖是這個架構的示意圖。

　　IIS 7 應用程序池的託管管道模式「經典」模式也是這樣的工做原理。這種模式是兼容 IIS 6 的方式， 以減小升級的成本。

　　IIS6 的執行架構圖，以及 IIS7  應用程序池配置成經典模式的執行架構圖

　　IIS  7 應用程序池的託管管道模式 — 集成模式

　　而 IIS 7 徹底整合 .NET 以後，架構的處理順序有了很大的不一樣（以下圖），最主要的緣由就是 ASP.NET 從 IIS 插件（ISAPI extension）的角色，進入了 IIS 核心，並且也能以 ASP.NET 模塊負責處理 IIS 7 的諸多類型要求。這些 ASP.NET 模塊不僅能處理 ASP.NET 網頁程序，也能處理其餘如 ASP 程序、PHP 程序或靜態 HTML 網頁，也由於 ASP.NET 的諸多功能已經成爲 IIS 7 的一部份，所以 ASP 程序、PHP 程序或靜態 HTML 網頁等類型的要求，也能使用像是 Forms 認證（Forms Authentication）或輸出緩存（Output Cache）等 ASP.NET 2.0 的功能（但須修改 IIS 7 的設定值）。也由於 IIS 7 容許自行以 ASP.NET API 開發並加入模塊，所以 ASP.NET 網頁開發人員將更容易擴充 IIS 7 和網站應用程序的功能，甚至能自行以 .NET 編寫管理 IIS 7 的程序（例如以程序控制 IIS 7 建置網站或虛擬目錄）。

IIS 7 的執行架構圖（集成託管信道模式下的架構）

小結

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

　　IIS6 到 IIS7 的改進，主要是 ISAPI 的改進。

　　參考資料：

　　ASP.NET Process Model之一：IIS 和 ASP.NET ISAPI

　　http://www.cnblogs.com/artech/archive/2007/09/09/887528.html

　　ASP.NET Internals – IIS and the Process Model

　　http://dotnetslackers.com/articles/iis/ASPNETInternalsIISAndTheProcessModel.aspx

　　模組化的IIS 7 與.NET 能力整合

　　http://www.microsoft.com/taiwan/technet/columns/profwin/33-iis7-componentization-integration.mspx

　　Introduction to IIS 7.0 Architecture

　　http://learn.iis.net/page.aspx/101/introduction-to-iis7-architecture/