IIS请求处理过程比较

IIS5、IIS6、IIS7的ASP.net请求处理过程比较ASP.NET是一个非常强大的构建Web应用的平台，它提供了极大的灵活性和能力以致于可以用它来构建所有类型的Web应用。绝大多数的人只熟悉高层的框架如：WebForms和WebServices--这些都在ASP.NET层次结构在最高层。这篇文章的资料收集整理自各种微软公开的文档，通过比较IIS5、IIS6、IIS7这三代IIS对请求的处理过程，让我们熟悉ASP.NET的底层机制并对请求(request)是怎么从Web服务器传送到ASP.NET运行时有所了解。通过对底层机制的了解，可以让我们对ASP.net有更深的理解。IIS5的ASP.net请求处理过程对图的解释：IIS5.x一个显著的特征就是WebServer和真正的ASP.NETApplication的分离。作为WebServer的IIS运行在一个名为InetInfo.exe的进程上，InetInfo.exe是一个NativeExecutive，并不是一个托管的程序，而我们真正的ASP.NETApplication则是运行在一个叫做aspnet_wp的WorkerProcess上面，在该进程初始化的时候会加载CLR，所以这是一个托管的环境。ISAPI：指能够处理各种后缀名的应用程序。ISAPI是下面单词的简写：InternetServerApplicationProgrameInterface，互联网服务器应用程序接口。IIS5模式的特点：1、首先，同一台主机上在同一时间只能运行一个aspnet_wp进程，每个基于虚拟目录的ASP.NETApplication对应一个ApplicationDomain，也就是说每个Application都运行在同一个WorkerProcess中，Application之间的隔离是基于ApplicationDomain的，而不是基于Process的。2、其次，ASP.NETISAPI不但负责创建aspnet_wpWorkerProcess，而且负责监控该进程，如果检测到aspnet_wp的Performance降低到某个设定的下限，ASP.NETISAPI会负责结束掉该进程。当aspnet_wp结束掉之后，后续的Request会导致ASP.NETISAPI重新创建新的aspnet_wpWorkerProcess。3、最后，由于IIS和Application运行在他们各自的进程中，他们之间的通信必须采用特定的通信机制。本质上IIS所在的InetInfo进程和WorkerProcess之间的通信是同一台机器不同进程的通信（localinterprocesscommunications），处于Performance的考虑，他们之间采用基于Namedpipe的通信机制。ASP.NETISAPI和WorkerProcess之间的通信通过他们之间的一组Pipe实现。同样处于Performance的原因，ASP.NETISAPI通过异步的方式将Request传到WorkerProcess并获得Response，但是WorkerProcess则是通过同步的方式向ASP.NETISAPI获得一些基于Server的变量。IIS6的ASP.net请求处理过程对图的解释：IIS5.x是通过InetInfo.exe监听Request并把Request分发到WorkProcess。换句话说，在IIS5.x中对Request的监听和分发是在UserMode中进行，在IIS6中，这种工作被移植到kernelMode中进行，所有的这一切都是通过一个新的组件：http.sys来负责。注：为了避免用户应用程序访问或者修改关键的操作系统数据，windows提供了两种处理器访问模式：用户模式（UserMode）和内核模式（KernelMode）。一般地，用户程序运行在Usermode下，而操作系统代码运行在KernelMode下。KernelMode的代码允许访问所有系统内存和所有CPU指令。在UserMode下，http.sys接收到一个基于aspx的httprequest，然后它会根据IIS中的Metabase查看该基于该Request的Application属于哪个ApplicationPool，如果该ApplicationPool不存在，则创建之。否则直接将request发到对应ApplicationPool的Queue中。每个ApplicationPool对应着一个WorkerProcess：w3wp.exe，毫无疑问他是运行在UserMode下的。在IISMetabase中维护着ApplicationPool和workerprocess的Mapping。WAS（WebAdministrativeservice）根据这样一个mapping，将存在于某个ApplicationPoolQueue的request传递到对应的workerprocess(如果没有，就创建这样一个进程)。在workerprocess初始化的时候，加载ASP.NETISAPI，ASP.NETISAPI进而加载CLR。最后的流程就和IIS5.x一样了：通过AppManagerAppDomainFactory的Create方法为Application创建一个ApplicationDomain；通过ISAPIRuntime的ProcessRequest处理Request，进而将流程进入到ASP.NETHttpRuntimePipeline。IIS7的ASP.net请求处理过程IIS7站点启动并处理请求的步骤如下图：步骤1到6，是处理应用启动，启动好后，以后就不需要再走这个步骤了。上图的8个步骤分别如下：1、当客户端浏览器开始HTTP请求一个WEB服务器的资源时，HTTP.sys拦截到这个请求。2、HTTP.syscontactsWAStoobtaininformationfromtheconfigurationstore.3、WAS向配置存储中心请求配置信息。applicationHost.config。4、服务接受到配置信息，配置信息指类似应用程序池配置信息，站点配置信息等等。5、处理策略。6、WASstartsaworkerprocessfortheapplicationpooltowhichtherequestwasmade.7、TheworkerprocessprocessestherequestandreturnsaresponsetoHTTP.sys.8、客户端接受到处理结果信息。W3WP.exe进程中又是如果处理得呢？？IIS7的应用程序池的托管管道模式分两种：经典和集成。这两种模式下处理策略各不相通。IIS6以及IIS7经典模式的托管管道的架构在IIS7之前，ASP.NET是以IISISAPIextension的方式外加到IIS，其实包括ASP以及PHP，也都以相同的方式配置（PHP在IIS采用了两种配置方式，除了IISISAPIextension的方式，也包括了CGI的方式，系统管理者能选择PHP程序的执行方式），因此客户端对IIS的HTTP请求会先经由IIS处理，然后IIS根据要求的内容类型，如果是HTML静态网页就由IIS自行处理，如果不是，就根据要求的内容类型，分派给各自的IISISAPIextension；如果要求的内容类型是ASP.NET，就分派给负责处理ASP.NET的IISISAPIextension，也就是aspnet_isapi.dll。下图是这个架构的示意图。IIS7应用程序池的托管管道模式经典模式也是这样的工作原理。这种模式是兼容IIS6的方式，以减少升级的成本。IIS6的执行架构图，以及IIS7应用程序池配置成经典模式的执行架构图IIS7应用程序池的托管管道模式集成模式而IIS7完全整合.NET之后，架构的处理顺序有了很大的不同（如下图），最主要的原因就是ASP.NET从IIS插件（ISAPIextension）的角色，进入了IIS核心，而且也能以ASP.NET模块负责处理IIS7的诸多类型要求。这些ASP.NET模块不只能处理ASP.NET网页程序，也能处理其他如ASP程序、PHP程序或静态HTML网页，也因为ASP.NET的诸多功能已经成为IIS7的一部份，因此ASP程序、PHP程序或静态HTML网页等类型的要求，也能使用像是Forms认证（FormsAuthentication）或输出缓存（OutputCache）等ASP.NET2.0的功能（但须修改IIS7的设定值）。也因为IIS7允许自行以ASP.NETAPI开发并加入模块，因此ASP.NET网页开发人员将更容易扩充IIS7和网站应用程序的功能，甚至能自行以.NET编写管理IIS7的程序（例如以程控IIS7以建置网站或虚拟目录）。IIS7的执行架构图（集成托管信道模式下的架构）小结IIS5到IIS6的改进，主要是HTTP.sys的改进。IIS6到IIS7的改进，主要是ISAPI的改进。