IIS5.x处理请求过程详解

经过一段时间的学习对IIS处理模型的了解，如有错误请指正 

(本文综于多篇文章的总结)

 

IIS5.x进程模型:

IIS 5.x特征如下：

服务器和asp.net应用程序分离，服务器运行于名为InetInfo.exe的进程上，InetInfo是在本地执行，并不是一个托管程序。而真正的asp.net应用程序是运行在名为aspnet_wp的工作进程上面，在该进程初始化的时候会加载CLR，这是一个托管环境。IIS接收到用户请求后，判断请求资源是否为静态资源，如果是静态的，将由IIS自己完成响应工作，最终将请些资源响应给客户端。如果不是静态资源，IIS将处理工作转交给ISAPI扩展，让它实现这个响应过程。

值得注意的是，对于asp.net的动态资源，其对应的ISAPI扩展为asp.net 扩展,由aspnet_isapi.dll扩展程序处理。

 

 

图中演示了用户向IIS服务器请求一个asp.net资源和static资源的处理流程

首先IIS运行在一个名为inetInfo.exe的进程中，它运行于本地，并不是一个托管程序。当客户在浏览器地址栏写入URL时，按下回车键，浏览器将找到对应的主机，通过端口号对其HTTP服务器（一个总称基于HTTP协议的服务器）发送一次GET请求，IIS服务器接收到这个HTTP请求之后，从HTTP请求格式的声明部分，可以找到客户端请求的方式及资源名称。

如果该资源为static，IIS在其对应的虚拟目录下找到该请求资源，并将其成响应，直接返回给Client。

此时更加复杂的处理是该用户请求的是一个非static源资，IIS对于这个请求，它将根据扩展名在ISAPI扩展的映射表中找到相应的ISA(扩展程序)，得知处理程序是一个asp.net扩展之后，就加载处理aspx后缀名的win32.dll(所有的ISAPI扩展都win32程序)程序（asp.net扩展，ISAPI扩展，只是范围的大小，类型的说法）,这里是aspnet_api.dll扩展程序处理的。asp.net扩展被IIS调用后，此时是asp.net扩展的工作流程。

asp.net扩展将会创建一个aspnet_wp进程（如果aspnet_wp进程不存在的话）,当初始化aspnet_wp进程的时候，会加载CLR（公共语言运行时，其时还有更标准的简称），这是一个托管环境，大多数asp.net程序都是托管代码，都依赖于这个环境。

 

初始化CLR的工作：

加载两个重要的dll：AppManagerAppDomainFactory和ISAPIRuntime。

通过AppManagerAppDomainFactory的Create方法为应程序创建一个应用程序域(Appdomain)。

 

此时涉及内个重要的概念：

应用程序:asp.net将应用程序定义为所有文件、页、处理程序、模块和可执行代码的总和,该应用程序可在 Web 应用程序服务器上的给定虚拟目录（及其子目录）的范围内调用或运行.

 

应用程序域: AppDomain是一个应用程序执行的独立环境,为执行托管代码提供隔离、卸载和安全边界. .net应用程序是由许多程序集组成的,然而不像win32程序,.net程序是在应用程序域中执行.应用程序域不同于win32的进程.实际上,一个进程可以有任意多的AppDomains,每个Appdomain之间是完全隔离的.运行在不同Appdomain中应用程序是不能共享信息的(全局变量,静态字段),除非用remoting.

 

在应用程序域和线程之间没有一对一的关联,多个线程可以属于一个应用程序域,尽管给定的线程并不局限于一个应用程序域,但在任何给定时间,线程都在一个应用程序域中执行."（来自.NET FrameWork SDK）多线程就是同一个应用程序域会有多个线程在上面执行.

可以对AppDomain进行动态加载卸载程序集.AppDomain是程序集的执行环境,程序集作为静态实体,其可以被多个appDomain加载执行.

 

创建了应用程序域之后的事情:

     通过ISAPIRuntime的ProcessRequest方法，将处理请求。流程进入到这里，这是很核心的一步，然而里面的工作是相当复杂的。(将来到Asp.net HTTP Runtime Pipeline的范畴，这是一个HTTP处理模型，也可以称为管道模型。)

   我们在后面将详细讲解此流程，先分析大致，再到细微。

 

 

对于从inetinfo进程(IIS,asp.net扩展)及aspnet_wp进程(asp.net)的工作有几点需知:

l         在同一主机，同一时间只能有一个aspnet_wp进程，对于每个虚拟目录，在aspnet_wp进程都会有相对应的应用程序域，它们之间实现的隔离是通过应用程序域(application Domain)实现，而不是基于进程间的实现的。

l         Asp.net扩展的工作不单单是创建aspnet_wp进程，它还负责监视该进程，当asp.net进程执行过程中的性能达到某个下限的时候，asp.net扩展将会卸载此进程(aspnet_wp)，然而后续的请求将会使得asp.net扩展重新创建并监视asp.net进程及运行情况。卸载是为了重新加载。

l         由于asp.net扩展和asp.net应用程序运行于不同的进程，然而它们如何做到相互交流信息的呢?

它们是通过特定的机制，特定的渠道来进行的，机制是IPC（进程间通讯Inter Process Communication）。而渠道是通过命名管道(Named pipe)。

它们之间的交流是相互的,就像HTTP协议一样。

注意的一点，这个命名管道和管道模型是不一样的概念。

管道模型它的描述在于asp.net进程中,命名管道是进程之间的。

 

 

 

对IIS5.x的补充：

Metabase:IIS配置元数据。

W3svc:该进程中一个重要的服务就是名为World wide web publishing service(简称W3SCV)的windows service。此服务主要功能包括HTTP请求监听，工作进程的管理以及配置管理（通过从Metabase中加载相关配置信息等）。

ISAPI:ISAPI是Internet服务器API(Internet Server Application Programming Interface)的缩写，是一套本地win32 API,具较高的执行性能，是IIS和其他动态WEB应用或者平台之间的纽带。

ISAPI支持ISAPI扩展及ISAPI筛选器，两者唯一不同的是前者是真正处理请求程序，而后者只是在请求及响应过程当中的一些工作。

 

 

 

IIS5.x的缺陷：

稳定性和性能永远是我们编程领域不变的主题,首先我们从性能上观察,inetinfo进程和工作线程aspnet_wp位于不同的线程，而线程之间的通信通过命名管道进行，虽然是异步进行，但是性能的问题不能得到根本解决。而从稳定性来看，asp.net运行只有一个进程aspnet_wp，而里面有着许多的应用程序，虽然通过应用程序域把各个application相互隔离，但如果aspnet_wp性达到某个下限的时候，inetinfo进程会把它卸载，那所有的application将受到影响，应用程序域的使用是可以增加运行的稳定性，但从分析看来，可想而知。

IIS6.x及IIS7.x都基于上述问题有及大的改进。