WCF技术剖析之二:再谈IIS与ASP.NET管道

原文: WCF技术剖析之二:再谈IIS与ASP.NET管道

在2007年9月份,我曾经写了三篇详细介绍IIS架构和ASP.NET运行时管道的文章,深刻介绍了IIS 5.x与IIS 6.0HTTP请求的监听与分发机制,以及ASP.NET运行时管道对HTTP请求的处理流程:php

[原创]ASP.NET Process Model之一:IIS 和 ASP.NET ISAPI
[原创]ASP.NET Process Model之二:ASP.NET Http Runtime Pipeline - Part I
[原创]ASP.NET Process Model之二:ASP.NET Http Runtime Pipeline - Part II css

不少人留言为什么没有IIS 7的介绍。在写做《WCF深刻剖析》中,为了剖析基于IIS的WCF服务寄宿(Hosting),再次对相关内容进行了研究,在这里一并与你们分享。html

IIS 5.x与ASP.NETweb

咱们先来看看IIS 5.x是如何处理基于ASP.NET资源(好比.aspx,.asmx等)请求的,整个过程基本上能够经过图1体现。 数据库

IIS 5.x运行在进程InetInfo.exe中,在该进程中一个最重要的服务就是名为World Wide Web Publishing Service(简称W3SVC)的Windows Service。W3SVC的主要功能包括HTTP请求的监听、工做进程的管理以及配置管理(经过从Metabase中加载相关配置信息)等。 编程

当检测到某个HTTP Request后,先根据扩展名判断请求的是不是静态资源(好比.html,.img,.txt,.xml等),若是是则直接将文件内容以HTTP Response的形式返回。若是是动态资源(好比.aspx,asp,php等等),则经过扩展名从IIS的脚本影射(Script Map)找到相应的ISAPI Dll。 api

clip_image002
 

 图1 IIS 5.x与ASP.NET 缓存

ISAPI是Internet服务器API(Internet Server Application Programming Interface)的缩写,是一套本地的(Native)Win32 API,具备较高的执行性能,是IIS和其余动态Web应用或者平台之间的纽带。好比ASP ISAPI桥接IIS与ASP,而ASP.NET ISAPI则链接着IIS与ASP.NET。ISPAI定义在一个Dll中,ASP.NET ISAPI对应的Dll为Aspnet_isapi.dll,你能够在目录“%windir%\Microsoft.NET\Framework\{version no}\”中找到该Dll。 安全

ISAPI支持ISAPI扩展(ISAPI Extension)和ISAPI筛选(ISAPI Filter),前者是真正处理HTTP请求的接口,后者则能够在HTTP请求真正被处理以前查看、修改、转发或者拒绝请求,好比IIS能够利用ISAPI筛选进行请求的验证(Authentication)。 服务器

若是咱们请求的是一个基于ASP.NET的资源类型,好比:.aspx Web Page、 .asmx Web Service或者.svc WCF Service等,Aspnet_isapi.dll会被加载,ASP.NET ISAPI扩展会建立ASP.NET的工做进程(若是该进程还没有启动),对于IIS 5.x来讲,该工做进程为aspnet.exe。IIS进程与工做进程之间经过命名管道(Named Pipes)进程通讯,以得到最好的性能。

在工做进程初始化过程当中,.NET 运行时(CLR)被加载,从而构建了一个托管的环境。对于某个Web应用的初次请求,CLR会为其建立一个AppDomain。在此AppDomain中,HTTP运行时(HTTP Runtime)被加载并用以建立相应的应用。对于寄宿于IIS 5.x的全部Web 应用都运行在同一个进程(工做进程Aspnet_wp.exe)的不一样AppDomain中。

IIS 6与ASP.NET

经过上面的介绍,咱们能够看出IIS 5.x至少存在着以下两个方面的不足:

  • ISAPI Dll被加载到InetInfo.exe进程中,它和工做进程之间是一种典型的跨进程通讯方式,尽管采用性能最好的命名管道,可是仍然会带来性能的瓶颈;
  • 全部的ASP.NET应用,运行在相同的进程(aspnet_wp.exe)中的不一样的应用程序域(AppDomain)中,基于应用程序域的隔离级别不能从根本上解决一个应用程序对另外一个程序的影响,在更多的时候,咱们须要不一样的Web应用运行在不一样的进程中。

