在IIS 中，Http监听者(http.sys)和请求处理者由两个系统服务在控制着。一个是WWW 服务，另外一个就是Windows Process Activation。
对于WWW服务，它主要是监控IIS的配置文件，将新的配置信息用到HTTP.sys和WAS上。同时它也维持一些性能计数器，把一些数据反应到计数器中，所以，很多的时候，我们可以查看性能计数器来获取一些与IIS性能相关的信息。
对于Windows ProcessActivation，这个服务的作用就是激活和唤起进程来处理请求，同时它也对正在运行的处理进程进行管理，例如资源的回收，以及控制着性能相关的一些限制。
在IIS6中，上面的讲述的功能都是包含在WWW服务中的，在IIS 7中，就将上面的功能分开了。到了这里，我感觉再讲下去，大家可能要犯糊涂了，为了使得后文的讲述更加的方便和大家的理解更加的深入，这里很有必要把IIS 的架构讲讲，也非常有必要把IIS 6和IIS 7进行比较。
首先，我们就来看看IIS6的请求的处理模型，如下图所示：
在上图中，我们可以看到：
1.IIS6的请求处理模型中包含了两个管道：一个是IIS6的处理管道，一个是的处理管道。
2.每一个请求的处理都要经过两个管道。当请求经过IIS的管道的时候，IIS6就是根据它的metabase里面的配置信息来决定把请求给那个来处理。如果是请求与相关的内容的，那么请求就会被交个aspnet_isapi.dll来处理，然后aspnet_isapi.dll就加载CLR运行时，并且开启的处理管道。
3.在两个管道中，有一些相同的处理流程，例如身份验证。
另外，允许我们在处理管道中注册自己的module或者handler，这一点朋友们都应该很清楚了。我们一般在的应用程序级别的事件中注册我们自己的逻辑，当触发这些事件的时候，我们的代码就运行了。
IIS6中引入了两个不同的处理管道，引发了下面的问题：
1.导致了一定程度的重复处理。例如，两个管道中都有身份验证的组件，那么一个请求就要被验证两次。
2.因为的管道在IIS的管道之后，所以对于每个请求的处理决定完全是由aspnet_isapi.dll这个组件来控制的，也就是说的处理管道无法在早期对请求如何进行处理下决定。
3.一旦把请求交给了的处理管道之后，IIS 的处理管道要等到处理完毕之后才能接着处理，而且，一旦管道处理完之后，的处理管道无法影响后续的IIS6的处理管道。
4.只有把请求交给了aspnet_isapi.dll之后，处理管道才开始启动，并且请求的内容只能是与相关的，例如aspx页面等。处理管道无法处理对非内容的请求，例如图片，脚本等。也就是说：程序在一定的程度上无法对非的资源进行验证与授权的保护。
既然IIS6有上面的一些问题，IIS7的出现就解决了上述的问题。IIS 7移除了对aspnet_isapi，并且将IIS和的进行了集成，成为一个管道，如下：
一个请求的处理流程变的简单了，效率应该会提高。事实也确实如何，并且一个请求的线程切换次数也变少了，这极大的提升了性能（不用把请求从IIS的线程切换到的处理线程）。
通过改进，IIS 7解决了上述我们提到的几个问题：
1.集成管道中不会包含重复的组件。
的module和handler可以在管道的如何地方发挥作用，从而使得我们可以对请求的处理流程进行完全的控制。
3.可以处理对非内容的请求。
相关内容
构建高性能.NET应用之配置高可用IIS服务器-第一篇：IIS必须掌握的知识
作者介绍：汪洋，哪合伙CEO，曾大汉电子商务有限公司首席技术官，副总裁，负责公司产品、技术、运营，参与商业模式设计。华康移动医疗前CTO，副总裁，首席架构师。微软MVP
.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注
赞赏
人赞赏
如果觉得《构建高性能.NET应用之配置高可用IIS服务器-第二篇 IIS请求处理模型》对你有帮助，请点赞、收藏，并留下你的观点哦！
