當一個客戶端頁面訪問IIS試圖獲取一些信息的時候，發(fā)生了什么事情？一個請求在通過了HTTP管道后又發(fā)生了什么？本文主要是描述這兩個過程，即IIS處理asp.net請求和asp.net的頁面生命周期。歡迎大家積極拍磚，共同學習，共同進步。

首先我們要弄清楚兩個非常重要的概念：

1， worker process(w3wp.exe). worker process管理所有的來自客戶端的請求并給出響應。它是IIS下asp.net應用程序的核心。

2， application pool. 它是worker process的容器，IIS5及之前的IIS版本均沒有application pool的概念。每一個application pool對應著一個worker process，在IIS Metabase中維護著Application Pool和worker process的Mapping。這就避免了IIS5中出現(xiàn)的worker process（IIS5中是aspnet_wp.exe，同一時間只能運行一個該進程)崩潰，application全崩潰的局面。

客戶端向IIS發(fā)出一個資源請求后發(fā)生了如下事情：

1， server接受該請求

IIS6通過內(nèi)核模式（Kernel mode）中的HTTP.SYS來分發(fā)各個Request到application pool。 這并不是隨機的過程，在application pool創(chuàng)建的時候就已經(jīng)注冊到了HTTP.SYS,所以當請求來到時HTTP.SYS會直接發(fā)送到相應的application pool。 接下來在IIS的用戶模式（User mode)中，Web Admin Services (WAS) 做了從HTTP.SYS中得到Request并分發(fā)到application pool的工作。application pool直接把request傳遞給worker process。

2， 請求傳遞到worker process后，worker process初始化加載ASP.NET ISAPI(Internet Server Application Program Interface)，ASP.NET ISAPI進而加載CLR創(chuàng)建托管環(huán)境。

(注：ISAPI只是一個接口，起到一個代理的作用，主要能力就是根據(jù)Request URL的后綴來尋找該后綴的處理程序）

ASP.NET ISAPI定義在aspnet_isapi.dll中，它本身運行在一個非托管的環(huán)境中。ASP.NET ISAPI開始一個HttpRuntime, HttpRuntime調(diào)用ProcessRequest方法來開始處理請求。ProcessRequest根據(jù)ISAPI傳進來的iWRType 來創(chuàng)建不同的HttpWorkerRequest，從而屏蔽了不同IIS的差異。接下來ProcessRequest方法創(chuàng)建了HttpContext，我們使用HTTPContext.Current來訪問它。在HttpRuntime使用HttpApplicationFactory創(chuàng)建了HttpApplication對象（IHttpHandler）以后，所有的請求都會在通過httpmodule后找到相應的Httphandler進行處理。在HttpApplicationFactory創(chuàng)建HttpApplication之前，會查找config（web.config和Machine.config）文件中注冊的所有的HttpModule，并根據(jù)配置信息加載相應的Assembly，通過Reflection創(chuàng)建對應的HttpModule，并將這些Module加到HttpApplication 的_moduleCollection Filed中。我們對一個Application的請求最終會落到一個HttpApplication對象上。當一個請求到來時，ASP.NET會在Httplication Pool中查找未被使用的HttpApplication對象。

3， 請求通過HTTP管道后，每個請求都發(fā)向相關的各自的httphandler，IIS請求處理過程結束。

HttpHandler是HTTP管道的終點，它為每個request生成輸出。System.Web.UI.Page就是這樣一個典型的Httphandler，當我們請求一個aspx頁面，這個HttpHandler就生成html發(fā)送回客戶端?？碢age類的簽名：

public class Page : TemplateControl, IHttpHandler

{

}

可以看到，Page類就是一個HttpHandler。

綜上整個過程就是：當客戶端向服務器發(fā)送資源請求時，請求首先到達IIS的HTTP.SYS。然后HTTP.SYS發(fā)送請求道對應的Application Pool。 然后Application Pool發(fā)送請求到Worker Process（W3WP.exe）中加載ISAPI Extension，ISAPI創(chuàng)建一個HttpRuntime對象來通過HttpModule和HttpHandler處理請求。 然后頁面生命周期就開始了。

4， 頁面生命周期開始

頁面生命周期的主要階段包括：

頁面初始化（Init）: 服務器創(chuàng)建服務器控件的實例

加載(load): 控件實例被加載到它定義的頁面對象中

預輸出:（PreRender) 對控件的更改被更新，準備輸出。

保存(SaveViewState): 控件的狀態(tài)信息被保存。

輸出頁面(Render):服務器為控件創(chuàng)建html標記。

處理(Dispose): 主要做的工作就是dispose, 關閉數(shù)據(jù)庫連接，文件資源的釋放等。

卸載(Unload)：銷毀服務器控件的實例

頁面生命周期的主要事件：

PreInit:

1.檢查IsPostBack 屬性

2.動態(tài)設置Master Page

3.動態(tài)設置Theme

4.設置控件的默認值(UniqueId等）

5.重新創(chuàng)建動態(tài)控件（初始化控件），初始化控件的值

Init: 這個事件發(fā)生在所有的控件被初始化，所有的皮膚設置被應用以后。它用來讀取或者初始化控件屬性。它能夠用來注冊一些aspx頁面中沒有指出的控件的事件。

InitComplete: Use this event for processing tasks that require all initialization to be complete.

PreLoad: 加載頁面的ViewState和所有的控件，然后處理所有的包含在Request實例中的postback數(shù)據(jù)。

Load: 這個事件可能是大家最熟悉的了。需要注意的是，Page對象會遞歸的調(diào)用子控件的onload事件直到頁面和所有的子控件被加載完成。這個事件主要用來設置控件屬性的值，建立數(shù)據(jù)庫連接（通常不這么做）。

Control events: 這個就不多說了，主要是處理控件的事件，例如click。這也就讓我們明白了每次我們click一個Button的時候，實際上是要先去執(zhí)行l(wèi)oad事件然后才執(zhí)行click事件的，一般我們用!IsPostBack來判斷一下從而避免執(zhí)行不必要的加載邏輯。

LoadComplete: 頁面所有的控件都被加載以后執(zhí)行，暫時沒有想到用來干什么。。。

PreRender: 在HTML被生成之前這是最后一個事件。每一個頁面中的控件都有PreRender的過程。在這里對將要輸出的HTML結果進行最后一次修改。

SaveStateComplete: 在這個時間發(fā)生之前，已經(jīng)保存了所有控件和頁面的，任何對page或者控件的改動都不會產(chǎn)生左右。暫時沒想到用來干啥。

Render: 它不是一個事件而是一個方法。工作就是把HTML寫回客戶端瀏覽器。

UnLoad: 頁面中的每一個控件都會發(fā)生這件事。在控件中，使用這個事件來做清理工作，例如關閉數(shù)據(jù)庫連接等。對與頁面本身也是做清理工作，例如關閉打開的文件和數(shù)據(jù)庫連接，或者結束日志或者其它指定的工作。

需要說明的是，每次Request都會創(chuàng)建一個全新的Page類的實例，所以在頁面中的自己定義的字段是不能在兩次request中傳遞值的，需要使用viewstate來存儲。

5， HttpHandler根據(jù)頁面生命周期中事件的處理把結果發(fā)回IIS,IIS再把結果發(fā)回客戶端瀏覽器。

值得注意的是，在這個過程中請求會再次通過HttpModule(注冊一個EndRequest事件）。

至此，整個Request結束。