MVC源碼解析 - 進入CLR

這一篇是轉載自湯姆大叔的一篇隨筆.

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

IIS5核心特徵是：IIS是容許在一個叫InetInfo.exe的進程上的，因此不管是aspx頁面仍是html頁面都是經過這個進程處理的，其中，因爲aspx頁面擴展名映射到了aspnet ISAPI.DLL上，因此若是頁面是aspx的話，aspnet ISAPI.DLL則建立aspnet_wp這個Worker Process，並在初始化的時候加載CLR，因此這是一個託管的環境。

 

須要注意的幾點是：

1. 同一臺服務器只能運行一個 aspnet_wp 進程，也就是說全部的ASP.NET Web Application都在同一個Worker Process 中，可是不意味着他們共享同一個context和數據庫， ASP.NET裏有個AppDomain的概念，每一個站點或虛擬目錄都對應一個單獨的AppDomain，每一個AppDomain是隔離的，有本身獨立的context上下文，因此安全沒問題，因此咱們的結論是：ASP.NET程序是繼續AppDomain的，而不是基於Process的。
2. ASP.NET  ISAPI 不但負責建立 aspnet_wp Worker Process，並且負責監控該進程，若是檢測到 aspnet_wp 的 Performance 下降到某個設定的下限，ASP.NET  ISAPI 將結束掉該進程，在Request來了之後，ASP.NET ISAPI 將從新建立新的 aspnet_wp Worker Process。
3. 因爲 IIS 和 Application 運行在他們各自的進程中，他們之間的通訊必須採用特定的通訊機制。因爲之間的通訊是同機器不一樣進程的通訊（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 的變量。

IIS 6 的 ASP.net 請求處理過程

IIS6和IIS5有3個很是不一樣的地方：接受請求（Http.sys），應用程序池（Application Pool），w3wp.exe Worker Process。

在IIS5裏，InetInfo.exe附件監聽並處理請求（Request），但在IIS6裏，服務器是經過一個新組件Http.sys來接受請求（Request）。

 

Http.sys接收到http請求的時候，它會根據IIS中的 Metabase 查看該基於該 Request 的 Application 屬於哪一個Application Pool， 若是該Application Pool不存在，則建立之。不然直接將 request 發到對應Application Pool 的 Queue中。

 

每一個 Application Pool 對應着一個Worker Process：w3wp.exe。在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。

 

注意：IIS5和IIS6還有一個區別是，在IIS5裏ASP.NET ISAPI建立aspnet_wp Worker Process，進而加載CLR，但在IIS6裏是w3wp經過Application Pool的map關係運行之後，才加載ASP.NET ISAPI，而後加載CLR。

 

IIS 7  的 ASP.net 請求處理過程

 

步驟 1 到 6 ，是處理應用啓動，啓動好後，之後就不須要再走這個步驟了，上圖的8個步驟分別以下：

 

1. HTTP.sys監聽攔截客戶端請求開始處理。
2. HTTP.sys經過配置信息聯繫WAS獲取相關信息。
3. WAS 向配置存儲中心請求配置信息。applicationHost.config。
4. WWW 服務接受到配置信息，配置信息指相似應用程序池配置信息，站點配置信息等等。
5. WWW 服務使用配置信息去配置 HTTP.sys 處理策略。
6. WAS爲這個請求對應的應用程序池（Application Pool）開啓W3WP Worker Process。
7. W3WP Worker Process處理之後，將Response返回給HTTP.sys。
8. 客戶端接受到Response內容。

 

W3WP.exe 進程中又是若是處理得呢？？ 取決於IIS 7 的應用程序池託管管道模式是什麼，IIS7目前有2個模式： 經典模式和集成模式。兩種模式下的處理方式是不同，看以下區別：

IIS7經典模式：

 

IIS7的經典模式和IIS6的處理方式是同樣的,用戶發送HTTP Request請求之後， IIS會先行處理，IIS會根據HTTP Request的類型進行篩選，若是是HTML 靜態網頁就由 IIS 自行處理，若是不是，就根據具體要求的內容類型，分派給各自的 IIS ISAPI extension；若是要求的內容類型是 ASP.NET，就分派給負責處理 ASP.NET 的 IIS ISAPI extension，也就是 aspnet_isapi.dll，而後再進入CLR。

 

IIS7集成模式：

 

IIS7集成模式是一個偉大的改進，已經預加載了CLR（不在依靠以前IIS版本的aspnet_ISPAI.DLL），也就是說全部的HTTP Request請求都要通過ASP.NET來處理（包括html, php等），也由於 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版本進入CLR的方式是不同的，其中IIS版本之間最大的改變時：

1. IIS5 到 IIS6 的改進，主要是 HTTP.sys 的改進。
2. IIS6 到 IIS7 的改進，主要是 ISAPI 的改進。

轉自:

　　MVC以前的那些事

目錄已同步