ASP.NET应用程序生命周期趣谈(二)
在上回书开始的时候我们提到博客园的IIS看了一眼我的请求后就直接交给ASP.NET去处理了，并且要求ASP.NET处理完之后返回HTML以供展示。
那么我们不仅要问：
1， IIS肯定是没有眼睛的啦，那它是怎么“看”的呢？
2， 在“看”到了.aspx的页面请求后又是如何把它交给ASP.NET的呢？如果不做任何处理那它的存在又有什么意义呢？
3， ASP.NET收到这个处理请求后又是如何做的呢？它是怎么创建Context对象又是如何“雇佣”项目经理HttpApplication对象的呢？
本文将就这些问题进行深入而简单的探讨。
当你点击了这篇文章的链接，在很短的一段时间内博客园的IIS就收到了你的请求。它要“看”了。正如我们知道的，它没有眼睛，所以它依靠ISAPI来“看”请求的后缀。我们这次请求的是.ASPX文件。ISAPI是全称Inernet Server Application Programe Interface, 它就是IIS的眼睛和路由器，先看后缀然后分发给各个应用，我们可以通过访问IIS的站点的属性—》主目录—》配置 来查看它的路由映射。
我们发现，在.aspx extension对应的Executable Path里，真正处理asp.net应用程序的是aspnet_isapi.dll。可以清楚的看到，它还能处理ASAX,ASCX, ASHX, ASD,BROWER,CD等等等一堆啊，真是功能强大。
然而，在“看”的方法方式上，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了。
接下来在最重要的worker process中发生了什么呢？项目经理HttpApplication又是怎么被雇来的呢？请听我慢慢道来。
ASPNET_ISAPI在创建了worker process加载了CLR完成了托管环境的布局后，就什么都不管啦。Worker process开始管理一切，它把所有的工作都交给了HttpRuntime。最后，是HttpRuntime雇佣了项目经理HttpApplication。然后，HttpRuntime并不是什么工作都没有做，它已经通过配置文件创建了所有的HttpModule并填写在了HttpApplication的“工作列表”中，项目经理HttpApplicaiton事根据这个列表来工作的。HttpRuntime也创建了HttpContext这个箱子并交给了项目经理HttpApplication。乎！现在我们终于理解“asp.net创建了HttpContext”这句话了吧。现在总结一下HttpRuntime都干了什么：
1， 打造了HttpContext这个箱子来存储Request和Response
2， 建立了工作列表HttpModule
3， 雇佣了项目经理HttpApplication并把箱子Context交给它，然后把工作列表作为效绩考核列表也交给他。
4， 等着返回结果
PS:在这个过程中，其实还有更详细的过程，但是我觉得那无助与我们理解真正的重要的东西，反而会带来更高的难度，所以也就没往上写。有兴趣的筒子们可以去微软网站搜索相关资源。
接下来，“项目经理”HttpApplication所作的事相信大家已经在前一篇文章中有所了解啦，什么？没看？那就赶紧去看看吧。