Ps：建议初学者在阅读本文之前，先简要了解一下之前的几篇文章，以便于熟悉本文提到的一些关于IIS6的内容，方便理解。仅供参考。

PS：为什么叫瞎说呢？我觉得自己理解的并不到位，只能是作为一个传声筒，希望能给大家一些启发，引发一些讨论，来让大家更好的理解asp.net处理原理。有错误的地方，大家一定要指正，一定不要给我面子。谢谢大家。

在之前的几篇文章中，我跟大家分享了ASP.NET应用程序生命周期的一些知识，大多是在IIS6中。
随着技术的迅猛发展，IIS7逐渐的走入我们的视线，我相信未来也将全面代替IIS6等旧的版本。今天我们就来了解一下IIS7是如何工作的，它究竟能给我们带来什么。

我们知道，IIS6使用HTTP.SYS这个协议监听器来处理HTTP和HTTPS请求，IIS7也一样。HTTP.SYS是内核模式运行的，它替换了WINDOWS Sockets API（用户模式的）来接收请求。大家一听这“内核”肯定是要比“用户”厉害的嘛，好处我就不详说了。

下面我就说说说整个处理过程，从IIS6开始。

在IIS6中，www service管理IIS中Http的配置和管理，对worker process进行管理，对网站性能进行监控，工作能力可谓强大。然而在IIS7中，微软为www service进行了减负，www service不再兼任worker process的管理员，而仅仅是作为HTTP.SYS的适配器，主要职责就是配置HTTP.SYS。Windows Process Activation Service分享了www service之前的一些职能，包括管理应用程序池的配置和worker process的管理。最大的改进在于：IIS7中asp.net管道和IIS管道被合并在了一起来处理请求（集成模式）。
这样做有什么好处呢？
在之前的IIS版本中，只有托管代码才可以使用IIS的module，先在所有的文件类型都可以使用这些module，也就是说，你可以为静态页面使用asp.net forms authentication和URL authorization；
消除了IIS和ASP.NET的重复特性。例如客户端在请求一个托管文件时，旧版本的IIS会先通过IIS管道再通过ASP.NET管道。先在，只需要通过集成管道调用IIS的验证模块就可以了；
在同一位置管理所有模块，而不是在IIS中和ASP.NET中个管理一部分，这就简化了配置和管理。

关于应用程序池，IIS7允许用户选择两种模式：经典模式和集成模式。集成模式就是我们刚刚提到的通过整个ASP.NET和IIS7变成集成管道来处理；经典模式就是IIS6中的模式分开管理。值得注意的是，IIS7在应用程序级别设置这种模式，所以我们才可以在同一server上运行两种处理模型的应用程序；而iis6在server级别设置worker process的隔离模式，所以我们只能使用一个处理模型（当然，也只有一种处理模型，那就是IIS+ASP.NET）

集成应用程序池模式
 当一个应用程序池在集成模式下时，你可以利用IIS和ASP.NET的集成请求处理架构。当一个worker process在一个应用程序池中接收到一个请求时，这个请求通过一些列的事件列表进行传递。每个事件调用需要的默认和托管的模块来处理请求的对应的部分生成response。
 集成模式有如下好处：
首先，IIS和asp.net请求处理模型被集成为一个统一的处理模型。这个模型消除了以前IIS和ASP.NET中重复的步骤，比如authentication。另外，集成模式使得托管特性的可用性扩展到所有的内容类型。

经典应用程序池模式
 经典模式时，IIS7处理请求的方式和IIS6一模一样。ASP.NET请求首先通过IIS的默认处理步骤，然后被引入ASPNET_ISAPI在托管runtime中来处理托管代码。最后，请求再被路由回IIS，发送response。
 这种IIS和ASP.NET分离的处理模型结果导致某些处理步骤重复，例如验证和授权。另外，托管代码特性，比如forms验证，也只能被asp.net应用程序使用（或者你写脚本映射所有的请求需要被ASPNET_ISAPI.DLL来处理）。
 在升级产品环境到IIS7并指定应用程序模式为集成模式前，要确保在继承模式下对现有的应用程序进行兼容性测试。如果集成模式失败，就加到经典模式上来。

说了那么多与以往版本的不同，我们以HTTP请求为例来捋顺一下IIS7的处理过程：

首先，客户端通过Internet发过来HTTP请求，HTTP.SYS接收到该请求。HTTP.SYS随后通知WAS说：去获取配置信息。WAS的配置信息来自于ApplicationHost.config。然后WWW SERVICE会得到配置信息，比如应用程序池和站点配置。我们知道，IIS7中WWW SERVICE主要功能就是配置HTTP.SYS，它配置了HTTP.SYS后，WWW SERVICE将请求通知给WAS。
WAS收到请求（可以是HTTP或非HTTP）后就会进行如下处理过程：
检查worker process是否在运行。如果一个应用程序池已经有了一个worker process，则将请求传递给WP；否则将创建一个WP。
Worker Process处理了请求后就返回一个response给HTTP.SYS。最后客户端接收response。
Worker Process里面则对该请求进行了一系列处理，可能包括验证，授权，缓存，异常等等module。
整个处理过程可以用两张图来表示，如下：

IIS处理过程：

Worker Process处理过程：
 

本文已经不再是趣谈了，虽然无“趣”，却也算有理，欢迎拍砖。