之前写过一些文章，处于为阅读者考虑的原因（其实也没什么人看，就是自己想多了），写得很啰嗦，有一种又当爹又当妈的感觉，真是操心的命。
现在回过头来看看，这么写出来的东西，不仅没人看，我自己也不愿意看，太啰嗦。然后有些时候，需要将自己理解的样子呈现出来。首先，说错了会有人跳出来鄙视；其次，好记性不如烂笔头，即使理解了，时过境迁，毕竟长大了，烦恼很多，不遗忘，真的做不到。
当一个httprequest发生时，IIS首先收到请求信息，根据扩展名的注册信息传送到asp.net ISAPI中，接着创建asp.net http runtime也就是对应的线程，runtime首先会创建一个httpcontext，很显然这个对象即包含了Request对象，也包含了Response对象，在整个请求过程中它就作为数据的中心。
之后就进入了HttpModule的处理管线，pipeline的设计方式在微软的组件当中十分的常见，通过一个管道套一个管道的方式，可以很灵活的依次对数据对象进行包装和处理，用户也可以很方便的加入自定义的module。WCF中的协议管道也是这个方式，类似于设计模式中的职责链，一环套一环，直到把对象洗白白。在这个管线中肯定有微软帮我们完成了的事情，比如高速缓存的查询，授权，认证。当然有begin就有end，在后处理的module中完成了update cache的操作。
第三部分就是真正处理这个请求的httphandler，主角总是在很多渲染之后登场的，没有人一开始就出王炸。。。这是HttpModule中的一个部分，这个过程中微软也是留足了事件的接口，pre和post包装了一圈httphandler。httphandler的核心部分就是processRequest方法，需要提一句的是，httphandler不是管道式的处理方式，我处理过的，其他的也就别想了。
最后，在完成一系列收尾的Module之后输出到客户端。
所以简单的说整个流程是如此：
Browser（request）--》IIS--》Asp.netISAPI--》HttpRuntime--》HttpModule（Pipeline，include HTTPHandler）--Output
写的比较粗糙，算是总括，很多内容可以展开到很具体，比如httphandler是如何创建的，它需要一个容器，因为httphandler可以有很多个，如何选择，创建，回收再利用。
随笔随笔，大方向对了，能让我想起来就好，具体的内容用的时候在捡起来吧。
参考链接：
http://www.cnblogs.com/stwyhm/archive/2006/08/09/471729.html
http://www.cnblogs.com/stwyhm/archive/2006/08/09/471729.html
http://www.cnblogs.com/stwyhm/archive/2006/08/09/471765.html
http://www.cnblogs.com/tenghoo/archive/2009/11/04/IIS_And_ASPNET_Http_Runtime_Pipeline.html