IIS Web 服務器/ASP.NET 運行原理基本知識概念整理

 前言：

     記錄 IIS 相關的筆記仍是從公司筆試考覈題開始的，問 Application Pool 與 AppDomain 的區別？

     促使我對進程池進了知識的學習，因此記錄一下學習的筆記。

 

     咱們知道如今 .NET 就業來看，80% 的 .NET 程序員都是從事 Web 開發，

     若是對微軟惟一（如今不惟一了）Web 服務器都不熟的話，那就有點兒尷尬了；（不能被微軟寵壞了）

 

     Web 站點性能的好壞不在於 Web 服務器自己，IIS 能夠說已經說一款很是強悍的 Web 服務器了。

     如今對 IIS 6.0、IIS 8.5 作一些基本知識的整理；

 

     微軟早期在 IIS 上，提出進程池的概念，容許多個 Web 站點運行在一個 IIS 進程池（W3WP.exe）上，怎麼說有好有壞，

     好在他節省了 CPU、內存的開銷，壞在他進程池的配置非獨立，最大問題是某一個 Web 站點掛了，同一個進程次下的站點都會掛掉。

     乃至在 IIS 7+ 以上的版本，默認建立的站點都會是獨立的進程池；

 

     Web 服務器其實深刻進去也沒有什麼多神祕的東西，核心取決於你的設計，怎麼合理處理請求/響應、併發控制；

 

     // 追評：

          全部的 Web 服務器，無非是對網絡層和 HTTP 協議層作了相應的解析處理而已。

 

1、IIS 6.0

     早些年，公司還在一直在使用 IIS 6.0，做爲微軟早期的版本，那各類安全問題源源不斷，此處默哀一下苦逼的程序員

     什麼遠程代碼執行、上傳數據流漏洞、身份認證漏洞.... 致使不少 .NET 開發人員以爲 Web 服務器放在 Windows 下就是不安全。

     其實微軟背後的團隊，已經很是努力的在作補丁和迭代了，

     注意：

     一、服務器上必定不要關閉 Windows Update。

     二、做爲一名程序員，有責任關於微軟動態、更新穩定的 IIS 版本。

 

     IIS 6.0 因爲太老的產品，不作過多的分析。

 

2、IIS 運行過程

     （這樣比較好理解，僞裝本身在寫 Web 服務器）

 

     首先，HTTP 請求規範原理、細節不作解釋了。

     咱們都知道 IIS Web 服務器默認監聽 80 端口，那麼監聽的過程總得須要支撐吧，

     HTTP.sys 組件，它負責監聽全部的 HTTP 請求，監聽到請求了之後，

     根據請求信息（URL）分配對對應的進程池上（W3WP.exe/Application Pool），進程池完成本次請求處理後進行響應；

     // 在上文簡單提到了 IIS 進程池，全部的站點都必要依賴與他，而進程池啓動後會產生一個獨立的 W3WP.exe 進程

 

     一、HTTP.SYS：（Kernel）的一個組件，它負責偵聽（Listen）來自於外部的HTTP請求,根據請求的URL將其轉發給相應的應用程序池 (Application Pool)。

          當此HTTP請求處理完成時，它又負責將處理結果發送出去。

          爲了提供更好的性能，HTTP.sys 內部創建了一個緩衝區，將最近的HTTP請求處理結果保存起來。

 

     二、Application Pool：IIS 總會保持一個單獨的工做進程：應用程序池。全部的處理都發生在這個進程裏，包括 ISAPI dl l的執行。

   　　應用程序池它們容許以更小的粒度控制一個指定進程的執行。

   　　你能夠爲每個虛擬目錄或者整個Web 站點配置應用程序池，這可使你很容易的把每個應用程序隔離到各自的進程裏，

    　  這樣就能夠把它與運行在同一臺機器上其餘程序徹底隔離。從 Web 處理的角度看，若是一個進程死掉，至少它不會影響到其它的進程。

　　  當應用程序池接收到 HTTP 請求後，交由在此應用程序池中運行的工做者進程 Worker Process: w3wp.exe 來處理此HTTP請求。

 

　　三、Worker Process: 當工做者進程接收到請求後，首先根據後綴找到並加載對應的 ISAPI 擴展 (如:aspx 對應的映射是 aspnet_isapi.dll )，

     　 工做者進程加載完 aspnet_isapi.dl l後，由 aspnet_isapi.dll 負責加載 ASP.NET應用程序的運行環境即CLR (.NET Runtime)。

          Worker Proces s運行在非託管環境，而 .NET 中的對象則運行在託管環境之上(CLR)，它們之間的橋樑就是 ISAPI 擴展。

 

　　四、WAS（Web Admin Service）：這是一個監控程序，它一方面能夠存取放在InetInfo元數據庫（Metabase）中的各類信息，

     　 另外一方面也負責監控應用程序池（Application Pool）中的工做者進程的工做狀態況，必要時它會關閉一個老的工做者進程並建立一個新的取而代之。

 

　　看圖：

       

     

　 進程池中 經典管道 ISAPI 的做用、生命週期？

      集成管道中的乞求處置管道怎麼理解？

 

 

2、ASP.NET 運行原理（淺析）

 

     看圖：

     

   （ AppDomain 運行過程圖示）

 

　AppDomain 的做用,相信你們都很瞭解了吧.這裏簡明扼要的寫幾點:

 

　一、一個 AppDomain 中的代碼建立的對象不能由另外一個 AppDomain 中的代碼直接訪問（只能使用按引用封送或者按值封送,起到了很好的隔離做用）；

 

　二、AppDomain 能夠卸載 CLR 不支持從 AppDomain 中卸載一個程序集的能力，但能夠告訴 CLR 卸載一個 AppDomain，

     　從而達到卸載當前包含在該 AppDomain 內的全部程序集.

 

　三、AppDomain 能夠單獨保護 當宿主加載一些代碼以後,能夠保證這些代碼不會被破壞（或讀取）宿主自己使用的一些重要的數據結構.。　

 

　四、AppDomain 能夠單獨配置 設置主要影響 CLR 在 AppDomain 中加載程序集的方式,涉及搜索路徑、版本綁定重定向、卷影複製及加載器的優化。

 

　由以上幾點能夠看出 AppDomain 確保了 Windows 系統及其中運行的應用程序的健壯性。AppDomain 提供了保護、配置和終止其中每個應用程序所需的隔離性。

 

 

   再來看下 ProcessRequest 的過程：

   

　簡單分析一下上圖

 

　ProcessRequest(HttpWorkerRequest wr)中判斷 wr 是否爲 null，而後判斷管線是否完整，再調用 ProcessRequestNoDemand(wr) 方法，

　並判斷當前 RequestQueue 是否爲 null，接着計算等待時間並更新管線數 CalculateWaitTimeAndUpdatePerfCounter(wr)；

　重置 wr 開始時間 wr.ResetStartTime()；調用 ProcessRequestNow(wr) 方法，並調用 ProcessRequestInternal(wr) 方法；

 

---

 

　到這裏想必可以使你們對ASP.NET管道機制可以有一個簡單的回顧.固然還有不少地方沒有詳細分析。

　再來總結一下IIS運行過程及ASP.NET管道機制：

 

     Request→ (Internet ) HTTP.sys 監聽

     → WAS (IIS6 web Admin Service /IIS7 (Windows Activation Service) 接收請求

     → (傳入)Application Pool's → w3wp.exe(檢查URL後綴)

     → (加載)ISAPI擴展[aspnet_isapi.dll] → 註冊映射 構造HttpRuntime類

     →ProcessRequest方法  HttpContext實例產生(Request,Response,Session and so on…)

 

　HttpRuntime 調用 HttpApplicationFactory加載HttpApplication對象

 

　穿越HttpModule到達HttpHandler

 

　簡單用140個字符(即一條微博的字數)歸納:

 

　Request→ (Internet ) HTTP.sys →(WAS)→Application Pool's → w3wp.exe→ISAPI→ Map→   (Pipeline)        

　HttpWorkerRequest→AppDomain→HttpRuntime→ProcessRequest()→ HttpContext(Request,Response)

　　→ HttpRuntime→HttpApplicationFactory→HttpApplication→ HttpModule→HttpHandler→EndRequest