在IIS 6.0中,为了解决第一个问题,ISAPI.dll被直接加载到工做进程中。为了解决第2个问题,引入了应用程序池(Application Pool)的机制。咱们能够为一个或者多个Web应用建立应用程序池,每个应用程序池对应一个独立的工做进程,从而为运行在不一样应用程序池中的Web应用提供基于进程的隔离级别。IIS 6.0的工做进程名称为w3wp.exe。

固然,除了上面两点改进以外,IIS 6.0还有其余一些值得称道的地方,其中最重要的一点就是建立了一个新的HTTP监听器:HTTP协议栈(HTTP Protocol Stack,HTTP.SYS)。HTTP.SYS运行在Windows的内核模式(Kernel Mode)下,做为驱动程序而存在。它是Windows 2003的TCP/IP网络子系统的一部分,从结构上,它属于TCP之上的一个网络驱动程序。严格地说,HTTP.SYS已经不属于IIS的范畴了,因此HTTP.SYS的配置信息并不保存在IIS的元数据库(Metabase),而是定义在注册表中。HTTP.SYS的注册表项位于下面的路径中:HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/HTTP。HTTP.SYS可以带来以下的好处:

  • 持续监听:因为HTTP.SYS是一个网络驱动程序,始终处于运行状态,对于用户的HTTP请求,可以及时做出反应;
  • 更好的稳定性:HTTP.SYS运行在操做系统内核模式下,并不执行任何用户代码,因此其自己不会受到Web应用、工做进程和IIS进程的影响;
  • 内核模式下数据缓存:若是某个资源被频繁请求,HTTP.SYS会把响应的内容进行缓存,缓存的内容能够直接响应后续的请求。因为这是基于内核模式的缓存,不存在内核模式和用户模式的切换,响应速度将获得极大的改进。

图2体现了IIS的结构和处理HTTP请求的流程。从中能够看出,与IIS 5.x不一样,W3SVC从InetInfo.exe进程脱离出来(对于IIS6.0来讲,InetInfo.exe基本上能够看做单纯的IIS管理进程),运行在另外一个进程SvcHost.exe中。不过W3SVC的基本功能并无发生变化,只是在功能的实现上做了相应的改进。与IIS 5.x同样,元数据库(Metabase)依然存在于InetInfo.exe进程中。

clip_image004
 

 图2 IIS 6与ASP.NET

当HTTP.SYS监听到用户的HTTP请求后,将其分发给W3SVC。W3SVC解析出请求的URL,并根据从Metabase获取的URL与Web应用之间的映射关系获得目标应用,并进一步获得目标应用运行的应用程序池或者工做进程。若是工做进程不存在(还没有建立或者被回收),则为该请求建立新的工做进程,工做进程的这种建立方式被称为请求式建立。在工做进程的初始化过程当中,相应的ISAPI.dll被加载,对于ASP.NET应用来讲,被加载的ISAPI.dll为Aspnet_ispai.dll。ASP.NET ISAPI再负责进行CLR的加载、AppDomain建立、Web Application的初始化等。

IIS 7.0与ASP.NET

IIS 7.0对请求的监听和分发机制上又进行了革新性的改进,主要体如今对于Windows进程激活服务(Windows Process Activation Service,WAS)的引入,将原来(IIS 6.0)W3SVC承载的部分功能分流给了WAS。具体来讲,经过上面的介绍,咱们知道对于IIS 6.0来讲,W3SVC主要承载着三大功能:

  • HTTP请求接收:接收HTTP.SYS监听到的HTTP请求;
  • 配置管理:从元数据库(Metabase)中加载配置信息对相关组件进行配置;
  • 进程管理:建立、回收、监控工做进程。

