比較IIS5、IIS6、IIS7的ASP.net請求處理過程

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

        絕大多數的人只熟悉高層的框架如 WebForms 和 WebServices 這些都在ASPNET層次結構在最高層

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

　　IIS 的 請求處理過程

　　

IIS 的請求處理過程

　　對圖的解釋

　　IIS x 一個顯著的特征就是 Web Server 和真正的 ASPNET Application 的分離作為 Web Server 的IIS運行在一個名為 InetInfoexe 的進程上InetInfoexe 是一個Native Executive並不是一個托管的程序而我們真正的 ASPNET Application 則是運行在一個叫做 aspnet_wp 的 Worker Process 上面在該進程初始化的時候會加載CLR所以這是一個托管的環境

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

　　IIS 模式的特點

　　首先同一台主機上在同一時間只能運行一個 aspnet_wp 進程每個基於虛擬目錄的 ASPNET Application 對應一個 Application Domain 也就是說每個 Application 都運行在同一個 Worker Process 中Application之間的隔離是基於 Application Domain 的而不是基於Process的
　
　　其次ASPNET  ISAPI 不但負責創建 aspnet_wp Worker Process而且負責監控該進程如果檢測到 aspnet_wp 的 Performance 降低到某個設定的下限ASPNET  ISAPI 會負責結束掉該進程當 aspnet_wp 結束掉之後後續的 Request 會導致ASPNET ISAPI 重新創建新的 aspnet_wp Worker Process

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

　　IIS 的 請求處理過程

　　

IIS 的 請求處理過程

　　對圖的解釋

　　IIS x 是通過 InetInfoexe 監聽 Request 並把Request分發到Work Process換句話說在IIS x中對Request的監聽和分發是在User Mode中進行在IIS 中這種工作被移植到kernel Mode中進行所有的這一切都是通過一個新的組件httpsys 來負責
　
　　注為了避免用戶應用程序訪問或者修改關鍵的操作系統數據windows提供了兩種處理器訪問模式用戶模式（User Mode）和內核模式（Kernel Mode）一般地用戶程序運行在User mode下而操作系統代碼運行在Kernel Mode下Kernel Mode的代碼允許訪問所有系統內存和所有CPU指令
　
　　在User Mode下httpsys接收到一個基於 aspx 的http request然後它會根據IIS中的 Metabase 查看該基於該 Request 的 Application 屬於哪個Application Pool 如果該Application Pool不存在則創建之否則直接將 request 發到對應Application Pool 的 Queue中
　
　　每個 Application Pool 對應著一個Worker Processwwpexe毫無疑問他是運行在User Mode下的在IIS Metabase 中維護著 Application Pool 和worker process的MappingWAS（Web Administrative service）根據這樣一個mapping將存在於某個Application Pool Queue的request 傳遞到對應的worker process（如果沒有就創建這樣一個進程）在 worker process 初始化的時候加載ASPNET ISAPIASPNET ISAPI 進而加載CLR最後的流程就和IIS x一樣了通過AppManagerAppDomainFactory 的 Create方法為 Application 創建一個Application Domain通過 ISAPIRuntime 的 ProcessRequest處理Request進而將流程進入到ASPNET Http Runtime Pipeline

　　IIS   的 請求處理過程

　　IIS 站點啟動並處理請求的步驟如下圖

　　步驟 到 是處理應用啟動啟動好後以後就不需要再走這個步驟了

　　

　　

IIS   的 請求處理過程

　　上圖的個步驟分別如下

　　當客戶端浏覽器開始HTTP 請求一個WEB 服務器的資源時HTTPsys 攔截到這個請求
HTTPsys contacts WAS to obtain information from the configuration store

　　WAS 向配置存儲中心請求配置信息nfig
WWW 服務接受到配置信息配置信息指類似應用程序池配置信息站點配置信息等等
WWW 服務使用配置信息去配置 HTTPsys 處理策略
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 HTTPsys

　　客戶端接受到處理結果信息

　　WWPexe 進程中又是如果處理得呢？？ IIS 的應用程序池的托管管道模式分兩種 經典和集成 這兩種模式下處理策略各不相通

　　IIS 以及 IIS 經典模式的托管管道的架構

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

　　

　　

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

　　IIS 應用程序池的 托管管道模式  經典  模式也是這樣的工作原理 這種模式是兼容IIS 的方式 以減少升級的成本

　　IIS  應用程序池的 托管管道模式  集成模式

　　

　　

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

　　小結

　　IIS 到 IIS 的改進主要是 HTTPsys 的改進

　　IIS 到 IIS 的改進主要是 ISAPI 的改進

From:http://tw.wingwit.com/Article/program/net/201311/13216.html