在上回书开始的时候我们提到博客园的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生命周期中两大非常重要的对象，我打算单独介绍，还请接续关注......
