原文：http://www.cnblogs.com/cilence/archive/2012/05/28/2520712.htmlAsp.Net 請求處理機制前言我們都知道Web請求響應是基於Http協議，那麼我們可以這樣來理解，一次Web請求和響應的過程，實際上就是一次發送Http請求和接收Htt...
原文：http://www.cnblogs.com/cilence/archive/2012/05/28/2520712.html
Asp.Net 請求處理機制 前言 我們都知道Web請求響應是基於Http協議，那麼我們可以這樣來理解，一次Web請求和響應的過程，實際上就是一次發送Http請求和接收Http響應的過程。 客戶端向伺服器發送一次Http請求，伺服器端接收到這次請求，並生成響應報文 ，將響應報文發送回客戶端。這樣客戶端和伺服器端就完成了一次Web交互。 什麼是Asp.Net呢? 我喜歡把Asp.Net定義如: Asp.Net 是一個運行在CLR的托管代碼上，從前到後處理Web請求，並響應Web請求的一個AOP框架,它是處理Web請求的一種引擎。它不是僅僅是我們常用的WebForm,WebService,IHttpHandler這些，它還有很多..... 從瀏覽器到伺服器的過程 我們來看一下，當我們在瀏覽器地址欄輸入http://www.cnblogs.com博客園的網址時,並敲擊回車鍵。這個時候就會從瀏覽器端生成一個Request請求,併發送給http://www.cnblgos.com的web伺服器 ,當請求到達web伺服器的那一刻，web伺服器Windows內核中的HTTP.SYS組件就會捕獲到請求。當HTTP.SYS組件分析到這是一個需要交給IIS伺服器處理的Http請求時，HTTP.SYS組件就會將Request請求，交給IIS伺服器來處理。IIS伺服器分析Request請求的context-type類型，然後從處理程式映射表中去匹配，當在處理程式映射表中能夠匹配到Request請求的context-type類型時，那麼IIS伺服器就將請求交給映射表中所對應的程式處理。
圖一 : IIS中 處理程式映射表
當IIS發現，在處理程式映射表中沒有能匹配的項的時候(當沒有匹配項的時候，一般情況下是請求"靜態文件")，就直接去下載Request請求所對應路徑的文件。如.jpg,html,xml.css文件等等。
圖二 : 從瀏覽器到達伺服器的過程
回到之前，當伺服器在處理如aspx.ashx,等等動態文件的時候，IIS伺服器將Request請求，交
給aspnet_isapi.dll文件來處理。
ISAPI是第一個也是性能最高Request請求報文最原始的Web請求切入點
aspnet_isapi.dll是一個非常底層，並且是非托管的win32API，這個dll非常簡單，非常高效，並且還被微軟優化過性能。它用來處理最底層的 指令以及函數回調，併為高層程式提供了應用程式級別服務的功能和介面。
當aspnet_isapi.dll接收到Request請求的時候，aspnet_isapi.dll就會去調動Web伺服器中的.Net Framework,最終載入CLR運行環境，並創建一個ISAPIRuntime對象,然後調用ISAPIRuntime對象的ProcessRequest()方法。
ISAPIRuntme.ProcessRequest()方法是進入ASP.Net的第一個入口
ISAPIRuntime.ProcessRequest()方法調用之後主要做了一件事情，就是將Request的原始請求信息封裝成HttpWorkRequest類，由於HttpWorkRequest類封裝的請求報文很原始，很複雜，所以微軟沒有將其公開出來。接著執行StartProcessing()方法，來創建HttpRuntime對象並調用其靜態方法ProcessRequest()。
圖三 : 如何開始ASP.Net
HttRuntime,HttpContext,HttpApplication ?
在HttpRuntime對象調用其靜態方法ProcessRequest()之後，我們的Web請求開始慢慢進入應用層級別，why?
ProcessRequest()這個方法做了很多事情，具體可以通過Reflector工具查看,但是大致分為四個部分:
1.為請求創建了一個新的HttpContext實例(這個對象就是我們常用的HttpContext上下文對象),並將HttpWorkRequest中最原始的請求
報文封裝到HttpContext對象的HttpRequest對象中。
2.通過HttpApplicationFactory(應用程式工廠)得到一個具體的HttpApplication 實例。
3.調用HttpApplication.Init()方法來建立事件請求管道。
4.Init()方法觸發了HttpApplication.ResumeProcessing()方法來開始執行Asp.Net事件請求管道。
圖四 : HttpRuntime,HttpApplication和HttpContext的關係
Asp.Net事件請求管道詳解
前面說Asp.Net是一個Aop框架，而Asp.Net事件請求管道就是一點。
Asp.Net事件請求管道，是微軟幫程式員提供來處理Web請求的一些列事件，這些事件是依次執行，我們可以通過在這些事件上註冊或移除我們自己寫的方法，來修改Web請求執行的邏輯。
圖五 : ASP.Net事件請求管道
在第八個事件的時候，會創建請求的頁面對象，並轉換為IHttpHandler介面。
在第九個事件到第十一個事件之間，會接收到瀏覽器發過來的SessionId。並先會將IHttpHandler介面嘗試轉換為IRequiresSessionState介面，如果轉換成功，Asp.Net會根據這個SessionId到伺服器的Session池中去查找所對應的Session對象，並將這個Session對象賦值到HttpContext對象的Session屬性。如果嘗試轉換為IRequiresSessionState介面不成功，則不載入Session。
在第十一個事件到第十二個事件之間，會調用在第八個事件創建的頁面對象的ProcessRequest方法。
當我們直接使用*.ashx頁面的時候，就直接調用了一個FrameworkInitialize()，並最終生成響應報文，發送回客戶端。
當我們在使用*.aspx頁面的時候，它繼承自Page類，而Page類實現了IHttpHandler介面。
由於Page類實現了IHttpHandler介面，在ProcessRequest方法中，調用了FrameworkInitialize()方法。
在FrameworkInitialize()這個方法內部就開始打造Asp.Net的頁面控制項樹(打造html樹),在其中就調用了ProcessRequestMain方法，在這個方法裡面就執行了整個Asp.Net頁面生命周期。
IHttpModules
請求通過事件管道，一些列的事件被觸發了，我們可以通過在Global.asax全局配置文件中看到這些事件。
但是由於這是由程式分配的事件，可能就不是我們想要的。如果我們想要創建一個能夠復用的HttpApplication事件管道來處理Web請求，
我們又想將這些代碼復用，或者開發成插件的形式。那麼我們就可以使用IHttpModules。
IHttpModules配置很簡單，我們只需要在Web.config裡面配置一下就可以了。而具體的HttpModules只需要實現IHttpModules介面，並註冊自己的方法就行了。
<?xml version="1.0"?>
<configuration>
<system.web>
<httpModules>
<add name="cnblogsHttpModules" type="cnblogs.cnblogsHttpModules"/>
</httpModules>
</system.web>
</configuration>
Web.config文件的配置
publicclass cnblogsHttpModules : IHttpModule
{
public void MyBeginRequest(object sender, EventArgs e)
{
HttpApplication application = sender as HttpApplication;
application.Context.Response.Write("這個IHttpModule具體類的寫法喲!");
}
}
具體的HttpModules類寫法
Asp.Net頁面生命周期詳解
Asp.Net是一個Aop框架，而Asp.Net事件請求管道體現了Aop思想，而現在我們要說的Asp.Net頁面生命周期也體現Aop思想。
Asp.Net頁面生命周期的本質就是微軟提供給我們程式員修改頁面控制項樹代碼的一些列事件，我們可以通過實現頁面生命周期的事件方法來修改控制項樹代碼。
圖六 : ASP.Net頁面生命周期
當ASP.Net執行完我們註冊的生命周期事件方法的時候，最後會調用Render方法，Render方法要求傳入一個TextWriter文本寫出器對象，並遍歷所有控制項樹，調用每個控制項的Render方法。
所以每一個控制項調用Render方法之後產生的Html字元串都依次寫入到TextWriter對象。最後ASP.Net將TextWriter中的Html字元串封裝成響應報文，然後發送回客戶端。
結束語
在這裡，我介紹了一下ASP.Net的整個處理請求的過程。但有很多底層的信息，我還沒有仔細去觀察過，因此很多細節可能還是沒有註意到。這篇文章可能還是有很多錯誤的地方，希望博客園的兄弟姐妹們糾錯，謝謝。
