Spring.net 学习笔记之ASP.NET底层架构(2)

IIS6通配符应用程序映射

如果你有一个ASP.NET应用程序需要处理虚拟目录的(或者是整个Web站点,如果配置为根目录的话)每一个请求,IIS6引入了新的称为通配符应用程序映射的概念.一个映射到通配符的ISAPI扩展在每个请求到来时都会被触发,而不管扩增名是什么.这意味着每个页面都会通过这个扩展来处理.这是一个强大的功能,你可以用这个机制来创建虚拟Url和不使用文件名的unix风格的URL.然而,使用这个设置的时候要注意,因为它会把所有的东西都传给你的应用,包括静态htm文件,图片,样式表等等.

IIS 5 和6以不同的方式工作

当一个请求来到时,IIS检查脚本映射(扩展名映射)然后把请求路由到aspnet_isapi.dll.这个DLL的操作和请求如何进入ASP.NET运行时在IIS5和6中是不同的.图2显示了这个流程的一个粗略概览.

在IIS5中,aspnet_isapi.dll直接寄宿在inetinfo.exe进程中,如果你设置了Web站点或虚拟目录的隔离度为中或高,则会寄宿在IIS单独的(被隔离的)工作进程中.当第一个ASP.NET请求来到,DLL(aspnet_isapi.dll)会开始另一个新进程aspnet_wp.exe并将请求路由到这个进程中来进行处理.这个进程依次加载并寄宿.NET运行时.每个转发到ISAPI DLL的请求都会通过命名管道调用被路由到这个进程来.

不同于以前版本的服务器,IIS6为ASP.NET做了全面的优化

IIS6-应用程序池万岁

IIS6对处理模型做了意义重大的改变,IIS不再直接寄宿象ISAPI扩展这样的外部可执行代码.IIS总是创建一个独立的工作线程-一个应用程序池-所有的处理都发生在这个进程中,包括ISAPI dll的执行.应用程序池是IIS6的一个很大的改进,因为它允许对指定线程中将会执行什么代码进行非常细粒度的控制.应用程序池可以在每个虚拟路径上或者整个Web站点上进行配置,这样你可以将每个Web应用隔离到它们自己的进程中,这样每个应用都将和其他运行在同一台机器上的Web应用完全隔离.如果一个进程崩溃了,不会影响到其他进程(至少在Web处理的观点上来看是如此).

不止如此,应用程序池还是高度可配置的.你可以通过设置池的执行扮演级别(execution impersonation level )来配置它们的运行安全环境,这使你可以定制赋予一个Web应用的权限(同样,粒度非常的细).对于ASP.NET的一个大的改进是,应用程序池覆盖了在machine.config文件中大部分的ProcessModel节的设置.这一节的设置在IIS5中非常的难以管理,因为这些设置是全局的而且不能在应用程序的web.config文件中被覆盖.当运行IIS6是,ProcessModel相关的设置大部分都被忽略了,取而代之的是从应用程序池中读取.注意这里说的是大部分-有些设置,如线程池的大小还有IO线程的设置还是从machine.config中读取,因为它们在线程池的设置中没有对应项.

因为应用程序池是外部的可执行程序,这些可执行程序可以很容易的被监控和管理.IIS6提供了一系列的进行系统状况检查,重启和超时的选项,可以很方便的用来检查甚至在许多情况下可以修正程序的问题.最后IIS6的应用程序池并不像IIS5的隔离模式那样依赖于COM+,这样做一来可以提高性能,二来提高了稳定性(特别对某些内部需要调用COM组件的应用来说)

尽管IIS6的应用程序池是单独的EXE,但是它们对HTTP操作进行了高度的优化,它们直接和内核模式下的HTTP.SYS驱动程序进行通讯.收到的请求被直接路由给适当的应用程序池.InetInfo基本上只是一个管理程序和一个配置服务程序-大部分的交互实际上是直接在HTTP.SYS和应用程序池之间发生,所有这些使IIS6成为了比IIS5更加的稳定和高效的环境.特别对静态内容和ASP.NET程序来说这是千真万确的.

一个IIS6应用程序池对于ASP.NET有着天生的认识,ASP.NET可以在底层的API上和它进行交互,这允许直接访问HTTP缓存API,这样做可以将ASP.NET级别的缓存直接下发到Web服务器.

在IIS6中,ISAPI扩展在应用程序池的工作进程中运行. .NET运行时也在同一个进程中运行,所以ISAPI扩展和.NET运行时的通讯是发生在进程内的,这样做相比IIS5使用的命名管道有着天生的性能优势.虽然IIS的寄宿模型有着非常大的区别,进入托管代码的接口却异常的相似-只有路由消息的过程有一点区别.

ISAPIRuntime.ProcessRequest()函数是进入ASP.NET的第一站

理解 Http 管道

进入.NET运行时的真正的入口发生在一些没有被文档记载的类和接口中(译著:当然,你可以用Reflector来查看J).除了微软,很少人知道这些接口,微软的家伙们也并不热衷于谈论这些细节,他们认为这些实现细节对于使用ASP.NET开发应用的开发人员并没有什么用处.

