谈谈IIS与ASP.NET管道
2016-03-01 21:26
806 查看
作为一个Asp.Net平台开发者,非常有必要了解IIS和Asp.Net是如何结合,执行我们的托管代码,以及Asp.Net管道事件的.
本节目录
IIS 5.X
IIS 6
IIS 7+
集成模式
Asp.Net管道
HttpModule
HttpHandle
IIS 5.x
InetInfo.exe与W3SVC服务
IIS 5.x运行在进程InetInfo.exe中,在该进程中一个最重要的服务就是名为World Wide Web Publishing Service(简称W3SVC)的Windows Service。
W3SVC的主要功能包括HTTP请求的监听、工作进程的管理以及配置管理(通过从Metabase中加载相关配置信息)等。
请求资源(根据扩展名区分静态和动态资源)
静态文件,直接返回文件内容。
动态资源,通过扩展名从IIS的脚本影射(Script Map)找到相应的ISAPI Dll。
ISAPI
ISAPI是Internet服务器API(Internet Server Application Programming Interface)的缩写.是IIS和其他应用的纽带.
ISAPI包括ISAPI Extension和ISAPI Filter
ISAPI Extension
不用种类的动态资源,会有不同的ISAPI扩展.
如Asp.Net(.aspx .asmx .svc等)则为aspnet_isapi.dll。在目录“%windir%\Microsoft.NET\Framework\{version no}\”中找到该dll。
ISAPI Filter
Filter则可以在HTTP请求真正被处理之前查看、修改、转发或者拒绝请求,比如IIS可以利用ISAPI筛选进行请求的验证(Authentication)。
请求Asp.Net
如果我们请求的是一个基于ASP.NET的资源:
加载aspnet_isapi.dll
创建工作进程(第一次请求)
加载CLR(第一次请求)
创建AppDomain(某个web应用的第一次请求)
执行ISAPIRuntime.
说明:
对于IIS 5.x来说,该工作进程为aspnet_wp.exe。
aspnet_isapi.dll与工作进程之间通过命名管道(Named Pipes)进程通信,以获得最好的性能。
对于寄宿于IIS 5.x的所有Web 应用都运行在同一个工作进程的不同AppDomain中。
IIS 6
IIS5的不足
aspnet_isapi与工作进程之间是跨进程通信。
所有的web应用都是在同一个工作进程中。
IIS6解决办法
将aspnet_ispai.dll加载到工作进程中。
建立应用程序池,一个应用程序池对应一个工作进程。
另外在IIS6中,创建新的http监听器:HTTP协议栈(HTTP Protocol Stack,HTTP.SYS)
持续监听:由于HTTP.SYS是一个网络驱动程序,始终处于运行状态,对于用户的HTTP请求,能够及时作出反应;
更好的稳定性:HTTP.SYS运行在操作系统内核模式下,并不执行任何用户代码,所以其本身不会受到Web应用、工作进程和IIS进程的影响;
内核模式下数据缓存:如果某个资源被频繁请求,HTTP.SYS会把响应的内容进行缓存,缓存的内容可以直接响应后续的请求。由于这是基于内核模式的缓存,不存在内核模式和用户模式的切换,响应速度将得到极大的改进。
请求Asp.Net
与IIS5.X不同的是:
1.W3SVC服务根据请求创建工作进程
2.aspnet_isapi.dll是在工作进程的初始化过程中被加载。
说明:
W3SVC服务已经从iis进程中脱离出来。http.sys接受到请求,将直接分发给w3svc服务
在IIS6中工作进程名为w3wp.exe
工作进程的这种创建方式被称为请求式创建
IIS 7+
W3SVC服务
在IIS6中的W3SVC服务的功能
HTTP请求接收:接收HTTP.SYS监听到的HTTP请求;
配置管理:从元数据库(Metabase)中加载配置信息对相关组件进行配置;
进程管理:创建、回收、监控工作进程。
在IIS7中W3SVC只负责第一个功能,剩余功能交给WAS服务管理
WAS服务
IIS7引入Windows进程激活服务(Windows Process Activation Service,WAS):同时处理HTTP和非HTTP请求。
在WAS中,定义了一个重要的接口:监听器适配器接口(Listener Adapter Interface)抽象出不同协议监听器监听到的请求。
WAS将监听W3SVC服务的http请求以及WCF服务的TCP、Named Pipes、MSMQ3种请求.
说明
WCF提供的这3种监听器和监听适配器定义在程序集SMHost.exe中,你可以通过下面的目录找到该程序集:%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation。
SMHost.exe提供了4个重要的Windows Service:
NetTcpPortSharing:为WCF提供TCP端口共享,关于端口共享;
NetTcpActivator:为WAS提供基于TCP的激活请求,包含TCP监听器和对应的监听适配器;
NetPipeActivator:为WAS提供基于命名管道的激活请求,包含命名管道监听器和对应的监听适配器;
NetMsmqActivator:为WAS提供基于MSMQ的激活请求,包含MSMQ监听器和对应的监听适配器。
集成模式
传统模式的缺点
相同操作的重复执行: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。
集成模式
实际上IIS7集成模式,就是让用户可以通过编写托管代码的module,把托管代码插入到IIS内核代码中来解析,方便大家精确控制任意请求,带来更好的扩展性。
(这里面每个静态文件也会经过生命周期事件,执行效率肯定会有所下降.)
配置文件上的区别
Asp.Net管道
加载CLR:在工作进程中,ISAPI负责进行CLR的加载(如果.NET运行时尚未加载).
创建AppDomain:当成功加载了运行时后,会通过AppDomainFactory为该Web应用创建一个应用程序域(AppDomain)。
执行ISAPIRuntime的int ProcessRequest(IntPtr ecb, int iWRType)方法
执行HttpRuntime的PR方法
获取httpapplication实例,调用httpapplication的pr方法
触发httpapplication各事件.
扩展
在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。
对于一个ASP.NET应用来说,HttpApplication派生于global.asax文件,我们可以通过创建global.asax文件对HttpApplication的请求处理行为进行定制。global.asax采用一种很直接的方式实现了这样的功能,这种方式既不是我们常用的方法重写(Method Overriding)或者事件注册,而是直接采用方法名匹配。在global.asax中,我们按照这样的方法命名规则进行事件注册:Application_{Event Name}。比如Application_BeginRequest方法用于处理HttpApplication的BeginRequest事件。
HttpModule
从功能上讲,HttpModule之于ASP.NET,就好比ISAPI Filter之于IIS一样。IIS将接收到的请求分发给相应的ISAPI Extension之前,注册的ISAPI Filter会先截获该请求。
如果说HttpModule相当于IIS的ISAPI Filter的话,我们可以说HttpHandler则相当于IIS的ISAPI Extension,HttpHandler在ASP.NET中扮演请求的最终处理者的角色。
当请求转入ASP.NET管道后,最终负责处理该请求的是与请求资源类型相匹配的HttpHandler对象,但是在Handler正式工作之前,ASP.NET会先加载并初始化所有配置的HttpModule对象。HttpModule在初始化的过程中,会将一些功能注册到HttpApplication相应的事件中,那么在HttpApplication整个请求处理生命周期中的某个阶段,相应的事件会被触发,通过HttpModule注册的事件处理程序也得以执行。
所有的HttpModule都实现了IHttpModule接口.
系统定义的HttpModule
OutputCacheModule:实现了输出缓存(Output Caching)的功能;
SessionStateModule:在无状态的HTTP协议上实现了基于会话(Session)的状态;
WindowsAuthenticationModule + FormsAuthenticationModule:实现了3种典型的身份认证方式:Windows认证、Forms认证;
WCFModule:使Asp.Net扩展出WCF服务(System.ServiceModel.Activation.HttpModule)
自定义HttpMoudle
实现IHttpMoudle
修改配置文件Web.config
HttpHandle
对于不同资源类型的请求,ASP.NET会加载不同的Handler来处理,也就是说.aspx page与.asmx web service对应的Handler是不同的。
所有的HttpHandler都实现了接口IHttpHandler。
系统定义的HttpHandle
WebForm的aspx文件:System.Web.UI.Page
WCF的svc文件:System.ServiceModel.Activation.HttpHandler
MVC:MVCHandler
自定义HttpHandle
由于Handle是在PostMapRequestHandler前和 PostResolveRequestCache 后映射指定的Handle,
所以我们可以在PostResolveRequestCache事件中注册我们的Handle.
在PreRequestHandlerExecute 后将会调用我们的Handle.PR方法.
扩展
HttpApplication主要有19个事件,通过我的网站任意地址+参数即可访问所有事件。
+?pipe可以查看这些事件触发时间.如:http://neverc.cn?pipe
+?pe可以附带我的网站内容:http://neverc.cn?pe
猜猜如何实现出以上效果
本文地址:http://neverc.cnblogs.com/p/4807836.html
本文参考: http://www.cnblogs.com/artech/archive/2009/06/20/1507165.html
本节目录
IIS 5.X
IIS 6
IIS 7+
集成模式
Asp.Net管道
HttpModule
HttpHandle
IIS 5.x
InetInfo.exe与W3SVC服务
IIS 5.x运行在进程InetInfo.exe中,在该进程中一个最重要的服务就是名为World Wide Web Publishing Service(简称W3SVC)的Windows Service。
W3SVC的主要功能包括HTTP请求的监听、工作进程的管理以及配置管理(通过从Metabase中加载相关配置信息)等。
请求资源(根据扩展名区分静态和动态资源)
静态文件,直接返回文件内容。
动态资源,通过扩展名从IIS的脚本影射(Script Map)找到相应的ISAPI Dll。
ISAPI
ISAPI是Internet服务器API(Internet Server Application Programming Interface)的缩写.是IIS和其他应用的纽带.
ISAPI包括ISAPI Extension和ISAPI Filter
ISAPI Extension
不用种类的动态资源,会有不同的ISAPI扩展.
如Asp.Net(.aspx .asmx .svc等)则为aspnet_isapi.dll。在目录“%windir%\Microsoft.NET\Framework\{version no}\”中找到该dll。
ISAPI Filter
Filter则可以在HTTP请求真正被处理之前查看、修改、转发或者拒绝请求,比如IIS可以利用ISAPI筛选进行请求的验证(Authentication)。
请求Asp.Net
如果我们请求的是一个基于ASP.NET的资源:
加载aspnet_isapi.dll
创建工作进程(第一次请求)
加载CLR(第一次请求)
创建AppDomain(某个web应用的第一次请求)
执行ISAPIRuntime.
说明:
对于IIS 5.x来说,该工作进程为aspnet_wp.exe。
aspnet_isapi.dll与工作进程之间通过命名管道(Named Pipes)进程通信,以获得最好的性能。
对于寄宿于IIS 5.x的所有Web 应用都运行在同一个工作进程的不同AppDomain中。
IIS 6
IIS5的不足
aspnet_isapi与工作进程之间是跨进程通信。
所有的web应用都是在同一个工作进程中。
IIS6解决办法
将aspnet_ispai.dll加载到工作进程中。
建立应用程序池,一个应用程序池对应一个工作进程。
另外在IIS6中,创建新的http监听器:HTTP协议栈(HTTP Protocol Stack,HTTP.SYS)
持续监听:由于HTTP.SYS是一个网络驱动程序,始终处于运行状态,对于用户的HTTP请求,能够及时作出反应;
更好的稳定性:HTTP.SYS运行在操作系统内核模式下,并不执行任何用户代码,所以其本身不会受到Web应用、工作进程和IIS进程的影响;
内核模式下数据缓存:如果某个资源被频繁请求,HTTP.SYS会把响应的内容进行缓存,缓存的内容可以直接响应后续的请求。由于这是基于内核模式的缓存,不存在内核模式和用户模式的切换,响应速度将得到极大的改进。
请求Asp.Net
与IIS5.X不同的是:
1.W3SVC服务根据请求创建工作进程
2.aspnet_isapi.dll是在工作进程的初始化过程中被加载。
说明:
W3SVC服务已经从iis进程中脱离出来。http.sys接受到请求,将直接分发给w3svc服务
在IIS6中工作进程名为w3wp.exe
工作进程的这种创建方式被称为请求式创建
IIS 7+
W3SVC服务
在IIS6中的W3SVC服务的功能
HTTP请求接收:接收HTTP.SYS监听到的HTTP请求;
配置管理:从元数据库(Metabase)中加载配置信息对相关组件进行配置;
进程管理:创建、回收、监控工作进程。
在IIS7中W3SVC只负责第一个功能,剩余功能交给WAS服务管理
WAS服务
IIS7引入Windows进程激活服务(Windows Process Activation Service,WAS):同时处理HTTP和非HTTP请求。
在WAS中,定义了一个重要的接口:监听器适配器接口(Listener Adapter Interface)抽象出不同协议监听器监听到的请求。
WAS将监听W3SVC服务的http请求以及WCF服务的TCP、Named Pipes、MSMQ3种请求.
说明
WCF提供的这3种监听器和监听适配器定义在程序集SMHost.exe中,你可以通过下面的目录找到该程序集:%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation。
SMHost.exe提供了4个重要的Windows Service:
NetTcpPortSharing:为WCF提供TCP端口共享,关于端口共享;
NetTcpActivator:为WAS提供基于TCP的激活请求,包含TCP监听器和对应的监听适配器;
NetPipeActivator:为WAS提供基于命名管道的激活请求,包含命名管道监听器和对应的监听适配器;
NetMsmqActivator:为WAS提供基于MSMQ的激活请求,包含MSMQ监听器和对应的监听适配器。
集成模式
传统模式的缺点
相同操作的重复执行: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。
集成模式
实际上IIS7集成模式,就是让用户可以通过编写托管代码的module,把托管代码插入到IIS内核代码中来解析,方便大家精确控制任意请求,带来更好的扩展性。
(这里面每个静态文件也会经过生命周期事件,执行效率肯定会有所下降.)
配置文件上的区别
加载CLR:在工作进程中,ISAPI负责进行CLR的加载(如果.NET运行时尚未加载).
创建AppDomain:当成功加载了运行时后,会通过AppDomainFactory为该Web应用创建一个应用程序域(AppDomain)。
执行ISAPIRuntime的int ProcessRequest(IntPtr ecb, int iWRType)方法
执行HttpRuntime的PR方法
获取httpapplication实例,调用httpapplication的pr方法
触发httpapplication各事件.
扩展
在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。
对于一个ASP.NET应用来说,HttpApplication派生于global.asax文件,我们可以通过创建global.asax文件对HttpApplication的请求处理行为进行定制。global.asax采用一种很直接的方式实现了这样的功能,这种方式既不是我们常用的方法重写(Method Overriding)或者事件注册,而是直接采用方法名匹配。在global.asax中,我们按照这样的方法命名规则进行事件注册:Application_{Event Name}。比如Application_BeginRequest方法用于处理HttpApplication的BeginRequest事件。
HttpModule
从功能上讲,HttpModule之于ASP.NET,就好比ISAPI Filter之于IIS一样。IIS将接收到的请求分发给相应的ISAPI Extension之前,注册的ISAPI Filter会先截获该请求。
如果说HttpModule相当于IIS的ISAPI Filter的话,我们可以说HttpHandler则相当于IIS的ISAPI Extension,HttpHandler在ASP.NET中扮演请求的最终处理者的角色。
当请求转入ASP.NET管道后,最终负责处理该请求的是与请求资源类型相匹配的HttpHandler对象,但是在Handler正式工作之前,ASP.NET会先加载并初始化所有配置的HttpModule对象。HttpModule在初始化的过程中,会将一些功能注册到HttpApplication相应的事件中,那么在HttpApplication整个请求处理生命周期中的某个阶段,相应的事件会被触发,通过HttpModule注册的事件处理程序也得以执行。
所有的HttpModule都实现了IHttpModule接口.
OutputCacheModule:实现了输出缓存(Output Caching)的功能;
SessionStateModule:在无状态的HTTP协议上实现了基于会话(Session)的状态;
WindowsAuthenticationModule + FormsAuthenticationModule:实现了3种典型的身份认证方式:Windows认证、Forms认证;
WCFModule:使Asp.Net扩展出WCF服务(System.ServiceModel.Activation.HttpModule)
自定义HttpMoudle
实现IHttpMoudle
修改配置文件Web.config
HttpHandle
对于不同资源类型的请求,ASP.NET会加载不同的Handler来处理,也就是说.aspx page与.asmx web service对应的Handler是不同的。
所有的HttpHandler都实现了接口IHttpHandler。
WebForm的aspx文件:System.Web.UI.Page
WCF的svc文件:System.ServiceModel.Activation.HttpHandler
MVC:MVCHandler
自定义HttpHandle
由于Handle是在PostMapRequestHandler前和 PostResolveRequestCache 后映射指定的Handle,
所以我们可以在PostResolveRequestCache事件中注册我们的Handle.
在PreRequestHandlerExecute 后将会调用我们的Handle.PR方法.
扩展
HttpApplication主要有19个事件,通过我的网站任意地址+参数即可访问所有事件。
+?pipe可以查看这些事件触发时间.如:http://neverc.cn?pipe
+?pe可以附带我的网站内容:http://neverc.cn?pe
猜猜如何实现出以上效果
本文地址:http://neverc.cnblogs.com/p/4807836.html
本文参考: http://www.cnblogs.com/artech/archive/2009/06/20/1507165.html
相关文章推荐
- asp.net页面之间的跳转
- Asp.net MVC中Html.Partial, RenderPartial, Action,RenderAction 区别和用法【转发】
- asp.net连接数据库报错
- ASP.NET MVC学前篇之Ninject的初步了解
- raspberry-pi之DSI
- 在ASP.NET Core 1.0中如何发送邮件
- Raspberry pi raspbain source mirror
- ASP.NET MVC 中实现View与Controller分离
- 实战:把ASP.NET MVC中的Views下面的视图放到Views文件夹外
- 轻量级asp.net ajax解决方案详解
- classic asp中使用ADODB.Command防止sql injection
- 几种判断asp.net中session过期方法的比较
- ASP.NET MVC URL重写与优化(1)-使用Global路由表定制URL
- 新手留言薄asp.net MVC 学习(适合新手学习)
- ASP.NET(C#)——唯一订单号
- Raspberry Pi 学习笔记之一
- asp.net单点登录(SSO)解决方案
- ASP.NET(C#)——日期函数
- asp.net 前台绑定后台变量方法总结
- ASP.NET开发知识总结