ASP.NET/MVC/Core的HTTP请求流程

时间  2019-11-08
标签 asp.net asp mvc core http 请求 流程 栏目 ASP 繁體版
原文   原文链接

ASP.NET HTTP管道（Pipeline）模型

1. 先讲一点，再深入思考

通常咱们都在写业务代码，优化页面，优化逻辑之间内徘徊。也许咱们懂得HTTP，HTTPS的GET，POST，可是咱们大部分人是不知道ASP是如何去解析HTTP，或者IIS是如何去处理页面请求。咱们只知道WebForm拉控件，MVC写Controller，Action，殊不知道IIS，NetFrameWork帮咱们作了不少事情。那接下咱们就是要去了解IIS帮咱们作了些啥事情。php

2. 那啥叫管道（Pipeline）模型

  • 初理解Pipelinehtml

    • 从一个现象提及，有一家咖啡吧生意特别好，天天来的客人络绎不绝，客人A来到柜台，客人B紧随其后，客人C排在客人B后面，客人D排在客人C后面，客人E排在客人D后面，一直排到店面门外。老板和三个员工首先为客人A准备食物：员工甲拿了一个干净的盘子，而后员工乙在盘子里装上薯条，员工丙再在盘子里放上豌豆，老板最后配上一杯饮料，完成对客人A的服务，送走客人A，下一位客人B开始被服务。而后员工甲又拿了一个干净的盘子，员工乙又装薯条，员工丙又放豌豆，老板又配上了一杯饮料，送走客人B，客人C开始被服务。一直重复下去。git

    • 从效率方面观察这个现象，当服务客人A时，在员工甲拿了一个盘子后，员工甲一直处于空闲状态，直到送走客人A，客人B被服务。老板天然而然的就会想到若是每一个人都不停的干活，就能够服务更多的客人，赚到更多的钱。老板经过不停的尝试想出了一个办法。以客户A，B为例阐述这个方法：员工甲为客户A准备好了盘子后，在员工乙开始为客户A装薯条的同时，员工甲开始为客户B准备托盘。这样员工甲就能够不停的进行生产。整个过程以下图，客户们围着咖啡吧台排队，由于有四个生产者，一个老板加三个员工，因此能够同时服务四个客户。咱们将目光转向老板，单位时间从他那里出去的客户数提升了将近四倍，也就是说效率提升将近四倍。github

    这样子，咱们就很好理解了Pipeline了，那其实就是每一个人络绎不绝的作本身的事情，但我的事情又是整个流程的一部分，有点像工厂的小妹，只作包鞋底，可是这又是制造鞋的中间流程。一条流水，一条管道，一直处理下去。那每一个HTTP请求，到了IIS也是这样子的。web

  • 针对Pipeline模型带来的启示,好处
    • 工做流的参考模型
      其实就是上面所说同样，pipeline模型与工做流模型，都是链式的，就像一条生产线，各个组件的先后协同。
    • 服务framework的参考构建模型
      Pipeline模型的一个特色是，在其内部是以组建的模式来实现组合的（虽然这些组建有前后顺序之分），它假如你把侧重点放在它的链式组合上，而不是将侧重点放在上面的工做流上（工做流的关注点是流程的前后顺序），那么彻底能够用这种方式来搭建一个复杂的服务，固然这样作的前提是，单个组件的粒度必须尽量小而且耦合性极低。
      那其实就很像如今的微服务了，只不过微服务更大，服务对象是一个应用程序。
    Pipeline模型带来的：流程式(有序)+可拆卸(配置)，比普通的封装机动性更好。

  • Pipeline模型的缺点
    每次它对于一个输入（或者一次请求）都必须从链头开始遍历（參考Http Server处理请求就能明确），这确实存在必定的性能损耗。json

3. 讲完Pipeline，咱们讲他在IIS上的实现

