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教程