IIS是如何處理ASP.NET請求的

英文原文：Beginner’s Guide: How IIS Process ASP.NET Request

　　前言

　　每次服務器接受到請求，都要先經IIS處理。這不是一篇描述ASP.NE生命週期的文章，僅僅是關於IIS操做的。在咱們開始以前，先了解這些會有助於對全文的理解，同時歡迎反饋和建議。

　　什麼是Web Server?

　　每當咱們經過VS運行ASP.NET網站時，VS集成的ASP.NET引擎會響應各類請求，這個引擎的名字叫「WebDev.WebServer.exe」。

　　當咱們配置一個Web程序時，總會涉及到一個詞「Web Server」，它的功能即是會響應全部請求。

　　什麼是IIS？

　　IIS（Internet Information Server）是微軟Web Server的一種，用來配置ASP.NET站點。IIS擁有本身的ASP.NET處理引擎來處理請求，所以，當一個請求到達時，IIS接收並處理請求，而後返回內容。

　　請求處理過程

　　如今，你應能搞清楚Web Server和IIS的區別。如今咱們來看一下核心部分。在繼續以前，你須要搞清兩個概念：

　　一、工做進程（Worker Process）

　　二、應用程序池（Application Pool）

　　工做進程：在IIS中，工做進程（w3wp.exe）運行着ASP.NET應用程序，管理並響應全部的請求，ASP.NET全部的功能都運行在工做進程下，當請求到來時，工做進程會生成Request和Response相關的信息。簡而言之，工做進程就是ASP.NET程序的心臟。

　　應用程序池：應用程序池是工做進程的容器，一般用來隔開不一樣配置的工做進程。當一個程序出錯或進程資源回收時，其餘池中的程序不會受到影響。

　　注：當一個應用程序池包含多個工做進程時，被叫作「Web Garden」。

　　若是咱們看一下IIS 6.0的結構，就會發現，能夠把它分紅兩部分：

　　一、內核模塊（Kernel Mode）

　　二、用戶模塊（User Mode）

　　內核模式是從IIS 6.0被引入的，它包含了一個叫HTTP.SYS的文件，每當請求進來時，會首先觸發該文件的響應。

　　HTTP.SYS文件負責把請求傳入相應的應用程序池中。但HTTP.SYS如何知道應傳給哪一個應用程序池呢？固然不是隨機抽取，每當建立一個應用程序池，該池的ID就會生成並在HTTP.SYS文件中註冊，所以該文件才能肯定將請求往哪傳。

　　以上即是IIS處理請求的第一步。接着，咱們來看一下請求如何從HTTP.SYS傳入應用程序池。

　　在IIS的用戶模塊中，經過Web Admin Services (WAS)從HTTP.SYS接收請求，並傳入相應的應用程序池中。

　　當應用程序池接收到請求，會接着傳給工做進程（w3wp.exe），該進程檢查來請求的URL後綴以肯定加載哪一個ISAPI擴展。ASP.NET加載時會附帶本身的ISAPI擴展（aspnet_isapi.dll），以便在IIS中映射。

　　注意：若是先安裝了asp.net，而後再安裝IIS，就須要經過aspnet_regiis命令來註冊ASP.NET中的ISAPI擴展。

　　一旦工做進程加載了aspnet_isapi.dll, 就會構造一個HttpRuntime類，該類是應用程序的入口，經過ProcessRequest方法處理請求。

　　一旦這個方法被調用，一個HttpContext的實例就產生了。可經過HTTPContent.Current獲取到這個實例，且該實例會在整個生命週期中存活，咱們經過它能夠獲取到一些經常使用對象，如Request，Response，Session 等。

　　以後HttpRuntime會經過HttpApplicationFactory類加載一個HttpApplication對象。每一次請求都要穿過一堆HttpModule到達HttpHandler，以便被響應。而這些HttpModule就被配置在HttpApplication中。

　　有一個概念叫「Http管道」，被叫作管道是由於它包含了一系列的HttpModule，這些HttpModule攔截請求並將其導向相應的HttpHandler。咱們也可自定義HttpModule，以便在請求響應之間作點特別的處理。

　　HttpHandler是「Http管道」的終點。全部請求穿過HttpModule需抵達相應的HttpHandler，而後HttpHandler根據請求資源，產生並輸出內容。也正所以，咱們請求任何aspx頁面纔會獲得響應的Html內容。

　　結語

　　每當請求Web服務器上的某些信息時，該請求首先會到達Http.SYS, 而後Http.SYS將其發送到相應的應用程序池，應用程序池傳給工做進程並加載ISAPI擴展，而後HttpRuntime對象會被建立，並經過HttpModule和HttpHandler處理請求。

　　最後，ASP.NET頁面生命週期就開始了。

　　這只是大體描述IIS處理過程的文章，若是你想進一步瞭解相應細節，請點擊下面連接來進一步學習。

