IIS7.0与ASP.NET

IIS7.0在请求的监听和分发机制上又进行了革新性的改进，主要体现在引入Window进程激活服务（Windows Process Activation Service，WAS）分流了原来（IIS6.0）W3SVC承载的部分功能。IIS6.0中W3SVC主要承载着如下三大功能。

1.HTTP请求接收：接收HTTP.SYS监听到的HTTP请求。

2.配置管理：从元数据库（metabase）中加载配置信息对相关组件进行配置。

3.进程管理：创建、回收、监控工作进程。

IIS7.0将后两组功能实现到了WAS中，但接收HTTP请求的任务依然落在W3SVC头上。WAS的引入为IIS7.0提供了对非HTTP协议的支持，它通过监听适配器接口抽象出针对不同协议的监听器。具体来说，除了专门用于监听HTTP请求的HTTP.SYS之外，WAS利用TCP监听器、命名管道监听器和MSMQ监听器提供基于TCP、命名管道和MSMQ传输协议的监听支持。

与此3种监听器相应的是3种监听适配器，他们提供监听器与WAS中的监听适配器接口之间的适配。这三种非HTTP监听器和监听适配器定义在程序集SMSvcHost.exe中。这三种监听器/监听适配器是为WCF设计的。

无论是从W3SVC接收到的HTTP请求，还是通过WCF提供的监听适配器接收到的针对其他传输协议的请求，最终都会被传递到WAS。如果相应的工作进程（针对单个应用进程池）尚未创建，则WAS会创建创建工作进程。WAS在进行请求处理过程中通过内置的配置管理模块加载相关的配置信息，并对相关的组件进行配置。IIS7.0大都将配置信息存放于XML形式的配置文件中，基本的配置存放在applicationHost.config。

1.3.4ASP.NET集成

从上面的介绍我们发现，在IIS5.x和IIS6.0中，IIS与ASP.NET是两个相互独立的管道。在各自的管辖范围内，他们各自具有自己的一套机制对HTTP请求进行处理。两个管道通过ISAPI实现“连通”，IIS是第一道屏障，当对HTTP请求进行必要的前期处理后，IIS通过ISAPI将请求分发给ASP.NET管道。当ASP.NET在自身管道范围内完成对HTTP请求的处理时，处理后的结果再返回到IIS，IIS对其进行后期处理后生成HTTP回复对请求予以响应。

从另一个角度讲，IIS运行在非托管的环境中，而ASP.NET管道则是托管的，所以说ISAPI还是连接非托管环境和托管环境的纽带。

把两个管道进行隔离至少带来了下面的一些局限与不足。

1.相同操作的重复执行。

2.动态文件与静态文件处理的不一致。

3.IIS难以扩展。

为此在IIS7.0中实现了两者的集成，通过集成可以获得如下的好处。

1.允许通过本地代码和托管代码两种方式定义IIS Module，这些IISModule注册到IIS中形成一个通用的请求处理管道。由这些IISModule组成的这个管道能够处理所有的请求，不论请求基于怎样的资源类型。

2.将ASP.NET提供的一些强大的功能应用到原来难以企及的地方。

3.采用相同的方式去实现、配置、检测和支持一些服务器特性。

在下一章我们详细讲解一下ASP.NET通道。

原文：http://blog.csdn.net/yejinwei1220/article/details/45665997