Asp.Net生命周期系列

本文转载来自：http://www.cnblogs.com/skm-blog/archive/2013/07/07/3176813.html

Asp.Net生命周期对于初级甚至中级程序员来说，一直都是一个难题，很多程序员不了解生命周期，导致使用Asp.Net做开发感觉很不灵活，感觉太多东西被微软封装好了，我们不能改变，其实只要你稍微了解一下就知道，原来不是这样的！

我写这一系列文章是采用总分的方式，先让大家整体了解，然后再逐一突破。先将一个故事，也是园子里看到的（http://www.cnblogs.com/GodSpeed/archive/2010/06/19/1761095.html），我认为这个写的有些细节上的错误，稍稍添加些自己的想法和理解，如有错误，还请留言！

当你访问博客园想看我的这篇文章的时候，这个请求就被博客园的WEB SERVER（IIS）接收到了【其实是被IIS中的一个叫做inetinfo.exe的进程截获了】。博客园IIS看了一眼你的请求，“噢，是.aspx啊，给aspnet_isapi.dll去处理吧，就把我这个请求给了aspnet_isapi.dll， 并且说：“这个你来处理，你处理完了之后把HTML给我，我好给请求者一个回复”。

aspnet_isapi.dll收到IIS传递过来的请求后也没时间抱怨啊 就开始干活儿了。怎么干的呢？其实啊很简单，就是通过一个http pipeline管道转交给了aspnet_wp.exe进程，接下来就到了.netFramework的HttpRunTime处理中心，HttpRunTime它其实就是做了几件事情。

第一，它先创建了一个Context对象，它就像个箱子，箱子当然是来装东西的啦，装什么呢？

第二，HttpRunTime创建了一个Request对象，包含了IIS传递给它的所有信息（IIS传递过来的实际就是个Request嘛）。

第三，HttpRunTime接着又创建了一个Response对象，用来装HTML的，也放进箱子（Context）

第四，然后，HttpRunTime说，太累了，这活儿没个干，还是雇个人吧。就找到了HttpApplication Factory公司要了一个项目经理（HttpApplication对象），然后就把箱子（Context）交给项目经理并且对它说，这里有我们收到的Request，你需要做的就是把 里面的Reponse填一下，具体怎么干你掂量着吧，就走了。

这个项目经理（HttpApplication对象）就想啊，凭啥活儿我干钱你们拿啊？不行，我得找俩苦力去，于是就有了：程序员HttpModule和程序员HttpHandler，姑且就称他们为P_Module和 P_Handler吧，项目经理先找到了P_Module，并且给予了p_Module足够大的权力，P_Module(HttpModule)非常的能干，它能够去查看HttpRunTime交给项目经理（HttpApplication对象）的箱子（Context），并且根据里面的东西做一些决定，比如安全啊 （FormsAuthenticationModule),状态啊（SessionStateModule ）等等吧。 在P_Module工作完成之后（也许已经改变了箱子里（Context）的内容），然后他就转交给他的副手P_Handler来做填充Response的工作。 可是啊，想找个合适的P_Handle也很难啊，找了好久也没找到，好吧，找猎头（HttpHandler Factory）吧。猎头公司一看，“噢，要.aspx Handler啊",于是找来了一个天生就善于并且愿意处理页面的P_Handler，所以呢P_Module就把自己处理过的箱子交给它并且说:"处理一下这个箱子里的东西，然后交给我"。

P_Handler是个天生的处理页面的牛人，它根据Request对象里的东西是用 了一招"乾坤大挪移"，不知道怎么挪的，就挪出了HTML并塞进了Response对象中。P_Handler自信的笑了一声，把箱子交还给了HttpModule。然后呢再一层一层的把这个箱子向上传递【不能越级啊，每个人都有自己顶头上司，只能把箱子交给自己的顶头上司】，最后就传给了IIS，IIS又给了你了，你就看到这篇文章了。

故事就是故事，故事就是故去的事，就是往事。那往事肯定就有遗漏的地方。那我们这个故事遗漏了哪些地方呢？

第一，IIS和ASP.NET之间的交互不是像我说的那么简单而直接的，中间还发生了很多事情。

第二，HttpModule，也就是我们的程序员P_Module, 它其实还能干很多事情，我们并没有去发掘。

第三，HttpHandler，也就是我们的程序员P_Handler，它的"乾坤大挪移"就是ProcessRequest方法，这里并没有详述到。

第四，。。。等我再想想再跟您聊。

 

希望这边小文能够帮助你更容易的理解ASP.NET生命周期，我会继续努力，争取以最简单明了的方式来speak out ASP.NET原理和运行机制。欢迎拍砖，谢谢。

 

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