3.1 Http请求带服务器的时候

  1. 当服务器接收到一个Http请求的时候，IIS是如何去决定，并处理该请求。答案就是文件的“后缀名”。api

    服务器获取所请求的页面或文件的后缀名后，那服务器就回去寻找能出来这些后缀的应用程序。如果IIS找不到，而且文件没有受到IIS的保护（保护：App_Code文件夹的文件，不保护：日常的JS文件等），就会直接返回给客户端（浏览器，移动端等）浏览器

    那么能处理后缀名的程序叫什么呢？ ISAPI 应用程序（Internet Server Application Programe Interface，互联网服务器应用程序接口）。它实际上是一个接口，起到一个代理的做用，他的主要工做就是将请求的页面（文件）与处理该页面（文件）的后缀的处理程序进行一个映射。让其能够争取的去处理页面（文件）。服务器

    那这个应用程序长什么样子呢？
    • 咱们打开IIS（server2003），随意选中一个站点，鼠标右击属性，而后选择“主目录”选项，接着选择“配置”。而后就能够看到下面的画面。

    这边咱们能看到后缀名与之可执行的文件路径。
    接着咱们找到“.axpx”的后缀名，打开来看。mvc

    咱们能够发现".aspx"的后缀名是有aspnet_isapi.dll来处理的，因此IIS将".aspx"页面的请求交给这个dll，就不关心后面是如何处理了。因此咱们如今知道了，ASP.NET只是服务器（IIS）的一个组成部分而已，它是一个ISAPI扩展。

  2. 上面是server2003的状况，如今08以上变成了不是在属性里面了， 他变成了IIS中的“ISAPI筛选器”和“处理程序映射”了。

    1. 咱们点击“ISAPI筛选器”，能够出现发现，筛选器是分FrameWork与位数的，因此有四个。

    1. 咱们进入处理程序映射，找出后缀为“.aspx”的，能够发现有不少个，对应了framework与位数，而且有个处理程序，

    3.双击进入，能够看到能够处处理模块的具体路径，以及请求限制。

注意，这边要是限制后，页面（文件）只能以某种特定方式访问。

3.2 宿主环境（Hosting）

从本质上讲，Asp.Net 主要是由一系列的类组成，这些类的主要目的就是将 Http 请求转变为对客户端的响应。HttpRuntime 类是 Asp.Net 的一个主要入口，它有一个称做 ProcessRequest的方法，这个方法以一个 HttpWorkerRequest 类做为参数。HttpRuntime 类几乎包含着关于单个 Http 请求的全部信息：所请求的文件、服务器端变量、QueryString、Http 头信息 等等。Asp.Net 使用这些信息来加载、运行正确的文件，而且将这个请求转换到输出流中，通常来讲，也就是 HTML 页面。固然也但是是文件。

当页面（文件）发生变更时，为了可以卸载运行在同一进程中的应用程序，固然卸载也是为了从新新加载，Http请求被分放在相互隔离的应用程序域。也就是“AppDomain”。

那么对于IIS来讲，IIS依赖一个叫HTTP.SYS的内置驱动程序来监听外部的HTTP请求，在操做系统启动的时候，IIS会在HTTP.SYS中注册本身的虚拟路径。（注册能够理解为，告诉HTTP.SYS哪些URL能够访问，哪些不能够访问，404就能够怎么来的，就是这么来的。）

若是是能够访问的URL，那么HTTP.SYS会将这个请求扔给IIS工做者进程。（就是咱们所熟悉的W3WP.EXE,IIS5.0叫作ASPNET_WP.EXE）。
运行是每一个进程都有一个身份标识，以及一系列的可选性能参数，其实就是应用程序池，惟一标识就是应用程序池名称。

基础的知识点都懂了，咱们来看下一个大概的HTTP请求的过程

  1. HTTP.SYS接收Http请求信息。并将信息保存到HttpWorkRequest类中。
  2. 从相互隔离的AppDomain中加载HttPRuntime。
  3. 调用HttpRuntime的ProcessRequest方法。
  4. 程序猿创造世界
  5. IIS接收返回的数据流，从新返回给HTTP.SSY
  6. HTTP.SYS将数据返回给客户端（浏览器）

3.3 接下来是重点，理解Pipeline

前面讲了那么多，终于进入到重点，划重点。
首先咱们先知道了什么是Pipeline，接着咱们知道一个Http的请求过程。而后咱们就知道了，原来Http请求到服务器，原来是走这样一条路。

可是咱们忽略了，这个过程跟咱们程序，跟咱们代码怎么衔接起来的。
当Http请求进入 Asp.Net Runtime之后，它的管道由托管模块（Managed Modules）和处理程序（Handlers）组成，而且由管道来处理这个 Http请求。这个就是所谓的ASP的Http管道模型了。

