引言
我查閲過不少Asp.Net的書籍，發現大多數作者都是站在一個比較高的層次上講解Asp.Net。他們耐心、細緻地告訴你如何一步步拖放控件、設置控件屬性、編寫CodeBehind代碼，以實現某個特定的功能。
這種做法，實際上是回答了“如何去做”的問題，卻沒有回答“為什麼可以這樣做”的問題。
儘管我很推崇 悉江華 先生的《聖殿祭祀的Asp.Net開發詳解》一書，但當我翻看了一下其對角色(Role) 和 用户(Member)的講解時，我決定跳過去直接讀後面的章節。因為我發現他也隨了大流，對這部分的講解停留在“如何去做”的層面上。我相信像悉先生 這樣的牛人是不可能不瞭解底層運作原理的，僅僅是因為那本書原本就已經很厚了吧。
當你按“如何去做”所講解的內容去開發進程的時候，對於你的用户，你仍是一名程序員；但對於實現了MembershipProvider 和 RoleProvider 抽象類的微軟開發人員來説，你已經成了他們的一個用户。
NOTE：我既不反對一些作者只講解“如何去做”，也不反對你只學“如何去做”，這樣也有它的好處，就是可以快速開發。我只是建議多掌握一點底層知識，對一些問題會有更好的理解。
希望通過這一系列文章的講解，可以讓你更好的理解Asp.Net的運作原理和做以瞭解。
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 ，看看它到底是什麼樣子，請按下面的步驟進行：
  • 打開IIS。
  • 選擇隨意一個站點，鼠標右鍵，“屬性”。
  • 選擇“主目錄”選項卡。
  • 選擇“配置”。
你應該會看到如下的畫面：
圖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 還需要做一些其他的工作：
  • 從HTTP.SYS中獲取當前的Httq請求信息，並且將這些信息保存到 HttpWorkerRequest 類中。
  • 在相互隔離的應用進程域AppDomain中加載HttpRuntime。
  • 調用 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 中的流動方向
 
總結
本文中，我首先概要介紹了這系列文章將要為大家講述的主題。然後，我提出了部分程序員存在的一個問題：在一個比較高的層次上學習和使用Asp.Net。
隨後，我以一個訪問我個人空間首頁的例子，引出了本文主要講述的三個內容：
  • Http請求剛剛到達時IIS時，IIS 所做的工作。
  • Http請求的宿主環境。
  • Http管道。
希望這篇文章能給你帶來幫助。
相關推薦：