在IIS 7.0,后两组功能被移入WAS中,接收HTTP请求的任务依然落在W3SVC头上。WAS的引入为IIS 7.0一项史无前例的特性:同时处理HTTP和非HTTP请求。在WAS中,经过一个重要的接口:监听器适配器接口(Listener Adapter Interface)抽象出不一样协议监听器监听到的请求。至于IIS下的监听器,除了基于网络驱动的HTTP.SYS提供HTTP请求监听功能外,WCF提供了3种类型的监听器:TCP监听器、命名管道(Named Pipes)监听器和MSMQ监听器,分别提供了基于TCP、命名管道和MSMQ传输协议的监听功能。与此3种监听器相对的,是3种监听器适配器(Adapter)提供监听器与监听器适配器接口之间的适配。从这个意义上讲,IIS 7.0中的W3SVC更多地为HTTP.SYS起着监听适配器的功能。WCF提供的这3种监听器和监听适配器定义在程序集SMHost.exe中,你能够经过下面的目录找到该程序集:%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundatio。

WCF提供的这3种监听器和监听适配器最终以Windows Service的形式体现,虽然它们定义在一个程序集中,咱们依然经过服务工做管理器(SCM,Service Control Manager)对其进行单独的启动、终止和配置。SMHost.exe提供了4个重要的Windows Service:

  • NetTcpPortSharing为WCF提供TCP端口共享,关于端口共享;
  • NetTcpActivator为WAS提供基于TCP的激活请求,包含TCP监听器和对应的监听适配器;
  • NetPipeActivator为WAS提供基于命名管道的激活请求,包含命名管道监听器和对应的监听适配器;
  • NetMsmqActivator为WAS提供基于MSMQ的激活请求,包含MSMQ监听器和对应的监听适配器。

图3为上述的4个Windows Service在服务控制管理器(SCM)中的呈现。

clip_image006 

图3 定义在SMHost.exe中的Windows Service

图4揭示了IIS 7.0的总体构架以及整个请求处理流程。不管是从W3SVC接收到的HTTP请求,仍是经过WCF提供的监听适配器接收到的请求,最终都会传递到WAS。若是相应的工做进程(或者应用程序池)还没有建立,其建立之;不然将请求分发给对应的工做进程进行后续的处理。WAS在进行请求处理过程当中,经过内置的配置管理模块加载相关的配置信息对相关的组建进行配置,与IIS 5.x和IIS 6.0基于Metabase的配置信息存储不一样的是,IIS 7.0大都将配置信息存放于XML形式的配置文件中。基本的配置存放在applicationHost.cofig中。

clip_image008 
图4 IIS 7与ASP.NET

 

ASP.NET集成

从上面对IIS 5.x和IIS 6.0的介绍中,咱们不难发现这一点,IIS与ASP.NET是两个相互独立的管道(Pipeline),在各自管辖范围内,它们各自具备本身的一套机制对HTTP请求进行处理。两个管道经过ISAPI实现“联通”:IIS是第一道屏障,当对HTTP请求进行必要的前期处理(好比身份验证等)后,经过ISAPI将请求分发给ASP.NET管道。当ASP.NET在自身管道范围内完成对HTTP请求的处理后,处理后的结果再返回到IIS,IIS对其进行后期处理(好比日志记录、压缩等),最终生成HTTP响应(HTTP Response)。从另外一个角度讲,IIS运行在非托管的环境中,而ASP.NET管道则是托管的,从这个意义上讲,ISAPI仍是链接非托管环境和托管环境的纽带。图5反映了IIS 6.0与ASP.NET之间的桥接关系。

clip_image012 

图5 基于IIS 6.0与ASP.NET双管道设计

IIS 5.x和IIS 6.0下把两个管道进行隔离至少带来了下面一些局限与不足:

  • 相同操做的重复执行:IIS与ASP.NET之间具备一些重复的操做,好比身份验证;
  • 动态文件与静态文件处理的不一致:由于只有基于ASP.NET的动态文件(好比.aspx、.asmx、.svc等等)的HTTP请求才能经过ASP.NET ISAPI进入ASP.NET管道,而对于一些静态文件(好比.html、.xml、.img等)的请求,则由IIS直接响应,那么ASP.NET管道中的一些功能将不能用于这些基于静态文件的请求,好比,咱们但愿经过Forms认证应用于基于图片文件的请求;
  • IIS难以扩展:对于IIS的扩展基本上就体如今自定义ISAPI,可是对于大部分人来讲,这不是一件容易的事情。由于ISAPI是基于Win32的非托管的API,并不是一种面向应用的编程接口。一般咱们但愿的是诸如定义ASP.NET的HttpModule和HttpHandler同样,经过托管代码的方式来扩展IIS。

