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

8/10/2015来源:ASP.NET技巧人气:1499

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

图 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

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

5

图 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中。

6

图 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 实现了两者的集成。