IIS与asp.net管道

时间  2019-11-08
标签 iis asp.net asp 管道 栏目 ASP 繁體版
原文   原文链接

　　咱们在基于asp.net开发web程序，基本上都是发布部署到安装了IIS的windows服务器上，而后只要用户可以访问就算任务完成了，可是不多静下心来想一想这背后到底发生了什么，那么这个系列就来总结下asp.net的基础原理。php

asp.net是什么

咱们作web开发的能够说时时刻刻都在跟asp.net打交道，但不多总结asp.net是什么，能够用一句话总结：
asp.net是一个开发web程序的平台。

HTTP协议

因为web程序是基于HTTP协议的，因此在继续深刻了解asp.net以前有必要学习下HTTP协议。
HTTP协议是一个属于应用层，基于TCP/IP协议，用于从万维网服务器传输超文本到本地浏览器的传送协议。HTTP协议工做于客户端/服务端架构上，以下图。
 

 

 

HTTP协议具备如下显著特色：html

1，简单快速，客户端向服务端发起请求时，只需发送请求方法和url。常见请求方法包括：GET，POST等。
2，灵活，是因HTTP协议容许发送任意类型的数据对象，数据类型能够经过Content-Type指定。
3，无链接和无状态。无链接的意思是，每次链接只处理一个请求，服务端处理完请求而且客户端收到请求后即断开链接。无状态的意思是，每次的请求都是独立的。
4，通常都是基于B/S架构的。
 

IIS与asp.net

 asp.net与IIS有着密不可分的联系的。
1，IIS 5.x与asp.net
IIS 5.x是集成在windows server 2000上的。
首先看下面的图，这张图展现了在IIS 5.x下如何处理asp.net程序请求的。

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

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）。windows

若是咱们请求的是一个基于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）进程通讯，以得到最好的性能。api

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

 
2，IIS 6.0与asp.net
IIS 6.0是集成在windows server 2003上的。
从上面能够看到，IIS 5.x仍存在如下两个问题：
  • ISAPI Dll被加载到InetInfo.exe进程中，它和工做进程之间是一种典型的跨进程通讯方式，尽管采用性能最好的命名管道，可是仍然会带来性能的瓶颈。
  • 全部的ASP.NET应用，运行在相同的进程（aspnet_wp.exe）中的不一样的应用程序域（AppDomain）中，基于应用程序域的隔离级别不能从根本上解决一个应用程序对另外一个程序的影响，在更多的时候，咱们须要不一样的Web应用运行在不一样的进程中。

那么IIS 6.0下是如何处理asp.net请求的呢，以下图。缓存

 

在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进程中。

当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 5.x，IIS 6.0的变化主要在如下方面：

  • ISAPI.dll被直接加载到工做进程中，这解决了IIS 5.x的第1个问题。
  • 引入了应用程序池（Application Pool）的机制。
  • 建立了一个新的HTTP监听器，HTTP协议栈（HTTP Protocol Stack，即HTTP.sys）
 
3，IIS 7.0与asp.net
IIS 7.0是集成在windows server 2008上的。
到了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监听器和对应的监听适配器。

下图为上述的4个Windows Service在服务控制管理器（SCM）中的呈现。

 

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

因此，相比IIS 6.0，IIS 7.0的变化主要在如下方面：

  • 引入了Windows进程激活服务（Windows Process Activation Service，WAS），将原来（IIS 6.0）W3SVC承载的部分功能分流给了WAS，带来的好处是，能够同时处理HTTP请求和非HTTP请求。
  • 与IIS 5.x和IIS 6.0基于Metabase的配置信息存储不一样的是，IIS 7.0大都将配置信息存放于XML形式的配置文件中。基本的配置存放在applicationHost.cofig中。 

asp.net管道

先看两张图。

　　　　　　　　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。上面整个处理流程如第1图所示。

 

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在处理每个请求时触发的事件名称。

经典的asp.net管道的19个事件：

名称

描述

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>

 

 

参考资料

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程