对于Windows平台下的IIS来说,ASP.NET无疑是一等公民,它们之间不该该是“井水不犯河水”的关系,而应该是“你中有我,我中有你”的关系。为此,在IIS 7.0中,实现了二者的集成。对于集成模式下的IIS 7.0,咱们得到以下的好处。

  • 容许咱们经过本地代码(Native Code)和托管代码(Managed Code)两种方式定义IIS Module,这些IIS Module注册到IIS中造成一个通用的请求处理管道。由这些IIS Module组成的这个管道可以处理全部的请求,不论请求基于怎样的资源类型。好比,能够将FormsAuthenticationModule提供的Forms认证应用到基于.aspx,CGI和静态文件的请求。
  • 将ASP.NET提供的一些强大的功能应用到原来难以企及的地方,好比将ASP.NET的URL重写功能置于身份验证以前;
  • 采用相同的方式去实现、配置、检测和支持一些服务器特性(Feature),好比Module、Handler映射、错误定制配置(Custom Error Configuration)等。

clip_image014

 图6 基于IIS 7.0与ASP.NET集成管道设计

图6演示了在ASP.NET集成模式下,IIS整个请求处理管道的结构。咱们能够看到,原来ASP.NET提供的托管组件能够直接应用在IIS管道中。

ASP.NET管道

以IIS 6.0为例,在工做进程w3wp.exe中,利用Aspnet_ispai.dll加载.NET运行时(若是.NET运行时还没有加载)。IIS 6引入了应用程序池的概念,一个工做进程对应着一个应用程序池。一个应用程序池能够承载一个或者多个Web应用,每一个Web应用映射到一个IIS虚拟目录。与IIS 5.x同样,每个Web应用运行在各自的应用程序域中。

若是HTTP.SYS接收到的HTTP请求是对该Web应用的第一次访问,当成功加载了运行时后,会经过AppDomainFactory为该Web应用建立一个应用程序域(AppDomain)。随后,一个特殊的运行时IsapiRuntime被加载。IsapiRuntime定义在程序集System.Web中,对应的命名空间为System.Web.Hosting。IsapiRuntime会接管该HTTP请求。

IsapiRuntime会首先建立一个IsapiWorkerRequest对象,用于封装当前的HTTP请求,并将该IsapiWorkerRequest对象传递给ASP.NET运行时:HttpRuntime,今后时起,HTTP请求正式进入了ASP.NET管道。根据IsapiWorkerRequest对象,HttpRuntime会建立用于表示当前HTTP请求的上下文(Context)对象:HttpContext。

随着HttpContext被成功建立,HttpRuntime会利用HttpApplicationFactory建立新的或者获取现有的HttpApplication对象。实际上,ASP.NET维护着一个HttpApplication对象池,HttpApplicationFactory从池中选取可用的HttpApplication用户处理HTTP请求,处理完毕后将其释放到对象池中。HttpApplicationFactory负责处理当前的HTTP请求。

在HttpApplication初始化过程当中,会根据配置文件加载并初始化相应的HttpModule对象。对于HttpApplication来讲,在它处理HTTP请求的不一样的阶段会触发不一样的事件(Event),而HttpModule的意义在于经过注册HttpApplication的相应的事件,将所需的操做注入整个HTTP请求的处理流程。ASP.NET的不少功能,好比身份验证、受权、缓存等,都是经过相应的HttpModule实现的。

而最终完成对HTTP请求的处理实如今另外一个重要的对象中:HttpHandler。对于不一样的资源类型,具备不一样的HttpHandler。好比.aspx页对应的HttpHandler为System.Web.UI.Page,WCF的.svc文件对应的HttpHandler为System.ServiceModel.Activation.HttpHandler。上面整个处理流程如图7所示。

clip_image016 

图7 ASP.NET 处理管道

HttpApplication