接下来咱们看下这个管道模型是怎么流动的。（WebForm）

  1. 首先进来确定是HTTPRuntime，而后经过HttpApplicationFactory建立HttpApplication。
  2. HttpApplication会建立该次Http请求的HttpContext（上下文），那这个对象咱们就很熟悉了，里面就包括HttpRequest、HttpResponse、HttpSessionState等。
  3. 那接下来请求会经过一系列的Module（能够理解为车间，能够作经过的物品作事情），Module能够作一些执行某个实际工做前的事情。由于它会Http请求有彻底的控制权。

  4. 当Http请求完，它会被HttpHandler处理。在这一步，也就是咱们实际作的事情了，他能够完成咱们.aspx的全部业务。WebForm的每一个页面都是继承“Page”，而“Page”继承了“IHttpHandler”接口

    public class Page : TemplateControl, IHttpHandler{
    // 代码省略
    }
  5. HttpHandler处理完后，又会回到Module，这时能够作一些实际工做后的事情。
    咱们不少事件，是否是有分前与后，就是这个道理。进行事件的先后拦截。

  6. 咱们能够看下,在只有Module与Handler的状况，整个Http的流动走向，大概是这样子

3.4 那讲完WebForm的，咱们来说MVC的

在IIS7以前，如IIS6或IIS5，请求处理管道分为两个：IIS请求处理管道和ASP.NET管道，若客户端请求静态资源则只有IIS管道进行处理，而ASP.NET管道不会处理该请求。从IIS7开始两个管道合二为一，称为集成管道。其实就是咱们IIS里会选择到应用程序池的托管模式。

再次了解

  • IIS 6以及IIS 7经典模式
    早期的IIS版本中，IIS接收到一个请求时先判断请求类型，若是是静态文件直接由IIS处理；若是是一个ASP.NET请求类型，IIS把请求发送给IIS的扩展接口ASP.NET ISAPI DLL。ISAPI至关于ASP.NET应用的容器，这也是咱们以前讲的。

  • IIS 7 集成模式
    IIS 7和以前的版本区别比较大，IIS7直接把ASP.NET的运行管道流程集成到了IIS上。

    • 在IIS7中，ASP.NET请求处理管道Pipeline直接覆盖了IIS自己的管道Pipeline，IIS整个流程按照ASP.ENT管道流程执行，例如BeginRequest、AuthenticateRequest、…、EndRequest。而不是经过插件扩展（ISAPI）形式，不一样的内容（jpg、html、php等）经过不一样的插件来执行。
    • IIS7的优点体如今哪里？开发人员能够实现自定义的HttpModule或者HttpHandler，而后直接集成到IIS上，例如，我能够自定义一个JpgHttpHandler，而后经过IIS的Handler部署方式，把JpgHttpHandler部署到IIS上，处理全部的请求格式为*.jpg的请求。

知道这些咱们继续了解MVC的管道模式

废话很少说，直接上图

废话也很少说，直接走下流程（以个人方式理解）

废话有点多

  1. 首先进入HttpRuntime，在同样经过HttpApplicationFactory建立HttpApplication
  2. HttpApplication会建立该次Http请求的HttpContext（上下文），那这个对象咱们就很熟悉了，里面就包括HttpRequest、HttpResponse、HttpSessionState等。(这些都跟webform是同样的)
  3. HttpApplication继承IHttpHandler，接着咱们开始走Module
  4. 而后咱们进入到使用UrlRoutingModule（路由系统）UrlRoutingModule，从Http请求获取Controller和Action以及路由数据。
  5. 接着匹配Route规则，获取Route对象，解析对象。
  6. 请求IRouteHandler(MVCRouteHandler)
  7. 执行ProcessRequest方法，而后使用ControllerBulider获取ControllerFactory
  8. 接着就调用到Controller，一样的的方法到达Action，并执行
  9. 在执行Controller与Action可能会有各类认证，各类特性拦截
  10. 程序猿创造世界
  11. 返回ActionResult
  12. 响应Http
  13. 客户端接收响应