工作进程(IIS5中是ASPNET_WP.EXE,IIS6中是W3WP.EXE)寄宿.NET运行时和ISAPI DLL,它(工作进程)通过调用COM对象的一个小的非托管接口最终将调用发送到ISAPIRuntime类的一个实例上(译注:原文为an instance subclass of the ISAPIRuntime class,但是ISAPIRuntime类是一个sealed类,疑为作者笔误,或者这里的subclass并不是子类的意思).进入运行时的第一个入口就是这个没有被文档记载的类,这个类实现了IISAPIRuntime接口(对于调用者说明来说,这个接口是一个COM接口)这个基于Iunknown的底层COM接口是从ISAPI扩展到ASP.NET的一个预定的接口.图3展示了IISAPIRuntime接口和它的调用签名.(使用了Lutz Roeder出色的.NET Reflector 工具http://www.aisto.com/roeder/dotnet/).这是一个探索这个步步为营过程的很好的方法.

如果你想深入这个接口,打开Reflector,指向System.Web.Hosting命名空间. ISAPI DLL通过调用一个托管的COM接口来打开进入ASP.NET的入口,ASP.NET接收一个指向ISAPI ECB的非托管指针.这个ECB包含访问完整的ISAPI接口的能力,用来接收请求和发送响应回到IIS.

IISAPIRuntime接口作为从ISAPI扩展来的非托管代码和ASP.NET之间的接口点(IIS6中直接相接,IIS5中通过命名管道).如果你看一下这个类的内部,你会找到含有以下签名的ProcessRequest函数:

[return: MarshalAs(UnmanagedType.I4)]
int ProcessRequest([In] IntPtr ecb,
[In, MarshalAs(UnmanagedType.I4)] int useProcessModel);

其中的ecb参数就是ISAPI扩展控制块(Extention Control Block),被当作一个非托管资源传递给ProcessRequest函数.这个函数接过ECB后就把它做为基本的输入输出接口,和Request和Response对象一起使用.ISAPI ECB包含有所有底层的请求信息,如服务器变量,用于表单(form)变量的输入流和用于回写数据到客户端的输出流.这一个ecb引用基本上提供了用来访问ISAPI请求所能访问的资源的全部功能,ProcessRequest是这个资源(ecb)最初接触到托管代码的入口和出口.

ISAPI扩展异步地处理请求.在这个模式下ISAPI扩展马上将调用返回到工作进程或者IIS线程上,但是在当前请求的生命周期上ECB会保持可用.ECB含有使ISAPI知道请求已经被处理完的机制(通过ecb.ServerSupportFunction方法)(译注:更多信息,可以参考开发ISAPI扩展的文章),这使得ECB被释放.这个异步的处理方法可以马上释放ISAPI工作线程,并将处理传递到由ASP.NET管理的一个单独的线程上.

ASP.NET接收到ecb引用并在内部使用它来接收当前请求的信息,如服务器变量,POST的数据,同样它也返回信息给服务器.ecb在请求完成前或超时时间到之前都保持可访问(stay alive),这样ASP.NET就可以继续和它通讯直到请求处理完成.输出被写入ISAPI输出流(使用ecb.WriteClient())然后请求就完成了,ISAPI扩展得到请求处理完成的通知并释放ECB.这个实现是非常高效的,因为.NET类本质上只是对高效的、非托管的ISAPI ECB的一个非常”瘦”(thin)的包装器.

装载.NET-有点神秘

让我们从这儿往回退一步:我跳过了.NET运行时是怎么被载入的.这是事情变得有一点模糊的地方.我没有在这个过程中找到任何的文档,而且因为我们在讨论本机代码,没有很好的办法来反编译ISAPI DLL并找出它(装载.NET运行时的代码)来.

我能作出的最好的猜测是当ISAPI扩展接受到第一个映射到ASP.NET的扩展名的请求时,工作进程装载了.NET运行时.一旦运行时存在,非托管代码就可以为指定的虚拟目录请求一个ISAPIRuntime的实例(如果这个实例还不存在的话).每个虚拟目录拥有它自己的应用程序域(AppDomain),当一个独立的应用(指一个ASP.NET程序)开始的时候ISAPIRuntime从启动过程就一直在应用程序域中存在.实例化(译注:应该是指ISAPIRuntime的实例化)似乎是通过COM来进行的,因为接口方法都被暴露为COM可调用的方法.

当第一个针对某虚拟目录的请求到来时,System.Web.Hosting.AppDomainFactory.Create()函数被调用来创建一个ISAPIRuntime的实例.这就开始了这个应用的启动进程.这个调用接收这个应用的类型,模块名称和虚拟目录信息,这些信息被ASP.NET用来创建应用程序域并启动此虚拟目录的ASP.NET程序.这个HttpRuntime实例(译注:原文为This HttpRuntime derived object,但HttpRuntime是一个sealed类,疑为原文错误)在一个新的应用程序域中被创建.每个虚拟目录(即一个ASP.NET应用程序寄)宿在一个独立的应用程序域中,而且他们也只有在特定的ASP.NET程序被请求到的时候才会被载入.ISAPI扩展管理这些HttpRuntime对象的实例,并根据请求的虚拟目录将内部的请求路由到正确的那个HttpRuntime对象上.

ISAPI请求使用一些没有文档记载的类,接口并调用许多工厂方法传送到ASP.NET的HTTP管道的过程.每个Web程序/虚拟目录在它自己的应用程序域中运行,调用者(译注:指ISAPI DLL)保持一个IISAPIRuntime接口的引用来触发ASP.NET的请求处理.