HttpApplication是整个ASP.NET基础架构的核心,它负责处理分发给它的HTTP请求。因为一个HttpApplication对象在某个时刻只能处理一个请求,只有完成对某个请求的处理后,HttpApplication才能用于后续的请求的处理。因此,ASP.NET采用对象池的机制来建立或者获取HttpApplication对象。具体来说,当第一个请求抵达的时候,ASP.NET会一次建立多个HttpApplication对象,并将其置于池中,选择其中一个对象来处理该请求。当处理完毕,HttpApplication不会被回收,而是释放到池中。对于后续的请求,空闲的HttpApplication对象会从池中取出,若是池中全部的HttpApplication对象都处于繁忙的状态,ASP.NET会建立新的HttpApplication对象。

HttpApplication处理请求的整个生命周期是一个相对复杂的过程,在该过程的不一样阶段会触发相应的事件。咱们能够注册相应的事件,将咱们的处理逻辑注入到HttpApplication处理请求的某个阶段。咱们接下来介绍的HttpModule就是经过HttpApplication事件注册的机制实现相应的功能的。表1按照实现的前后顺利列出了HttpApplication在处理每个请求时触发的事件名称。

表1

名称

描述

BeginRequest

HTTP管道开始处理请求时,会触发BeginRequest事件

AuthenticateRequest,PostAuthenticateRequest

ASP.NET前后触发这两个事件,使安全模块对请求进行身份验证

AuthorizeRequest,PostAuthorizeRequest

ASP.NET前后触发这两个事件,使安全模块对请求进程受权

ResolveRequestCache,PostResolveRequestCache

ASP.NET前后触发这两个事件,以使缓存模块利用缓存的直接对请求直接进程响应(缓存模块能够将响应内容进程缓存,对于后续的请求,直接将缓存的内容返回,从而提升响应能力)。

PostMapRequestHandler

对于访问不一样的资源类型,ASP.NET具备不一样的HttpHandler对其进程处理。对于每一个请求,ASP.NET会经过扩展名选择匹配相应的HttpHandler类型,成功匹配后,该实现被触发

AcquireRequestState,PostAcquireRequestState

ASP.NET前后触发这两个事件,使状态管理模块获取基于当前请求相应的状态,好比SessionState

PreRequestHandlerExecute,PostRequestHandlerExecute

ASP.NET最终经过一请求资源类型相对应的HttpHandler实现对请求的处理,在实行HttpHandler先后,这两个实现被前后触发

ReleaseRequestState,PostReleaseRequestState

ASP.NET前后触发这两个事件,使状态管理模块释放基于当前请求相应的状态

UpdateRequestCache,PostUpdateRequestCache

ASP.NET前后触发这两个事件,以使缓存模块将HttpHandler处理请求获得的相应保存到输出缓存中

LogRequest,PostLogRequest

ASP.NET前后触发这两个事件为当前请求进程日志记录

EndRequest

整个请求处理完成后,EndRequest事件被触发

对于一个ASP.NET应用来讲,HttpApplication派生于global.asax文件,咱们能够经过建立global.asax文件对HttpApplication的请求处理行为进行定制。global.asax采用一种很直接的方式实现了这样的功能,这种方式既不是咱们经常使用的方法重写(Method Overriding)或者事件注册,而是直接采用方法名匹配。在global.asax中,咱们按照这样的方法命名规则进行事件注册:Application_{Event Name}。好比Application_BeginRequest方法用于处理HttpApplication的BeginRequest事件。若是经过VS建立一个global.asax文件,下面是默认的定义。

   1: <%@ Application Language="C#" %>
   2: <script runat="server">
   3: void Application_Start(object sender, EventArgs e) {}
   4: void Application_End(object sender, EventArgs e) {}
   5: void Application_Error(object sender, EventArgs e) {}
   6: void Session_Start(object sender, EventArgs e) {}
   7: void Session_End(object sender, EventArgs e) {}
   8: </script>

HttpModule

ASP.NET为建立各类.NET Web应用提供了强大的平台,它拥有一个具备高度可扩展性的引擎,而且可以处理对于不一样资源类型的请求。那么,是什么成就了ASP.NET的高可扩展性呢? HttpModule功不可没。

