【原創】asp.net內部原理（三） 第三個版本 (最詳細的版本)

前言： 今天繼續吧這個系列補齊，這幾天公司的項目比較忙，回到家已經很是的累了，因此也沒顧得上每天來這裏分享一些東西和你們一塊兒探討，可是今天晚上我仍是堅持打開電腦，分享一些asp。net生命週期的知識，一是能夠鞏固本身所掌握的知識，而且在分享的期間也能發現一些問題和你們一塊兒探討，同時也但願讓一些「小白」們儘量的瞭解asp內部的運行原理，不要天天只知道把控件拖來拖去，或者是隻是知道這麼寫代碼，而不知道爲何這麼寫代碼。

首先呢，讓咱們在複習一下上一節的內容：

1）瀏覽器輸入請求網址的域名，瀏覽器按照HTTP協議封裝成請求報文，而後經過DNS解析域名獲得IP地址，接着經過socket插座將請求報文傳到服務器.

2）IIS接受到請求後，解析要求請的是一個什麼類型的文件，若是請求的是靜態文件，那麼IIS會直接處理，在本地找到請求的靜態文件，而後發送給瀏覽器。

3）若是是動態文件，如aspx或者ashx等動態文件，IIS會發現本身處理不了這樣的文件，那麼，IIS就會去他的映射表裏面去找，實現它接口的那個擴展程序能夠處理這樣的動態文件，而後IIS發現有個叫作aspnet_isapi的這樣一個擴展程序能夠處理處理像.aspx和.ashx這樣後綴名的文件，那麼IIS則把請求交給這個aspnet_isapi來處理。

4）aspnet_isapi將啓動CLR（公共語言運行時），負責啓動asp.net框架的域，而後將請求交給asp.net框架來處理，框架裏面有個一HttpRuntime類的對象，那倒請求後，它負責將請求封裝成HttpContext對象，常見Application對象，調用application對象的ProcessRequest方法（HttpContext對象做爲參數）處理請求（具體的實現咱們將在後面講解到），最後處理完成後，返回給IIS，IIS在返回給瀏覽器。

這是上一結咱們所講的內容，那這一節咱們主要講的是：

1--請求報文是怎麼到iis的，iis又是怎麼處理的

2--請求報文時怎麼傳遞給CRL的

3--CRL拿到請求以後具體是解析處理請求，而後呈現出咱們想要的頁面。這裏咱們重點研究兩個東西：

　　1）---Application對象的建立以及 HttpModule 註冊管道的事件  golable註冊管道事件

　　2）---頁面的生命週期

 

這一節的內容比較多，並且有些小夥伴認爲這裏面有些東西是在開發過程中用不到這知識，可是筆者認爲從基礎和原理去了解才能讓咱們正確的掌握asp。net開發而且開發出高質量的應用程序。

 

 

在閱讀本節內容時，你們先了解一下如下幾個概念

內核模式:就是操做系統模式，其中的程序代碼能直接訪問全部內存（包括全部的用戶模式進程和應用程序的地址空間）和硬件，也稱爲「管理員模式」、「保護模式」或「Ring 0」。

用戶模式：跑在操做系統之上，好比說qq，百度影音這些應用程序。都是跑在用戶模式之上的。

在windows xp之前（包括xp）,基於http協議的的程序都是在用戶模式下運行的，並且必須本身處理例如軟件中斷、context swith、線程調度等問題，而且沒法直接接觸系統資源，過去，HTTP服務器，如IIS, Apache等都是利用Winsock API來建立一個User mode下的network listener，這個network listener每每獨自佔用一個ip端口，也就是說，同一個端口在同一時間只能有一個應用程序監聽，這在有些時候是一個不太使人舒服的限制。

在windows 2003之後，

進了新的HTTP API和kernel mode driver（內核模式驅動） Http.sys，目的是使基於Http服務的程序更有效率。這個改變的直接收益者就是IIS6.0和ASP.NET。

那麼如今是有http.sys來監聽求情端口。http.sys得好處：

一、能夠緩存，靜態內容能夠緩存到內核模式下，是服務器相應更加快速

二、安全可靠，應爲全部的請求都會在http.sys裏面暫存在列隊中，而不是由服務程序自己來處理，這樣一來，就是服務程序崩潰重啓，請求也不會丟失。