接下来咱们具体了解下细节

  • HttpApplication与HttpModule

    HTTP请求由ASP.NET运行时接管以后，HttpRuntime会利用HttpApplicationFactory建立或从HttpApplication对象池（.NET中相似的机制有线程池和字符串拘留池）中取出一个HttpApplication对象，同时ASP.NET会根据配置文件来初始化注册的HttpModule，HttpModule在初始化时会订阅HttpApplication中的事件来实现对HTTP请求的处理。

    public class HttpApplication : IComponent, IDisposable, IHttpAsyncHandler, IHttpHandler, IRequestCompletedNotifier, ISyncContext{   

   public HttpApplication();
   public ISite Site { get; set; }
   public IPrincipal User { get; }
   ...
  }

    很明显咱们能够看到HttpApplication继承了IHttpHandler，是跟WebForm的Page是同样的

  • Route

    一个HTTP请求会通过至少一个HttpModule的处理。UrlRoutingModule是很是重要的模块，它是路由系统的核心。路由系统的职责是从请求URL中获取controller和action的名称以及其它请求数据。
    UrlRoutingModule根据当前请求的URL和RouteTable中已注册的路由模板进行匹配并返回第一个和当前请求相匹配的路有对象Route，而后根据路有对象获取路由数据对象RouteData(ASP.NET MVC中，路由数据必须包含controller和action的名称)，再有RouteData获取IRouteHandler最终有IRouteHandler获得IHttpHandler

  • HttpHandler

    一个HTTP请求最终要进入HttpHanler中进行处理，一次HTTP请求只能被一个HttpHandler进行处理。

  • Controller
    IHttpHandler在ProcessRequest方法中对当前请求进行处理，在该方法中经过ControllerBuilder获得IControllerFactory而后经过反射的方式获取Controller的类型。

  • Action

    ASP.NET MVC中ControllerBase是全部Controller的基类，在该类型的Execute方法中经过IActionInvoker的InvokeAction方法来执行对Action的调用。在Action执行前会进行模型绑定和模型认证操做。

  • Filters

    在ASP.NET MVC5中有经常使用的过滤器有5个：IAuthenticationFilter、IAuthorizationFilter、IActionFilter、IResultFilter、IExceptionFilter。
    在ASP.NET MVC中全部的过滤器最终都会被封装为Filter对象，该对象中FilterScope类型的属性Scope和int类型属性Order用于决定过滤器执行的前后顺序，具体规则以下：
    Order和FilterScope的数值越小，过滤器的执行优先级越高；
    Order比FilterScope具备更高的优先级，在Order属性值相同时FilterScope才会被考虑

    //数值越小，执行优先级越高
  public enum FilterScope
  {
      Action= 30,
      Controller= 20,
      First= 0,
      Global= 10,
      Last= 100
  }

  • ActionResult

    Action执行完毕以后会返回ActionResult类型对象做为对这次请求进行处理的结果，对于不是ActionResult类型的返回值，ASP.NET MVC会将其转换为ActionResult类型。

总结：那这个就是MVC模式下，一个大概的请求走向，在MVC的模式下，它的管道是啥样子的。

3.5 看完MVC ，咱们接着来看最牛的Core，谁叫它能够跨平台呢【傲娇】

既然Core是跨平台的，那么它不依托IIS，如今的IIS就是个摆设，它有独立的Core的SDK，Core的RunTime。咱们来一探究竟！

Core是跨平台的，那他是怎么实现的呢，其实他本身自己有本身的Kestrel Server，能够直接对外部提供服务。可是还须要有个反向代理服务器将他保护起来，IIS就是其一，其余平台有其余的方式。

上图：