　　A low-level Look at the ASP.NET Architecture

　　IIS Architecture

　　本文翻譯自：Beginner’s Guide: How IIS Process ASP.NET Request

　　譯後小注：

　　一、若是在IIS配置完站點卻看不到「w3wp.exe」進程，只要用瀏覽器打開該站其中一個頁面，「w3wp.exe」進程就會出現了。

　　二、爲節省時間，直接引用了原圖，英文差的，小查一下字典應該沒啥問題。

 

Http請求處理流程概述

 

思考「爲何在地址欄輸入www.tracefact.net就能夠看到張子陽的我的空間？」，相似於思考「爲何蘋果是往地上掉不是往天上飄？」。對於普通訪問者來講，這就像天天太陽東邊升起西邊落下同樣是理所固然的；對於不少程序員來講，認爲這個與己無關，不過是系統管理員或者網管員的責任。畢竟，IIS是 Windows 的一個組件，又不是 Asp.Net 的一個組成部分。而實際上，從你輕拍回車到頁面呈如今你眼前的十分之一秒內，IIS和.Net Framework已經作了大量的幕後工做。

你可能以爲了解這些幕後工做是如何運做的可有可無，做爲程序員的你只要保證開發出的程序能夠高效地運行就能夠了。然而，在開發過程當中，你卻發現經常須要使用諸如 HttpContext 這樣的類。這個時候，你可曾思考過這些類的構成和類的實體是如何建立的？你可能簡單地回答：HttpContext表明當前請求的一個上下文環境。可你又知道IIS 、Framework、Asp.Net 是如何協同工做處理每一個Http請求、如何區分不一樣的請求、IIS、Framework、Asp.Net三者之間的數據如何流動麼？

回答上面這些問題，首先須要瞭解IIS是如何處理頁面請求的，這也是理解 Form驗證模式和Windows 驗證模式 的基礎。

Http請求剛剛到達服務器的時候

當服務器接收到一個 Http請求的時候，IIS 首先須要決定如何去處理這個請求（NOTE：服務器處理一個.htm頁面和一個.aspx頁面確定是不同的麼）。那IIS依據什麼去處理呢？―― 根據文件的後綴名。

服務器獲取所請求的頁面（NOTE：也能夠是文件，好比 jimmy.jpg）的後綴名之後，接下來會在服務器端尋找能夠處理這類後綴名的應用程序，若是IIS找不到能夠處理此類文件的應用程序，而且這個文件也沒有受到服務器端的保護（NOTE：一個受保護的例子就是 App_Code中的文件，一個不受保護的例子就是你的js腳本），那麼IIS將直接把這個文件返還給客戶端。

可以處理各類後綴名的應用程序，一般被稱爲 ISAPI 應用程序（NOTE：Internet Server Application Programe Interface，互聯網服務器應用程序接口）。雖然這 ISAPI 聽上去還挺氣派，也算是「應用程序」呢，但仔細看看它的全稱就明白了：它實際上只是一個接口，起到一個代理的做用，它的主要工做是映射所請求的頁面(文件)  和與此後綴名相對應的實際的處理程序。

讓咱們更進一步地看一下 ISAPI ，看看它究竟是什麼樣子，請按下面的步驟進行：

1. 打開IIS。
2. 選擇隨意一個站點，鼠標右鍵，「屬性」。
3. 選擇「主目錄」選項卡。
4. 選擇「配置」。

你應該會看到以下的畫面：

圖1. 應用程序配置

很清楚地就能夠看到，全部IIS所能處理，或者叫 ISAPI 所提供代理服務的 文件類型 及其相對應的實際的後臺處理程序都在這裏清楚地列出來了。

咱們找到 .aspx 的應用處理程序，而後點「編輯」，會出現下面的畫面：

圖2. 編輯.aspx文件的處理程序

 

一路看到這裏，能夠看出，全部的.aspx文件實際上都是由 aspnet_isapi.dll 這個程序來處理的，當IIS把對於.aspx頁面的請求提交給了aspnet_isapi.dll之後，它就再也不關心這個請求隨後是如何處理的了。如今咱們應該知道：Asp.Net 只是服務器(IIS)的一個組成部分而已，它是一個 ISAPI擴展。

這裏須要注意兩點：

• 當你修改「限制爲」後，能夠限制頁面(文件)只能以某種特定方式訪問
• 「確認文件是否存在」是實現 URL 地址映射的關鍵選項，我之後會專門講述。

理解宿主環境（Hosting）

從本質上講，Asp.Net 主要是由一系列的類組成，這些類的主要目的就是將Http請求轉變爲對客戶端的響應。HttpRuntime類是Asp.Net的一個主要入口，它有一個稱做 ProcessRequest 的方法，這個方法以一個 HttpWorkerRequest 類做爲參數。HttpRuntime 類幾乎包含着關於單個 Http請求的全部信息：所請求的文件、服務器端變量、QueryString、Http 頭信息 等等。Asp.Net 使用這些信息來加載、運行正確的文件，而且將這個請求轉換到輸出流中，通常來講，也就是HTML頁面。