三、IP端口重用 － 如今，只要是經過Http.sys管理的端口（基本包括了那些著名的端口，好比80），均可以同時容許多個程序同時監聽了。

四、帶寬控制(額。。其實我也不知道他這個是咋控制的，反正就是能控制)

 

 

好了，瞭解了這些以後，讓咱們進入今天的正題。

首先我仍是上一個圖吧。你們看着圖，而後我在下面解釋，我以爲這樣會解釋的更清楚一些。

1--首先，瀏覽器發送一條請求到服務器，服務器端,內核模式下的http.sys這個內核驅動，拿到了http請求，拿到請求後，他要去找，哪一個應用程序能夠處理這個求情（或者說去找誰在我這注冊過，說它吖的能夠處理http請求），去哪找呢，是去註冊表裏面找。而後他發現，有個叫iis的小子在我這注冊過，說它能夠處理，那麼http.sys就把這個請求交給iis去處理。

2--這時，iis拿到了請求。 其實iis能夠分爲兩塊，一塊就是iis的核心進程:inetinfo.exe（這裏面放着iis的全部的配置信息和網站信息），另外一塊就是w3svc服務（寄生在svchost進程上），這個服就是管着將請求分發的。分發給什麼呢？就是在上一節中咱們說到的像aspnet_isapi.dll這樣的擴展程序。這個服務先去核心進程裏面的配置信息裏面去尋找，註冊的哪一個擴展程序能夠處理請求的頁面，好比請求的是aspx頁面，他發現aspnet_isapi.dll這個擴這注冊了說它能夠處理，那麼w3svc服務將請求分發給aspnet_isapi.dll來處理。

3--這時，aspnet_isapi.dll 拿到了請求信息，這時，aspnet_isapi.dll負責啓動CLR（公共語言運行時，裏面跑的是託管代碼），這裏你能夠把aspnet_isapi.dll當作是一個橋樑，一個非託管和託管之間的一個橋樑 。

 

CLR被啓動好了以後，調用託管代碼中ISAPIRuntime得ProcessRequest（之後我會簡稱其爲PR方法），ISAPIRuntime類就是system。web。hosting命名空間下的一個類，也是CLR處理http請求的一個入口類，若是你想看CRL是怎麼處理http請求，你就能夠從這個類開始。

 

在上圖中咱們能夠看出調用了ISAPIRuntime類的PR方法，將http請求信息（ecb）做爲參數傳進去。

　　---ecb：包含了底層的全部請求信息，包括服務器信息，一個來組織標量的輸入流還有一個寫回數據給瀏覽器的輸出流，，它包含了ISAPI求其的全部功能。

 

如上圖在ISAPIRuntime的PR方法中，先建立了一個HttpWorkerRequest對象，而後又調用了HTTPRuntime的PR方法進一步處理請求。

 

如上圖，在HttpRuntime的PR方法裏面，主要三個事就是：

　　1--建立上下文對象HttpContext（將請求信息封裝成上下文對象）

　　2--建立Application對象：這裏用到了應用程序池技術，由於建立一個Application對象很消耗資源。這個Application對象很重要，在下一節咱們重點討論他，同時在下一節還討論時如何建立頁面控件樹的。

　　3--調用Application對象的PR方法，將上下文對象做爲參數穿進去。此時，http請求（這時候已經被封裝成HttpContext）就由application交給了HttpHandler來處理，而後調用HttpHandler的PR方法，繼續處理請求（這裏開始走頁面的生命週期，也就是那十個事件）

 

在HttpApplication的PR方法裏，開始走HttpApplication負責的求情處理管道，就是咱們常常說的19個事件，23個步驟。

在這個請求處理管道里面具體的內容，我貼上兩個圖，相信你們就看的差很少明白了，若是不明白也不要緊，在下一節我會詳細介紹請求管道乾的事情和咱們在開發過程當中若是應用這個管道寫出高質量的web應用程序。

 

 

【原創】前言  

【原創】asp.net內部原理（一） 第一個版本  

【原創】asp.net內部原理（二） 第二個版本  

好啦，今天就介紹到這吧，各位，晚安。