知识点:IIS 是经过 HTTP 的方式来调用咱们的 ASP.NET Core 程序。而部署在IIS中时，并不须要咱们手动来启动 ASP.NET Core 的控制台程序，这是由于IIS新增了一个 AspNetCoreModule 模块，它负责 ASP.NET Core 程序的启动与中止，并能监听 ASP.NET Core 程序的状态，在咱们的应用程序意外崩溃时从新启动。

  • Hostting(宿主)

    IIS经过Http调用Core应用程序，因此咱们确定要建立一个Host来启动Core，WebHost，上面咱们也讲到宿主，咱们经过宿主在生成一系列的Http的上下文，环境等。整个http请求都在宿主内。

    • WebHost的建立

      public class Program{
      public static void Main(string[] args){
      CreateWebHostBuilder(args).Build().Run();
      }

      public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
      WebHost.CreateDefaultBuilder(args)
          .UseStartup<Startup>();
  }

      咱们能够看到WeHost经过静态自己来调用建立出来的。“CreateDefaultBuilder”用来作一些简单的配置

      1. 注册 Kestrel 中间件，指定 WebHost 要使用的 Server（HTTP服务器）。
      2. 设置 Content 根目录，将当前项目的根目录做为 ContentRoot 的目录。
      3. 读取 appsettinggs.json 配置文件，开发环境下的 UserSecrets 以及环境变量和命令行参数。
      4. 读取配置文件中的 Logging 节点，对日志系统进行配置。
      5. 添加 IISIntegration 中间件。
      6. 设置开发环境下， ServiceProvider 的 ValidateScopes 为 true，避免直接在 Configure 方法中获取 Scope 实例。

      接着指定Startup最终使用Build建立WebHost。紧接着使用Run将程序跑起来。

    • WebHost的启动
      1. 初始化，构建 RequestDelegate
        RequestDelegate 是咱们的应用程序处理请求，输出响应的整个过程，也就是咱们的 ASP.NET Core 请求管道。
        1. 调用 Startup 中的 ConfigureServices 方法
        2. 初始化 Http Server
          Server 是一个HTTP服务器，负责HTTP的监听，接收一组 FeatureCollection 类型的原始请求，并将其包装成 HttpContext 以供咱们的应用程序完成响应的处理。
        3. 建立 IApplicationBuilder
          IApplicationBuilder 用于构建应用程序的请求管道，也就是生成 RequestDelegate
        4. 配置 IApplicationBuilder
      2. 启动 Server，监听请求并响应
      3. 启动 HostedService
        那这边是简单的讲了下WebHost，具体的内容能够看下文章末尾的Core的连接。
  • Middleware（中间件），管道模型的构成
    • IApplicationBuilder
      首先，IApplicationBuilder 是用来构建请求管道的，而所谓请求管道，本质上就是对 HttpContext 的一系列操做，即经过对 Request 的处理，来生成 Reponse。所以，在 ASP.NET Core 中定义了一个 RequestDelegate 委托，来表示请求管道中的一个步骤，它有以下定义：
      public delegate Task RequestDelegate(HttpContext context);
      而对请求管道的注册是经过 Func<RequestDelegate, RequestDelegate> 类型的委托（也就是中间件）来实现的。它接收一个 RequestDelegate 类型的参数，并返回一个 RequestDelegate 类型，也就是说前一个中间件的输出会成为下一个中间件的输入，这样把他们串联起来，造成了一个完整的管道。
      它有一个内部的 Func<RequestDelegate, RequestDelegate> 类型的集合（用来保存咱们注册的中间件）和三个核心方法：
      1. Use
      Use是咱们很是熟悉的注册中间件的方法，其实现很是简单，就是将注册的中间件保存到其内部属性 _components 中。
      2. Build
      在 Hosting 的启动中，即是经过该 Build 方法建立一个 RequestDelegate 类型的委托，Http Server 经过该委托来完成整个请求的响应
      3. Run
      在咱们注册的中间件中，是经过 Next 委托 来串连起来的，若是在某一个中间件中没有调用 Next 委托，则该中间件将作为管道的终点，所以，咱们在最后一个中间件不该该再调用 Next 委托，而 Run 扩展方法，一般用来注册最后一个中间件
      4. New
      New 方法根据自身来“克隆”了一个新的 ApplicationBuilder 对象，而新的 ApplicationBuilder 能够访问到建立它的对象的 Properties 属性，可是对自身 Properties 属性的修改，却不到影响到它的建立者，这是经过 CopyOnWriteDictionary 来实现的

    因此 Core的管道其实就是Middleware来作的，每一个都有前置，后置的处理步骤，中间能够调用其余Middleware。也能够并行走向。

ASP.NET Core 请求管道的构建过程，以及一些帮助咱们更加方便的来配置请求管道的扩展方法。在 ASP.NET Core 中，至少要有一个中间件来响应请求，而咱们的应用程序实际上只是中间件的集合，MVC 也只是其中的一个中间件而已。简单来讲，中间件就是一个处理http请求和响应的组件，多个中间件构成了请求处理管道，每一个中间件均可以选择处理结束，仍是继续传递给管道中的下一个中间件，以此串联造成请求管道。一般，咱们注册的每一个中间件，每次请求和响应均会被调用，但也可使用 Map , MapWhen ,UseWhen 等扩展方法对中间件进行过滤。

3.6总结

那咱们分析了以往微软的3种形式底下的Web，分别是WebForm，MVC，Core，其中WebForm与MVC雷士，依托于IIS，不一样的就是ISAPI的不一样。前者的ISAPI以插件形式存在IIS，然后者将其整合成一套。Core跨平台，IIS只是他的一个反向代理服务器，HTTP请求带Core的程序，运行Core。
可是我以为他们内容是基本不变的，HTTP请求，进来在彼此的AppDomain中建立HttpContext,而后就开始走Pipeline走流程，WebFrom走Page的IHTTPHandler与其相关的IModule，而MVC是Global.asax继承HttpApplication,HttpApplication又继承IHTTPHandler，接下来WebFrom与MVC就各自走各自的Pipeline。Core却不是这样，它的Pipeline采用了Middleware（中间件）的形式。俄罗斯套娃，一步一步走Pipeline。最终都是响应客户端，一个HTTP请求，从开始到结束。

感谢张子阳的博客-WebForm
感谢雪飞鸿的博客-MVC
感谢雨夜朦胧-Core

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