Asp.Net構架(Http請求處理流程) - Part.1

引言

我查閱過不少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 ，看看它到底是什麼樣子，請按下面的步驟進行：

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 中的流動方向

總結

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

随後，我以一個通路我個人空間首頁的例子，引出了本文主要講述的三個内容：

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

希望這篇文章能給你帶來幫助。