[ASP.NET]谈谈IIS与ASP.NET管道

做为一个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的资源:

1. 加载aspnet_isapi.dll
2. 建立工做进程（第一次请求）
3. 加载CLR(第一次请求)
4. 建立AppDomain(某个web应用的第一次请求)
5. 执行ISAPIRuntime.

说明：

1. 对于IIS 5.x来讲，该工做进程为aspnet_wp.exe。
2. aspnet_isapi.dll与工做进程之间经过命名管道（Named Pipes）进程通讯，以得到最好的性能。
3. 对于寄宿于IIS 5.x的全部Web 应用都运行在同一个工做进程的不一样AppDomain中。

 

IIS 6

IIS5的不足

1. aspnet_isapi与工做进程之间是跨进程通讯。
2. 全部的web应用都是在同一个工做进程中。

 

IIS6解决办法

1. 将aspnet_ispai.dll加载到工做进程中。
2. 创建应用程序池，一个应用程序池对应一个工做进程。

 

另外在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是在工做进程的初始化过程当中被加载。

  

 

说明：

1. W3SVC服务已经从iis进程中脱离出来。http.sys接受到请求，将直接分发给w3svc服务
2. 在IIS6中工做进程名为w3wp.exe
3. 工做进程的这种建立方式被称为请求式建立

 

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内核代码中来解析，方便你们精确控制任意请求，带来更好的扩展性。

(这里面每一个静态文件也会通过生命周期事件,执行效率确定会有所降低.)

 

配置文件上的区别

  <!--传统模式-->
  <system.web>
    <customErrors mode="RemoteOnly">
      <error statusCode="404" redirect="404.html"/>
      <error statusCode="500" redirect="500.html"/>
    </customErrors>
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" />
  </system.web>
  <!--集成模式-->
  <system.webServer>
    <httpErrors errorMode="DetailedLocalOnly">
      <clear/>
      <error path="404.html" statusCode="404"/>
      <error path="500.html" statusCode="500"/>
    </httpErrors>
  </system.webServer>

 

Asp.Net管道

 

1. 加载CLR:在工做进程中,ISAPI负责进行CLR的加载（若是.NET运行时还没有加载）.
2. 建立AppDomain:当成功加载了运行时后，会经过AppDomainFactory为该Web应用建立一个应用程序域（AppDomain）。
3. 执行ISAPIRuntime的int ProcessRequest(IntPtr ecb, int iWRType)方法
4. 执行HttpRuntime的PR方法　　
5. 获取httpapplication实例,调用httpapplication的pr方法
6. 触发httpapplication各事件.

 

扩展

1. 在HttpApplication初始化过程当中，会根据配置文件加载并初始化相应的HttpModule对象。对于HttpApplication来讲，在它处理HTTP请求的不一样的阶段会触发不一样的事件（Event），而HttpModule的意义在于经过注册HttpApplication的相应的事件，将所需的操做注入整个HTTP请求的处理流程。ASP.NET的不少功能，好比身份验证、受权、缓存等，都是经过相应的HttpModule实现的。
2. 而最终完成对HTTP请求的处理实如今另外一个重要的对象中：HttpHandler。对于不一样的资源类型，具备不一样的HttpHandler。好比.aspx页对应的HttpHandler为System.Web.UI.Page，WCF的.svc文件对应的HttpHandler为System.ServiceModel.Activation.HttpHandler。
3. 对于一个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接口.

namespace System.Web
{
  public interface IHttpModule
  {
    void Init(HttpApplication context);

    void Dispose();
  }
}

 

系统定义的HttpModule

• OutputCacheModule：实现了输出缓存（Output Caching）的功能；
• SessionStateModule：在无状态的HTTP协议上实现了基于会话（Session）的状态；
• WindowsAuthenticationModule + FormsAuthenticationModule：实现了3种典型的身份认证方式：Windows认证、Forms认证；
• WCFModule:使Asp.Net扩展出WCF服务(System.ServiceModel.Activation.HttpModule)

 

自定义HttpMoudle

1. 实现IHttpMoudle
2. 修改配置文件Web.config

 

 

 

HttpHandle

对于不一样资源类型的请求，ASP.NET会加载不一样的Handler来处理，也就是说.aspx page与.asmx web service对应的Handler是不一样的。

全部的HttpHandler都实现了接口IHttpHandler。

  public interface IHttpHandler
  {
    bool IsReusable { get; }

    void ProcessRequest(HttpContext context);
  }

 

系统定义的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