在上回書開始的時候我們提到博客園的IIS看了一眼我的請求后就直接交給ASP.NET去處理了，并且要求ASP.NET處理完之后返回HTML以供展示。

那么我們不僅要問：

1，??? IIS肯定是沒有眼睛的啦，那它是怎么“看”的呢？

2，??? 在“看”到了.aspx的頁面請求后又是如何把它交給ASP.NET的呢？如果不做任何處理那它的存在又有什么意義呢？

3，??? ASP.NET收到這個處理請求后又是如何做的呢？它是怎么創建Context對象又是如何“雇傭”項目經理HttpApplication對象的呢？

本文將就這些問題進行深入而簡單的探討。

IIS通過請求的后綴去看,IIS中的isapi就是它的眼睛和路由，我們可以通過訪問IIS的站點的屬性—》主目錄—》配置 來查看它的路由映射

我 們可以發現，當請求的Extension是.aspx時，對應的Executable path是C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll 。就是當IIS查找對應的請求映射表時，發現后綴是.aspx則直接交給aspnet.isapi.dll文件處理。

然而，在“看”的方法方式上，IIS5和IIS6有一些不同。

IIS5 通過inetinfo.exe進程在TCP端口(默認是80)來“看”那些進來的Request。正如我們剛才看到的，如果這些Request是需要 aspnet_isapi.dll來處理，則aspnet_isapi.dll創建(不太確定worker process是不是aspnet_isapi.dll創建的，但是它們通過命名管道來交互)并持續監視一個aspnet_wp.exe進程，它就是 asp.net最重要的組件：worker process。幾乎所有的工作都是在這個進程中完成，它在IIS6中被改名叫做w3wp.exe。

IIS6 則通過內核模式中的HTTP.SYS來“看”那些進來的Request。HTTP.SYS把進來的Request發送到相應的Application Pool(應用程序池)。應用程序池再把Request傳遞給aspnet_isapi來進行創建worker process的工作。IIS6中的worker process已經是w3wp.exe了。

其實aspnet_isapi在創建了 work process進程和加載了CLR完成了托管環境的布局以后就什么也不管了，剩下的就交給了work process進程去管理了，而wp進程則把所有的任務都轉交給了HttpRuntime去處理，HttpRuntime完成了以后的所有工作，包括雇傭 項目經理(Httpapplication)，HttpRunTime根據webconfig創建了HttpModule并放到了 Httpapplication的工作表中，而Httpapplication則是根據這個工作表去工作的，并且HttpRunTime也創建了 Context這個箱子，并把它交給了Httpapplication。以后的事情就是Httpapplication找到的兩個程序員 HttpModule和HttpHandler去完成了。

總結一些HttpRunTime做了哪些事情：

第一：雇傭了HttpApplication。。。。

第二：根據配置文件創建了HttpModule列表。HttpApplication就是按照這個工作列表去工作的。。。。

第三：創建了上下文環境(就是Context這個箱子，箱子中包括Request和Response兩大主要對象)，并轉交給了HttpApplication的手中。。。。

第四：等著返回結果。。。。

如果您看完這篇文章有些不理解，請首先閱讀系列一。

可是還有些問題需要解決：

第一：HttpModule到底是什么東西呢，HttpApplication為什么會按照它的工作列表去工作呢？

第二：HttpHandler又是怎么去處理頁面的請求的呢，又是怎么生成Html代碼返回給留言器的呢？

其實HttpModule和HttpHandler是Asp.Net生命周期中兩大非常重要的對象，我打算單獨介紹，還請接續關注......

總結

以上是生活随笔為你收集整理的Asp.Net生命周期系列二的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。