标签：style blog http io os sp strong 文件 数据
本文主要介绍 3 个主要的 IIS 版本各自对 Web 请求的不同处理方式。
IIS 5.x 如何处理基于 ASP.NET 资源（如 .aspx、.asmx 等）请求的。
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 5.x 至少存在两个不足：
为了解决第一个问题，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 的好处如下：
图 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 在请求监听和分发机制上又进行了改进。主要体现在引入了Windows进程激活服务（Windows Process Activation Service，WAS），将原来IIS 6.0 W3SVC的部分功能分流给了 WAS。对于IIS 6.0 W3SVC主要有三个功能：
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
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 实现了两者的集成。
标签：style blog http io os sp strong 文件 数据
原文地址：http://www.cnblogs.com/liuning8023/p/4074203.html
