我查閱過不少Asp.Net的書籍，發現大多數作者都是站在一個比較高的層次上講解Asp.Net。他們耐心、細致地告訴你如何一步步拖放控件、設置控件屬性、編寫CodeBehind代碼，以實現某個特定的功能。

       這種做法，實際上是回答了“如何去做”的問題，卻沒有回答“為什么可以這樣做”的問題。

       盡管我很推崇 悉江華 先生的《圣殿祭祀的Asp.Net開發詳解》一書，但當我翻看了一下其對角色(Role) 和 用戶(Member)的講解時，我決定跳過去直接讀后面的章節。因為我發現他也隨了大流，對這部分的講解停留在“如何去做”的層面上。我相信像悉先生 這樣的牛人是不可能不了解底層運作原理的，僅僅是因為那本書原本就已經很厚了吧。

        當你按“如何去做”所講解的內容去開發程序的時候，對于你的用戶，你仍是一名程序員；但對于實現了MembershipProvider 和 RoleProvider 抽象類的微軟開發人員來說，你已經成了他們的一個用戶。

 

        你可能覺得了解這些幕后工作是如何運作的無關緊要，作為程序員的你只要保證開發出的程序可以高效地運行就可以了。然而，在開發過程中，你卻發現常常需要使用諸如 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：卸載也是為了重新加載），Http請求被分放在相互隔離的應用程序域中。

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

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

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

接下來進行的事情就是上一章節講述的 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類的簽名：

    // 代碼省略
}

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

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

 

如果我們將注意力只集中在Http請求、HttpHandler和HttpModule上，不去考慮HttpContext和HttpApplication，那么圖4.可以簡化成下面這樣：

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

總結

本文中，我首先概要介紹了這系列文章將要為大家講述的主題。然后，我提出了部分程序員存在的一個問題：在一個比較高的層次上學習和使用Asp.Net。

隨后，我以一個訪問我個人空間首頁的例子，引出了本文主要講述的三個內容：

1. Http請求剛剛到達時IIS時，IIS 所做的工作。
2. Http請求的宿主環境。
3. Http管道。