本文主要介绍 3 个主要的 IIS 版本各自对 Web 请求的不同处理方式。

本文内容

• IIS 5.x 和 ASP.NET

• IIS 6.0 和 ASP.NET
• IIS 7.0 和 ASP.NET
• ASP.NET 集成

IIS 5.x 和 ASP.NET

IIS 5.x 运行在进程 inetinfo.exe 中，该进程寄宿着一个名为 World Wide Web Publishing Service（简称 W3SVC）的 Windows 服务中。W3SVC 主要功能，包括 HTTP 请求的监听、工作进程和配置管理（通过从元数据库 Metabase 中加载相关配置信息）等。

图 1 IIS 5.x 与 ASP.NET

当检测到某个 HTTP 请求时，IIS 先根据扩展名判断请求的是否为静态资源（如 .html、.img、.txt、.xml 等），如果是，则直接将文件内容以 HTTP 响应的形式返回；否则，若是动态资源（如 .aspx、.asp、.php等），则通过扩展名从 IIS 脚本映射（Script Map）中找到相应的 ISAPI 动态链接库。

ISAPI（Internet Server Application Programming Interface）是一套本地 Win32 API，是 IIS 和其他动态 Web 应用或平台之间的纽带。ISAPI定义在一个动态链接库（DLL）文件中，ASP.NET ISAPI 对应的DLL 文件为 aspnet_isapi.dll。ISAPI 支持 ISAPI 扩展（ISAPI Extension）和 ISAPI 筛选（ISAPI Filter），前者是真正处理 HTTP 请求的接口，后者可以在 HTTP 请求真正被处理前查看、修改、转发或拒绝请求，如 IIS 可以利用 ISAPI 筛选进行请求验证。

如果请求的是一个基于 ASP.NET 的资源类型，如 .aspx、.asmx 等，aspnet_isapi.dll 会被加载，而 ASP.NET Extension 会创建 ASP.NET 工作进程（若该进程未启动）。对于 IIS 5.x 来说，该工作进程为 aspnet_wp.exe。IIS 进程与工作进程之间通过命名管道（Named Pipes）通信。

在工作进程初始化过程中，.NET CLR 被加载，并构建一个托管环境。对于某个 Web 应用的初次请求，CLR 会为其创建一个应用程序域（Application Domain）。在应用程序域中，HTTP 运行时（HTTP Runtime）被加载，并创建相应的应用。寄宿于 IIS 5.x 的所有 Web 应用都运行在同一个工作进程（aspnet_wp.exe）的不同应用程序域中。

IIS 6.0与ASP.NET

• 1，ISAPI动态链接库被加载到Inetinfo.exe 进程中，它与工作进程aspnet_wp.exe 之间是一种典型的跨进程通信方式，尽管采用命名管道，但仍存在性能瓶颈；

• 2，所有Web应用运行在相同进程（aspnet_wp.exe）中不同的应用程序域。基于应用程序域的隔离，不能从根本上解决一个应用程序对另一个应用程序的影响。

为了解决第一个问题，IIS 6.0 将 ISAPI 动态链接库直接加载到工作进程；

为了解决第二个问题，引入应用程序池（Application Pool）机制。可以为一个或多个 Web 应用创建应用程序池。由于每个应用程序池对应一个独立的工作进程，从而为运行在不同应用程序池中的 Web 应用提供基于进程的隔离级别。IIS 6.0 工作进程名为 w3wp.exe。

除了以上两点改进外，IIS 6.0 还有一些值得称道的地方。其中最重要的一点就是创建了一个名为 HTTP.SYS 的 HTTP 监听器。HTTP.SYS 以驱动程序形式运行在 Windows 内核模式（kernel Mode）下，它是 Windows 2003 的 TCP/IP 网络子系统的一部分，从结构上看它属于 TCP 之上的一个网络驱动程序。

严格来说，HTTP.SYS 已经不属于 IIS 的范畴，所以 HTTP.SYS 的配置信息也没有保存在 IIS 的 Metabase 中，而是定义在注册表中。HTTP.SYS 的好处如下：

• 1，持续监听。由于 HTTP.SYS 是一个网络驱动程序，始终处于运行状态，对用户的 HTTP 请求能够及时作出反应；

• 2，更好的稳定性。HTTP.SYS 运行在操作系统内核模式下，不执行任何用户代码，所以其本身不会受到 Web 应用、工作进程和 IIS 进程的影响；
• 3，内核模式下数据缓存。若某个资源被频繁请求，HTTP.SYS 会把响应内存缓存，缓存内容可以直接响应后续请求。由于这是基于内核模式的缓存，不存在内核模式和用户模式的切换，响应速度将得到极大改进。

图 2 所示，描述IIS的结构和处理 HTTP 请求的流程。与 IIS 5.x 不同，W3SVC 从 inetinfo.exe 进程脱离出来（对 IIS 6.0 来说，inetinfo.exe 基本上可以看作单纯的 IIS 管理进程），运行在另一个进程svchost.exe 中。W3SVC 的基本功能没有变化，只是在功能的实现上做了相应改进。与IIS 5.x一样，Metabase 依然存在于 inetinfo.exe 进程中。

图 2 IIS 6.0 与 ASP.NET

当HTTP.SYS 监听到用户 HTTP 请求时，将其分发给 W3SVC，W3SVC 解析出请求的 URL，并根据从 Metabase 获取的 URL与Web 应用之间的映射关系得到目标应用，并进一步得到目标应用运行的应用程序池或工作进程。若工作进程不存在（尚未创建或被回收），则为该请求创建新的工作进程。在工作进程初始化过程中，相应的 ISAPI 动态链接库被加载。对于 ASP.NET应用来说，被加载的 ISAPI为aspnet_iaspi.dll。ASP.NET ISAPI 再负责进行 CLR 的加载、应用程序域的创建和Web应用的初始化等操作。

IIS 7.0 与 ASP.NET

• 1，HTTP请求接收。接收HTTP.SYS监听到的HTTP请求；

• 2，配置管理。从Metabase中加载配置信息对相关组件进行配置；
• 3，进程管理。创建、回收、监控工作进程。

IIS 7.0 将后两个功能实现到 WAS中。WAS 的引入为了IIS 7.0 提供了对非 HTTP 协议的支持。WAS 通过监听器适配器接口（Listener Adapter Interface）抽象出不同协议监听器，如TCP监听器、命名管道监听器、MSMQ 监听器。

图 3 显示 IIS 7.0 的整体构架及整个请求处理流程。无论是从 W3SVC接收到的 HTTP 请求，还是通过 WCF 监听适配器接收到的请求，最终都会传递到 WAS。若相应的工作进程（或应用程序池）尚未创建，则创建；否则，将请求分发给对应的工作进程后续的处理。WAS在进行请求处理过程中，通过内置的配置管理模块加载相关的配置信息，并对相关信息进行配置。与 IIS 5.x 和 IIS 6.0 基于 Metabase 的配置信息存储不同，IIS 7.0 大都将配置信息以 XML 文件形式存储，基本配置存放在 Applicationhost.config中。

图 3 IIS 7.0 与 ASP.NET

ASP.NET 集成

但是 IIS 5.x 和 IIS 6.0 的双管道设计存在一些局限和不足。

为此，IIS 7.0 实现了两者的集成。