IIS/ASP.NET 管道模式

IIS 5.x 与 ASP.NET

构成

IIS 5.x 运行在进程InetInfo.exe 中，该进程还寄宿着一个名为 World Wide Web Publishing Service（简称 W3SVC）的 Windows 服务。这个服务主要任务负责HTTP请求的监听、激活和管理工作进程、从 Metabase 中加载配置等。

请求流程

1. W3SVC检测到Http请求
2. IIS 根据扩展名判断请求的是静态资源（如：.html、.img、.txt、.xml 等）还是动态资源。对于前者，IIS会将文件内容直接响应给用户；对于后者，则通过扩展名从IIS脚本映射找到相应的 ISAPI 动态连接口
3. 如果我们请求的是一个基于ASP.NET资源，aspnet_isapi.dll 会被加载
4. ASP.NET ISAPI 随后会创建工作进程 aspnet_wp.exe（如果该进程尚未启动）
5. 对于IIS 5.x来说，该进程为 aspnet.exe
6. IIS 与工作进程之间通过命名管道（Named Pipes）进行通信
7. 在工作进程初始化的过程中，.net 运行时 会被加载以构建一个托管的环境，对于与某个Web应用的初次进球，CLR会为其创建一个应用程序域（Application Domain）
8. 寄宿在 IIS5.x 的所有应用都运行在同一个工作进程的不同应用程序域中

缺陷

1. ISAPI动态链接库被加载到 InetInfo.exe进程中，它与工作进程之间跨进程通信，尽管采用命名管道，但仍存在性能瓶颈
2. 所有ASP.NET 应用运行在同一个工作进程（aspnet_wp.exe）的不同应用程序域中，基于应用程序域的隔离并不能从根本上解决一个应用程序对另一个应用程序的影响
3. 利用 W3SVC 服务监听HTTP请求，并不稳定

IIS 6 与 ASP.NET

改进

1. 针对第一点：IIS 6.0 将 ISAPI动态链接库加载到工作进程中

2. 针对第二点：IIS 6.0 引入应用程序池的机制，我们可以为多个应用程序创建一个应用程序池，也可以为一个应用程序创建一个应用程序池，每一个应用程序池都是一个独立的工作进程（w3wp.exe）

3. 针对第三点：在IIS 6.0版，用于监听HTTP请求的不再是 W3SVC服务了，而是 HTTP.SYS 监听器，严格意义上讲，HTTP.SYS已经不属于 IIS 范畴了，他是TCP/IP网络层的一部分

4. 另外一点改变：W3SVC 服务不再运行在 InetInfo.exe进程中了，他独立出来运行在SvcHost.exe进程中。职责也不再负责HTTP请求的监听了，而单纯的座位IIS的管理进程

请求流程

1. HTTP.SYS监听到HTTP请求后，将其分发给W3SVC
2. W3SVC 解析出URL，并且从Metabase元数据中获取到URL与Web应用之间的映射关系得到目标应用，进而得到目标应用运行的工作进程以及应用程序池
3. 如果工作进程不存在，则创建新的工作进程
4. 在工作进程初始化的过程中，相应的ISAPI动态链接库被加载
5. 对于ASP.NET应用来说，被加载的是aspnet_isapi.dll ，ASP.NET ISAPI负责进行CLR的加载、应用程序域的创建，以及Web应用的初始化等操作

缺陷

1. W3SVC 服务既有接收来自HTTP.SYS监听到的请求，又要创建、管理工作进程，负担比较中
2. 当W3SVC 服务接收到请求，URL与Web应用的对应关系是从 Metabase中找的，这并不符合业界标准

IIS 7 与 ASP.NET

改进

1. 针对第一点，IIS 7.0 引入Web进程激活服务（Windows Process Activation Service）简称 WAS，它将之前W3SVC负责的URL域应用程序映射以及工作进程的管理负责起来，W3SVC只需将HTTP.SYS监听到的请求传递给WAS即可
2. 针对第二点，与IIS 5.x、IIS 6.0不急于Metabase的配置信息存储不同的是，IIS 7.0 大都将配置信息以XML形式存与 applicationHost.config 中