IIS 7.0与ASP.NET

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

HTTP请求接收:接收HTTP.SYS监听到的HTTP请求。

配置管理:从元数据库(Metabase)中加载配置信息对相关组件进行配置。

进程管理:创建、回收、监控工作进程。

IIS 7.0将后两组功能实现到了WAS中,接收HTTP请求的任务依然落在W3SVC头上。WAS的引入为IIS 7.0提供了对非HTTP协议的支持。WAS通过监听器适配器接口(Listener Adapter Interface)抽象出不同协议监听器。具体来说,除了基于网络驱动的HTTP.SYS提供HTTP请求监听功能外还提供了TCP监听器、命名管道监听器和MSMQ监听器以提供基于TCP、命名管道和MSMQ传输协议的监听支持。

与此3种监听器相对的是3种监听适配器,它们提供监听器与WAS中的监听器适配器接口之间的适配。从这个意义上讲,IIS 7.0中的W3SVC更多地为HTTP.SYS起着监听适配器的作用。这3种非HTTP监听器和监听适配器定义在程序集SMHost.exe中,我们可以在目录%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\中找到它们。

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

NetTcpPortSharing:为WCF提供TCP端口共享。关于端口共享在WCF中的应用,本人拙著《WCF全面解析》(上册)对此有详细的介绍。

NetTcpActivator:为WAS提供基于TCP的激活请求,包含TCP监听器和对应的监听适配器。

NetPipeActivator:为WAS提供基于命名管道的激活请求,包含命名管道监听器和对应的监听适配器。

NetMsmqActivator:为WAS提供基于MSMQ的激活请求,包含MSMQ监听器和对应的监听适配器。

图1-7为上述的4个Windows 服务在服务控制管理器中的呈现。

IIS 7.0与ASP.NET 

图1-7  定义在SMHost.exe中的Windows Service

图1-8揭示了IIS 7.0的整体构架及整个请求处理流程。无论是从W3SVC接收到的HTTP请求,还是通过WCF提供的监听适配器接收到的请求,最终都会传递到WAS。如果相应的工作进程(或者应用程序池)尚未创建,则创建它,否则将请求分发给对应的工作进程进行后续的处理。WAS在进行请求处理过程中,通过内置的配置管理模块加载相关的配置信息,并对相关的组件进行配置。与IIS 5.x和IIS 6.0基于Metabase的配置信息存储不同的是,IIS 7.0大都将配置信息存放于XML形式的配置文件中,基本的配置存放在applicationHost.config中。

 IIS 7.0与ASP.NET

图1-8  IIS 7.0与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响应。图1-9反映了IIS 6.0与ASP.NET之间的桥接关系。

 IIS 7.0与ASP.NET

图1-9  基于IIS 6.0与ASP.NET双管道设计

从另一个角度讲,IIS运行在非托管的环境中,而ASP.NET管道则是托管的,ISAPI还是连接非托管环境和托管环境的纽带。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中实现了两者的集成,通过集成可以获得如下的好处。

允许通过本地代码(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)等。

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

 IIS 7.0与ASP.NET

图1-10  基于IIS 7.0与ASP.NET集成管道设计

 

 

 

 

 

 

本文节选自《ASP.NET MVC 4 框架揭秘》

IIS 7.0与ASP.NET

蒋金楠

电子工业出版社出版

分类:

技术点:

相关文章: