.NET總結--ASP.NET工做原理

前言

　　前先後後寫了很多關於某些技術啥的博客,一直在追新求深,而真正使用上的時候才發現瞭解的太少太少了,從事.net開發三年有餘了不是它不行了而是我堅持不住了,現在不得不向生活低頭,這個系列做爲三年技術知識的一個小小總結吧,最主要的是寫給本身也許這些在技術大牛哪裏根本不值一提,而我卻把它當成個人所有.

簡介

　　主要剖析一下客戶端(Browser)發送請求到服務端過程如何處理

ASP.NET請求解析

　　IIS6

　　請求流程:客戶端向IIS發送請求,該請求由http.sys(監聽),當監聽到http請求時分配w3wp.exe運行進程進行(處理),若爲靜態請求直接返回客戶端,其餘則搜尋擴展程序表也就是(監控)程序(Metabase) 查找相應ISAPI.DLL處理,如圖:

　　

　　IIS7

　　與6相比較7不單單多了許多功能 其實本質上沒有太大變化工做流程如圖:

　　

 

　　

 　　1.IIS7 服務器不單單支持最大鏈接數限制還能夠限制帶寬使用

 　　2.IIS7增長了失敗請求跟蹤規則

　　 3.應用程序池單獨權限設置

　　 此外.iis7與ii6 映射策略略有不一樣,當iis啓用經典模式的時候與iis6同樣使用aspnet_isapi.dll針對.aspx請求處理,可是當啓用集成模式的時候則使用託管程序處理(System.Web.UI.PageHandlerFactory)

CLR處理機制

　　

　　

　　如上圖所示根據集成魚託管模式區分調用有所差別aspnet_isapi.dll 工做原理如圖:

　　

　　這裏引用一下園子小哥的總結:　　

　　由ISAPI aspnet_isapi.dll加載CLR環境。

1. IsapiRuntime運行時被加載，接管了HTTP請求後，建立IsapiWorkerRequest對象來封裝當前的HTTP請求，隨後把對象傳遞給ASP.NET運行時HttpRuntime。

2. HttpRuntime會根據IsapiWorkerRequest對象建立表示當前HTTP請求的上下文對象HttpContext。

3. HttpApplicationFactory會建立或者從HttpApplication對向池中選取可用的HttpApplication對象，處理完後釋放。

4. HttpApplication在初始化中，ASP.NET會根據配置文件加載HttpModule對象（用於註冊HttpApplication對應的事件，將所需的操做注入Htt請求的處理流程）

5. Http請求最終由HttpHandler處理。不一樣的資源類型對應不一樣的HttpHandler。

總結

　　

 

　　首先，瀏覽器嘗試鏈接Web服務器的80端口，若是Web服務器能夠響應此鏈接請求，就在瀏覽器與Web服務器間創建了一個通信鏈路，在此「通道」上瀏覽器與Web服務器能夠相互發送與接收信息。

假設瀏覽器向Web服務器發出一個讀取某ASP.NET站點上的某個ASPX網頁的請求。當此請求經過網絡到達Web服務器時，此請求被HTTP.SYS組件所接收。HTTP.SYS系統組件會檢查此HTTP請求的相關信息，根據其URL將此HTTP請求發送給運行在某個應用程序池中的工做者進程處理。若是同時有多個針對此ASP.NET站點的HTTP請求，HTTP.SYS會將這些請求排隊，加入到對應的應用程序池的HTTP請求隊列中等待。

若是這是第一個對ASP.NET站點的HTTP請求，工做者進程會加載aspnet_isapi.dll，並將請求轉給它，aspnet_isapi.dll接着會裝載.NET CLR，建立一個針對此ASP.NET站點的應用程序域，而後啓動一個複雜的由多個步驟和組件參與的處理流程，當此處理流程結束，要發回給客戶端的結果（一般是HTML代碼，固然也能夠是其餘類型的資源，好比由程序動態生成的圖片）已經生成，此結果被轉發給HTTP.SYS。

　　注意：對於以集成模式運行的IIS 7，.NET CLR在應用程序池一啓動就自動裝載，從而避免了臨時裝載CLR的花銷。後繼處理過程與IIS 6基本一致。