最近看了几篇讲述httpHandler和HttpModuler的文章，总的来说还是Fish li的那篇文章给力，但是他是大牛，他写出来的文章技术含量太高，对于像我这样的小兵，
要完全看懂估计需要看几遍。虽然说没有完全了解底层操作，但是我也算明白了一个请求从进入IIS到最后输出都经历了哪些过程。说实话，原来我以为.Net的类的子
类都是设计者自己设计的，没有考虑到真正的程序员是否可以完全掌握。了解了底层操作，我发现我的那个观点是多么的无知，每个.Net的类都是对应现实中的一种对
象，比如说Mvc3 中的路由就包括RouteData和HttpContext，至于为什么要这样包含？只有了解了iis的触发过程，我们就会真正的了解了。
序言介绍完毕，现在就来分享一下我对IIS底层的理解。技术不过硬，只能是采用大白话来说。
上面这幅图说明了在IIS 6 下的处理过程。
因为我们现在所用的是MVC3 ，所以我就按照MVc3 中的生命周期来叙述一个请求从开始到消亡的全过程。
请求阶段：
用户通过浏览器输入localhost/home/index 的地址，浏览器会发送一个请求到服务器的IIS用来处理这个请求。其实在操作系统中存在一个系统文件叫做http.sys
文件，它用来监视是否有请求到来，也就是说一个用户发来的请求的第一个接待者就是http.sys，它是一个系统文件，运行在操作系统的内核模式下，因此运行速度
更快。
在http.sys文件接收到请求之后（注：这是我的一个理解误区，我以前一直以为请求会直接进入IIS），会传入到第二个接待者IIS，真正的用来处理请求的操作系统组
件。在IIS接收到用户请求以后，首先会通过映射文件 然后由aspnet_iisapi.dll （IIS扩展）根据文件扩展名来选择对应的应用程序。这样说有点拗口，直白点的意思
就是IIS扩展会根据传入文件的扩展名(.aspx等)来选择 在IIS中配置的处理程序。这里会有一个问题存在，在Mvc中没有扩展名，那么程序是如何匹配的呢？其实这个
问题的处理方法有两种：
1.就是通过在路由表中添加一个虚拟的扩展名来欺骗IIS
2.就是通过在IIS配置文件中不选择确认文件存在，让IIS根据没有文件扩展名的文件路径来进行处理。
现在这个请求到了哪里？到了IIS扩展这里，下一步就是要进入到.Net框架中，让.Net框架来处理请求。但是在这中间会经过一些步骤的处理。大家应该记得在Web
form中有很多的事件，Page_load、Page_Render等，这些事件的执行顺序是依次进行的，不会混乱？那么.Net框架是如何来保证这些事件的顺序执行呢？这就是今
天的第一个主角HttpModule。我们可以把它称为http请求的过滤器，因为它不会有任何的输出，它会在任何请求中都会执行。当然有一个例外，那就是静态文件或者
其他没有配置为让IIS扩展让.Net框架处理的请求文件，因为他们进入到IIS中，IIS会找到对应的文件然后输出给浏览器的。
HttpModule的具体使用大牛们都说的很清楚了，我就简洁的描述一下大牛们忽略的知识点。既然说HttpModule是一个过滤器，那么我们可以在任何一个HttpModule
中终止当前请求的执行，执行身份认证，请问文件的访问权限检查等操作。我们可以自定义HttpModule扩展，只是让我们自己定义的类实现IHttpModule接口即可，
在IHttpModule 接口中有一个Init(HttpApplication app)方法，这是我们自定义扩展Module的入口，我们可以在其中定义我们自己进行的处理操作。
Init这个方法会接受一个HttpApplication类型的参数，HttpApplication 在MSDN中的定义就是定义 ASP.NET 应用程序中的所有应用程序对象通用的方法、属性和事
件。此类是用户在 global.asax 文件中所定义的应用程序的基类。HttpApplication 类的实例是在 ASP.NET 基础结构中创建的，而不是由用户直接创建的。
HttpApplication 类的一个实例在其生存期内被用于处理多个请求，但它一次只能处理一个请求。这样，成员变量才可用于存储针对每个请求的数据。
看到这个类的定义我们有没有想到应用程序池的概念，在IIS中我们新建一个应用程序就会创建一个对应的应用程序池，其实在应用程序池中存储的是什么？应该就是
这些HttpApplication对象。每个请求会有一个对应的HttpApplication对象来全程的负责它的执行，在httpApplication对象中包含着请求所需要的所有参数值。例如
Response、Request、Cache等.Net常用的对象，甚至我们可以通过这个变量获取到web.config中定义的所有Module扩展。HttpApplication会伴随着请求的全部
执行过程。
现在一个问题又来了，这个Module扩展需要传递一个HttpApplication对象作为参数，那么这个方法的参数是由谁创建的呢？我们应该经常用到一个类
HttpRuntime，根据这个字面意思，我们也可以想到这个就是表示的Http运行时，是的，在IIS将请求的数据准备好以后会通过HttpRuntime 调用
HttpApplicationFactory的一个Create()方法来得到一个HttpApplication对象，然后把参数值传递给这个对象，最后这个对象会传递到Module扩展中。
现在请求经过了Module扩展过滤之后，就要进入到真正处理它的地方了，HttpHandler，提起它，如果我们有点陌生，那么我们一定使用过.Net中的一般处理程序，
我们可以看到一般处理程序是一个ashx文件，其中会继承自IHttpHandler接口，进行ProcessRequest处理。其实我们的HttpHandler就是ashx文件的codeBehind
文件。只要我们实现了IHttpHandler接口中的方法，就定义了一个Handler扩展。
HttpHandler 是作为处理者的角色出现的，不是过滤者，所以Handler会有输出结果。如果你要在Handler中使用Session，那么就要继承IRequiredSessionState
接口，或者加上一个IReadOnlySessionState接口，这样我们操作Session的时候才不会出现错误。在Handler中我们可以进行任何我们想要的操作，例如生成图片
水印、防盗链甚至是文件的输出压缩以及编码等都可以实现。
像我们的Web Service以及一般处理程序，从本质上说都是Handler的一种高层实现方式，都是进行了Handler的扩展操作。
因为我们讨论的是MVC，所以我们不得不考虑路由Route，其实Route是Mvc中的一个单独的组件，它在我们的整个请求中也占据了非常重要的地位。在IIS通过IIS扩
展选择了适当的处理程序来处理这个请求的时候，就是路由出现的时候，路由会根据路由配置分析这个路径的ControllerName以及ActionName，对应的参数值，然
后会把这些参数存储到RouteData中，RouteTable.Routes 是一个路由集合，RouteData和HttpContext上下文就会组成另一个类的对象，RequestContext，我
们在MVC编程的时候，经常会用到这个对象中的一些数据。.Net框架会根据RequestContext对象的值来匹配程序中的Controller以及Action，然后调用
ControllerDescriptor 执行Controller，生成Controller的对象，然后通过ActionInvoke方法来执行具体的Action。
在Action执行完毕，返回对应的视图的时候，整个请求在.Net框架中的处理就算结束了。在输出结果返回到用户浏览器之前，输出结果还会经过Module扩展的最后处
理，输出结果到达IIS，最后IIS通过Http.sys响应到用户浏览器上，用户就可以看到输出结果。
因为一个请求从进入到显示在浏览器上会两次经过Module扩展，这就是为什么我们在web form中可以定义一个开始事件，然后还会有一个完成事件的原因。
总结一下，一个用户发起的请求通过http.sys-->IIS-->aspnet_iisapi.dll-->对应的处理程序-->Module--->Handler-->Module--->IIS-->http.sys-->用户浏
览器。
当然这个请求的顺序不是特别的准确，因为省略了好多的细节，但是从大的方面说就是这些功能。可能你会有一个疑问，aspx文件没有是什么时候执行的呢？其实这
个问题我以前也有想过，aspx是在Module之后处理的，但是在handler之后还是之前呢？今天终于得到了答案，其实一个单独的aspx文件就是一个handler，每个
aspx文件在编译的时候都会编译成一个类，这个类继承自Page，但是Page继承自哪里呢？
public class Page : TemplateControl, IHttpHandler
我们可以看到Page继承自IHttpHandler接口，这就验证了Page类的执行是在Handler执行的时候触发的。
一个小小的http请求会让我们有那么多的知识要掌握，我们作为程序员对于这个请求的模型应该是很熟悉。但是作为.Net 拖控件开发的程序员，我善意的提醒一下，
如果可以不用控件，我们就别用了，用js、css来代替吧，毕竟html是基础。在Mvc时代到来的时候，，拥抱新技术吧。
我是小兵，没有太多的发言权，所以我就是按小兵的思路来分析大牛们的技术。
我又回来了，回到了技术最前线，
