IIS 5.x/6.0/7.0 和 ASP.NET

原文:IIS 5.x/6.0/7.0 和 ASP.NET

本文主要介绍 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 如何处理 ASP.NET 资源（如 .aspx、.asmx 等）请求。

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

资源映射被存储在 IIS 的 metabase 中。在安装时，ASP.NET 修改 IIS 的 metabase，以确保 aspnet_isapi.dll 能够处理所有的按照扩展名识别的资源。

图 1 IIS 5.x 与 ASP.NET

当对一个资源的 HTTP 请求到达时，IIS 首先根据扩展名判断确认资源类型。若为静态资源（如图像、文本文件、HTML页面、没有脚本的 ASP 页面等），不使用外部模块，由 IIS 直接处理，直接将内容以 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 筛选进行请求验证。

ISAPI 扩展不处理 .aspx 文件，而是起到调度程序的作用。它收集有关被调用的 URL 和底层资源的所有相关信息，然后将请求转发给 ASP.NET 工作进程。

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

ASP.NET 工作进程表示 ASP.NET 运行库环境，由一个名为 aspnet_wp.exe 的 Win32 非托管可执行文件组成，该文件上寄宿了 .NET 公共语言运行库（CLR）。ASP.NET 工作进程激活 HTTP 管道，由它实际处理页面请求。HTTP 管道是 .NET Framework 类的集合，负责编译页面程序集以及实例化有关的页面类。

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

IIS 6.0与ASP.NET

---

IIS 5.x 至少存在两个不足：

• 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应用的初始化等操作。

图  3 IIS 6.0 中如何处理 Web 应用程序

IIS 7.0 与 ASP.NET

---

IIS 7.0 在请求监听和分发机制上又进行了改进。主要体现在引入了Windows进程激活服务（Windows Process Activation Service，WAS），将原来IIS 6.0 W3SVC的部分功能分流给了 WAS。对于IIS 6.0 W3SVC主要有三个功能：

• 1，HTTP请求接收。接收HTTP.SYS监听到的HTTP请求；
• 2，配置管理。从Metabase中加载配置信息对相关组件进行配置；
• 3，进程管理。创建、回收、监控工作进程。

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

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

图 4 IIS 7.0 与 ASP.NET

ASP.NET 集成

---

IIS 5.x 和 IIS 6.0，IIS 与 ASP.NET 是两个相互独立的管道。在各自范围内，具有自己的一套机制处理 HTTP 请求。两个管道通过 ISAPI 连接。IIS 是第一道，对 HTTP 请求进行前期处理，如身份验证，通过 ISAPI 将请求分发给 ASP.NET 管道。当 ASP.NET 完成对 HTTP 请求处理后，处理后的结果返回到 IIS，IIS 对其进行后期处理，如日志记录、压缩等，最终生成 HTTP 响应。

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

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