构建高性能.NET应用之配置高可用IIS服务器-第二篇 IIS请求处理模型

         在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的处理管道，一个是ASP.NET的处理管道。

2.      每一个请求的处理都要经过两个管道。当请求经过IIS的管道的时候，IIS6就是根据它的metabase里面的配置信息来决定把请求给那个来处理。如果是请求与ASP.NET相关的内容的，那么请求就会被交个aspnet_isapi.dll来处理，然后aspnet_isapi.dll就加载CLR运行时，并且开启ASP.NET的处理管道。

3.      在两个管道中，有一些相同的处理流程，例如身份验证。

 

另外，ASP.NET允许我们在处理管道中注册自己的module或者handler，这一点朋友们都应该很清楚了。我们一般在ASP.NET的应用程序级别的事件中注册我们自己的逻辑，当ASP.NET触发这些事件的时候，我们的代码就运行了。

IIS6中引入了两个不同的处理管道，引发了下面的问题：

1.      导致了一定程度的重复处理。例如，两个管道中都有身份验证的组件，那么一个请求就要被验证两次。

2.      因为ASP.NET的管道在IIS的管道之后，所以对于每个请求的处理决定完全是由aspnet_isapi.dll这个组件来控制的，也就是说ASP.NET的处理管道无法在早期对请求如何进行处理下决定。

3.      一旦把请求交给了ASP.NET的处理管道之后，IIS 的处理管道要等到ASP.NET处理完毕之后才能接着处理，而且，一旦ASP.NET管道处理完之后，ASP.NET的处理管道无法影响后续的IIS6的处理管道。

4.      只有把请求交给了aspnet_isapi.dll之后，ASP.NET处理管道才开始启动，并且请求的内容只能是与ASP.NET相关的，例如aspx页面等。ASP.NET处理管道无法处理对非ASP.NET内容的请求，例如图片，脚本等。也就是说：程序在一定的程度上无法对非ASP.NET的资源进行验证与授权的保护。

既然IIS6有上面的一些问题，IIS7的出现就解决了上述的问题。IIS 7移除了对aspnet_isapi，并且将IIS和ASP.NET的进行了集成，成为一个管道，如下：

一个请求的处理流程变的简单了，效率应该会提高。事实也确实如何，并且一个请求的线程切换次数也变少了，这极大的提升了性能（不用把请求从IIS的线程切换到ASP.NET的处理线程）。

通过改进，IIS 7解决了上述我们提到的几个问题：

1.      集成管道中不会包含重复的组件。

2.      ASP.NET的module和handler可以在管道的如何地方发挥作用，从而使得我们可以对请求的处理流程进行完全的控制。

3.      可以处理对非ASP.NET内容的请求。

相关内容

• 构建高性能.NET应用之配置高可用IIS服务器-第一篇：IIS必须掌握的知识

作者介绍：汪洋，哪合伙CEO，曾大汉电子商务有限公司首席技术官，副总裁，负责公司产品、技术、运营，参与商业模式设计。华康移动医疗前CTO，副总裁，首席架构师。微软MVP

---

.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注

赞赏

人赞赏