從Asp .net到Asp core （第一篇）《回顧Asp .net生命週期與管道機制》

從2016年微軟收購了Xamarin整合到Visual Studio裏並將其開源到如今已有三年多時間，從.net core 1.0 到如今的2.2，以及即將問世的3.0，咱們看到微軟正在跨平臺之路越走越遠，從以前的偏科學生變成了如今的三號學生，但願覺得之後還會愈來愈好

做爲微軟的狂熱粉，從17年末就開始熱衷於.net core 的學習和使用，下面談談我對web 框架asp core的簡單理解

1：首先第一個問題.net core和Asp core有什麼區別？是同一個東西嗎？

　　.net core是一個統一的平臺，是微軟準備要用來開發移動端，桌面應用，web網站等的總體平臺

　　asp core 是.net core着重開發網站的web 框架，這也就就比如以前.net框架與Aps .net框架的關係，能夠理解爲包含關係吧

2：Asp core與原來的Asp .net框架有什麼區別，它對比傳統Asp .net框架到底有哪些好處？

　　首先我想說，Asp core其實對比原來的Asp .net，其實能夠說徹底是一套新的東西（並不像以前Asp .net到Asp .net MVC，Asp .net MVC只是在原有的Asp .net框架擴展和升級，其本質仍是.net框架的那一套）。

可是Asp core雖然說是一套新的框架，聽到說是新的東西也沒關係張，我的感受Asp core不少基礎開發的用法，仍是保留了原來.net開發人員的一些開發習慣，實際開發過程當中我的的感受沒有給人一種陌生的感受

　　對比Asp core與Asp .net的區別：

• 首先一條Asp core是跨平臺的，何爲跨平臺，就是Asp core能夠部署和運行在windows之外的其餘服務器上面（固然必需要在所要運行的系統上安裝有運行時，比如java的JRE）好比更適合作服務器系統的linux服務器，並且並不像以前的Aps .net徹底依賴IIS，新的Asp core能夠部署到IIS，Nginx，Apache等其餘代理服務器
• 新的Asp.net core默認使用Kestrel做爲Http請求的監聽器，而並不依賴原先龐大複雜的Https.sys。Kestrel不只僅是微軟下一代的跨平臺Http請求監聽器，同時還提供了比Https.sys更輕量級以及更快速的Http請求處理。
• Asp.net core與原來的Web設計另外一個最大的區別在於Asp.net core(及.net core)，徹底拋棄了原來的使用管道模式來接收以及處理HttpRequest。在Asp.net core中容許處理中間件(Middleware)來對全部的HttpRequest來進行請求，當請求被接收到時，Asp.net core會調用註冊的中間件（按照註冊的順序）對HttpRequest進行處理。這樣作相比與原來使用HttpApplication的管道方式而言，其優點在於徹底由開發人員決定HttpRequest須要執行怎麼樣的處理，沒有多餘的其餘步驟。而原來的方式既使開發人員不但願對一個HttpRequest進行任何處理，但HttpApplication仍然會按照管道的設置依次建立HttpModel -> 激活HttpHandler -> 處理Session等。相對原來的Aps .net程序，程序性能也有很大的提高

3：傳統的asp .net框架請求處理流程

　　3.1 IIS服務器請求處理流程

　　1，當IIS服務器接收到一個 Http請求的時候，對於IIS來講，它依賴一個叫作 HTTP.SYS 的內置驅動程序來監聽來自外部的 HTTP請求。

　　在操做系統啓動的時候，IIS首先在HTTP.SYS中註冊本身的虛擬路徑。實際上至關於告訴HTTP.SYS哪些URL是能夠訪問的，哪些是不能夠訪問的（舉個簡單的例子：爲何你訪問不存在的文件會出現 404 錯誤呢？就是在這一步肯定的）。

　　若是請求的是一個可訪問的URL，HTTP.SYS會將這個請求交給 IIS 工做者進程（IIS6.0中叫作 w3wp.exe，IIS5.0中叫作 aspnet_wp.exe。）。

　　每一個工做者進程都有一個身份標識 以及 一系列的可選性能參數（是指諸如 回收機制的設置、超時時間設置 等等）。

　　2，而後請求會首傳遞到ISAPI（Internet Server Application Programe Interface，互聯網服務器應用程序接口），ISAPI決定如何去處理這個請求，若是服務器獲取所請求的靜態文件（也能夠是文件，好比 jimmy.jpg）的後綴名以後，接下來會在服務器端尋找能夠處理這類後綴名的應用程序，若是IIS找不到能夠處理此類文件的應用程序，而且這個文件也沒有受到服務器端的保護（好比代碼文件，配置文件.config都是受保護的， 不受保護的好比js，css），那麼IIS將直接把這個文件返還給客戶端。

ISAPI是什麼？到底長啥樣?

ISAPI 服務器擴展是能夠被 HTTP 服務器加載和調用的 DLL(動態連接庫)

如圖：

　　3，而後ISAPI 還需調用 HttpRuntime的ProcessRequest方法，開始進入請求管道週期，請求最終走完整個管道週期，ISAPI 接收返回的數據流，並從新返還給 HTTP.SYS，最後，HTTP.SYS 再將這些數據返回給客戶端瀏覽器。

上面文字總結可能有些枯燥，下面這張圖片也許會清晰許多