从功能上讲,HttpModule之于ASP.NET,就比如ISAPI Filter之于IIS同样。IIS将接收到的请求分发给相应的ISAPI Extension以前,注册的ISAPI Filter会先截获该请求。ISAPI Filter能够获取甚至修改请求的内容,完成一些额外的功能。与之类似地,当请求转入ASP.NET管道后,最终负责处理该请求的是与请求资源类型相匹配的HttpHandler对象,可是在Handler正式工做以前,ASP.NET会先加载并初始化全部配置的HttpModule对象。HttpModule在初始化的过程当中,会将一些功能注册到HttpApplication相应的事件中,那么在HttpApplication整个请求处理生命周期中的某个阶段,相应的事件会被触发,经过HttpModule注册的事件处理程序也得以执行。

全部的HttpModule都实现了IHttpModule接口,下面是IHttpModule的定义。其中Init方法用于实现HttpModule自身的初始化,该方法接受一个HttpApplication对象,有了这个对象,事件注册就很容易了。

   1: public interface IHttpModule
   2: {
   3:      void Dispose();
   4:     void Init(HttpApplication context);
   5: }

ASP.NET提供的不少基础构件(Infrastructure)功能都是经过相应的HttpModule实现的,下面类列出了一些典型的HttpModule:

  • OutputCacheModule:实现了输出缓存(Output Caching)的功能;
  • SessionStateModule:在无状态的HTTP协议上实现了基于会话(Session)的状态;
  • WindowsAuthenticationModule + FormsAuthenticationModule + PassportAuthentication- Module:实现了3种典型的身份认证方式:Windows认证、Forms认证和Passport认证;
  • UrlAuthorizationModule + FileAuthorizationModule:实现了基于Uri和文件ACL(Access Control List)的受权。

而另一个重要的HttpModule与WCF相关,那么就是System.ServiceModel. Activation.HttpModule。HttpModule定义在System.ServiceModel程序集中,在默认的状况下,HttpModule完成了基于IIS的寄宿工做。

除了这些系统定义的HttpModule以外,咱们还能够自定义HttpMoudle。经过Web.config,咱们能够很容易地将其注册到咱们的Web应用中。

HttpHandler

若是说HttpModule至关于IIS的ISAPI Filter的话,咱们能够说HttpHandler则至关于IIS的ISAPI Extension,HttpHandler在ASP.NET中扮演请求的最终处理者的角色。对于不一样资源类型的请求,ASP.NET会加载不一样的Handler来处理,也就是说.aspx page与.asmx web service对应的Handler是不一样的。

全部的HttpHandler都实现了接口IHttpHandler。下面是IHttpHandler的定义,方法ProcessRequest提供了处理请求的实现。

   1: public interface IHttpHandler
   2: {
   3:     void ProcessRequest(HttpContext context);
   4:     bool IsReusable { get; }
   5: }

对于某些HttpHandler,具备一个与之相关的HttpHandlerFactory,用于建立或者获取相应的HttpHandler。HttpHandlerFactory实现接口IHttpHandlerFactory,方法GetHandler用于建立新的HttpHandler,或者获取已经存在的HttpHandler。

   1: public interface IHttpHandlerFactory
   2: {
   3:     IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated);
   4:     void ReleaseHandler(IHttpHandler handler);
   5: }

HttpHandler和HttpHandlerFactory的类型均可以经过相同的方式配置到Web.config中。下面一段配置包含对3种典型的资源类型的HttpHandler配置:.aspx,.asmx和.svc。能够看到基于WCF Service的HttpHandler类型为:System.ServiceModel.Activation.HttpHandler。

   1: <?xml version="1.0" encoding="utf-8" ?>
   2: <configuration>
   3: <system.web>
   4: <httpHandlers>
   5: <add path="*.svc" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" validate="false"/>
   6: <add path="*.aspx" verb="*" type="System.Web.UI.PageHandlerFactory" validate="True"/>
   7: <add path="*.asmx" verb="*" type="System.Web.Services.Protocols.WebServiceHandlerFactory, System.Web.Services, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" validate="False"/>
   8: </httpHandlers>
   9: </system.web>
  10: </configuration>
做者: Artech
出处: http://artech.cnblogs.com 本文版权归做者和博客园共有,欢迎转载,但未经做者赞成必须保留此段声明,且在文章页面明显位置给出原文链接,不然保留追究法律责任的权利。
相关文章
相关标签/搜索