NOTE：二般來講，也能夠是張圖片。

當 Web.config文件的內容發生改變 或者 .aspx文件發生變更的時候，爲了可以卸載運行在同一個進程中的應用程序（NOTE：卸載也是爲了從新加載），Http請求被分放在相互隔離的應用程序域中。

NOTE：可能你之前就聽過應用程序域，可是不瞭解怎麼回事，應用程序域就是 AppDomain。

對於IIS來講，它依賴一個叫作 HTTP.SYS 的內置驅動程序來監聽來自外部的 HTTP請求。在操做系統啓動的時候，IIS首先在HTTP.SYS中註冊本身的虛擬路徑。

NOTE：實際上至關於告訴HTTP.SYS哪些URL是能夠訪問的，哪些是不能夠訪問的。舉個簡單的例子：爲何你訪問不存在的文件會出現 404 錯誤呢？就是在這一步肯定的。

若是請求的是一個可訪問的URL，HTTP.SYS會將這個請求交給 IIS 工做者進程。

NOTE：IIS6.0中叫作 w3wp.exe，IIS5.0中叫作 aspnet_wp.exe。

每一個工做者進程都有一個身份標識 以及 一系列的可選性能參數。

NOTE：可選性能參數，是指諸如 回收機制的設置、超時時間設置 等等。

接下來進行的事情就是上一章節講述的 ISAPI 了。

NOTE：這部分的內容相關性比較強，爲了讓你們好理解，我最後仍是決定把 ISAPI 放到前面了，可能全系列完成的時候會再調整吧。

除了映射文件與其對應的處理程序之外，ISAPI 還須要作一些其餘的工做：

1. 從HTTP.SYS中獲取當前的Httq請求信息，而且將這些信息保存到 HttpWorkerRequest 類中。
2. 在相互隔離的應用程序域AppDomain中加載HttpRuntime。
3. 調用 HttpRuntime的ProcessRequest方法。

接下來纔是程序員一般編寫的代碼所完成的工做了，而後，IIS 接收返回的數據流，並從新返還給 HTTP.SYS，最後，HTTP.SYS 再將這些數據返回給客戶端瀏覽器。

OK，如今你看到張子陽的空間主頁了。

圖3.Asp.Net 的宿主環境

理解管道（Pipeline）

在前面兩章中，咱們在一個相對比較低的層次上討論了從發出Http請求到看到瀏覽器輸出這轉瞬即逝的十分之一秒內IIS和 Framework 所作的事情。可是咱們忽略了一個細節：程序員編寫的代碼是如何在這一過程當中銜接的，本章咱們就來看看這個問題。

當Http請求進入 Asp.Net Runtime之後，它的管道由託管模塊（NOTE：Managed Modules）和處理程序（NOTE：Handlers）組成，而且由管道來處理這個 Http請求。

圖4. 理解 Http 管道

咱們按編號來看一下這幅圖中的數據是如何流動的。

1. HttpRuntime將Http請求轉交給 HttpApplication，HttpApplication表明着程序員建立的Web應用程序。HttpApplication建立針對此Http請求的 HttpContext對象，這些對象包含了關於此請求的諸多其餘對象，主要是HttpRequest、HttpResponse、HttpSessionState等。這些對象在程序中能夠經過Page類或者Context類進行訪問。、

2. 接下來Http請求經過一系列Module，這些Module對Http請求具備徹底的控制權。這些Module能夠作一些執行某個實際工做前的事情。

3. Http請求通過全部的Module以後，它會被HttpHandler處理。在這一步，執行實際的一些操做，一般也就是.aspx頁面所完成的業務邏輯。可能你會以爲在建立.aspx頁面並無體會到這一過程，可是，你必定知道，.aspx 頁面繼承自Page類，咱們看一下Page類的簽名：

public class Page : TemplateControl, IHttpHandler{
    // 代碼省略
}

能夠看到，Page類實現了IHttpHandler接口，HttpHandler也是Http請求處理的最底層。

4.HttpHandler處理完之後，Http請求再一次回到Module，此時Module能夠作一些某個工做已經完成了以後的事情。

NOTE：注意我用紅色標識的字，而後回想一下：Asp.Net 中是否是有衆多的 Inserting 、Inserted 之類成對的事件？其實，這裏講述的就是爲何Asp.Net能夠將一個Insert操做分紅先後兩部分，而後再分別進行事件攔截的幕後原理。

若是咱們將注意力只集中在Http請求、HttpHandler和HttpModule上，不去考慮HttpContext和HttpApplication，那麼圖4.能夠簡化成下面這樣：

圖5.Http請求在HttpHandler 和 HttpModule 中的流動方向

 

本文連接轉自：http://blog.csdn.net/linux7985/article/details/44079993