　流程：請求開始=>Http.Sys=>ISAPI=>CLR/HttpRuntime=>ISAPI=>Http.Sys=>請求結束

　　3.2 理解管道

  前面講到請求在IIS中的一個簡單流程，可是講到當請求進入asp.net Runtime以後的細節，只是一筆帶過，沒有將請求在asp.net Runtime中到底通過了哪些處理，最終又是如何返回請求結果的，下面就來簡單講解一下整個過程

  這裏會是涉及到在.net框架兩個比較重要的概念：Http Module和 Http Handler

  想要理解這兩個概念，首先要知道當請求進入asp.net Runtime以後會經歷以下圖的十九個事件

對於這個事件要廢話幾句，這個流程雖然看着比較多，對於初學者其實不要有太大壓力，其實徹底不必去每個都研究他，只是大概過一遍，知道有這麼個東西，混個眼熟就行了

Http Module 託管模塊

若是咱們想要在上面某一個事件中去處理咱們本身框架代碼，好比要在請求到達某個事件時咱們要對該請求進行篩選或者在此時記錄一條日誌，咱們應該怎麼作？

這裏就須要用到Http Module了，咱們能夠經過Http Module在Http請求管道(Pipeline)中註冊指望對應用程序事件作出反應的方法

Http Module實現了IHttpModule接口，IHttpModule接口要是實現Dispose和Init方法

Dispose：它能夠在進行垃圾回收以前進行一些清理工做。

Init：咱們能夠在init方法中註冊上面十九個事件的任意一個或者多個，並在對應的回調方法中去作實際的邏輯處理

具體代碼以下：

public class TestModule : IHttpModule { void IHttpModule.Dispose() { } void IHttpModule.Init(HttpApplication context) { context.EndRequest += new EventHandler(context_EndRequest); } private void context_EndRequest(object sender, EventArgs e) { /*HttpApplication對象包含了請求所須要的全部上下文對象，好比HttpContext,HttpRequest,HttpResponse,HttpSession等等，因此咱們能夠經過這個對象 來完成過濾請求，記錄日誌等等實際開發中會用到的功能 */ HttpApplication application = (HttpApplication)sender; HttpContext context = application.Context; context.Response.Write("<hr><h1 style='color:#f00'>來自HttpModule的處理，請求結束</h1>"); } }

值得注意的是Http Module所處理的請求一般是全局的，應用級別的，不是隻針對哪個頁面，什麼意思，好比把上面代碼做爲的例子，上面代碼的效果會使全部的頁面都會有 「來自HttpModule的處理，請求結束」，這句話

Http Handler 處理程序

對比Http Module，HttpHandler的處理請求的權限相對較低，維度也更細，它能夠只針對特定後綴的頁面，其實咱們的webform頁面其實也就是一個Handler

全部aspx頁面繼承System.Web.UI.Page，能夠看到Page類也實現了IHttpHandler接口

public interface IHttpHandler{ void ProcessRequest(HttpContext context); bool IsReusable { get; } }

• ProcessRequest 用來處理請求的主要代碼。
• IsReusable 屬性，MSDN上是這樣解釋的：獲取一個值，該值指示其餘請求是否可使用 IHttpHandler 實例。也就是說後繼的Http請求是否是能夠繼續使用實現了該接口的類的實例，通常來講，我把它設置成true。

 咱們HttpHandler用的比較多的場景就是有Ajax+Httphandler進行web無刷新頁面開發，而後就是HttpHandler實現圖片防盜鏈，IhttpHandler實現圖片驗證碼等等，傳統的Http Module和HttpHandler編寫程序，其實都是比較老的開發方式了，我的感受只須要學習和了解.net有這兩個東西就行了

通過上面基礎的學習，咱們來總計一下進入asp.net Runtime以後，和Http Module和HttpHandler發生了哪些關係，梳理出一個流程

1. 請求進入HttpRuntime
2. HttpRuntime 經過HttpApplicationFactory 建立 HttpApplication對象（HttpApplication表明着程序員建立的Web應用程序。HttpApplication建立針對此Http請求的 HttpContext對象，這些對象包含了關於此請求的諸多其餘對象如HttpRequest、HttpResponse、HttpSessionState）
3. 接下來Http請求經過一系列Module對請求進行應用級別的處理
4. Http Module處理完成後會把請求轉交給HttpHandler去進行一些定製化的頁面級別的處理
5. HttpHandler在處理完成後又會轉回Http Module作一些後續的收尾處理

 以上就是整個Asp.Net的生命週期，雖然在這以後，出現了Asp.Net MVC，正如前面所說，可是Asp.Net MVC框架並非一套新的框架，Asp.net Mvc仍是以Asp.net運行時爲基礎的。可是Asp Core並再也不以Asp.netRuntime爲基礎的，因此它也沒有了十九個事件，也沒有了Http Module和HttpHandler這一套，可是Asp Core引入了一些新的核心概念如中間件（middleware），控制反轉容器（DI）等等，那麼我會在下一篇文章簡單解析Asp Core一些相關概念，以及它的的請求週期

 

參考資料：

http://go.microsoft.com/?linkid=8101007

https://docs.microsoft.com/en-us/previous-versions/aspnet/ms227435(v=vs.100)

http://www.tracefact.net/tech/001.html

https://www.cnblogs.com/me-sa/archive/2009/06/01/MVCLifecycle.html