ASP.NET HTTP運行時組成的詳解

asp.net|詳解 簡介

　　不管使用哪種底層平台，可靠性和效能都是對所有 Web 應用程式的主要要求，儘管從某種意義上講，這兩個要求是相互矛盾的。例如，要構建更可靠、更健壯的應用程式，可能需要將 Web 服務器與具體的應用程式分離，使應用程式在進程外工作。但是，如果在不同於 Web 服務器進程的記憶體環境中工作，應用程式將變慢。因此，需要採取合理的措施，以確保進程外代碼儘可能快地運行。

　　在構建 Microsoft? ASP.NET 運行時環境時，依據的設計原則即：充分考慮可靠性和效能。得到的 ASP.NET 進程模型包含了兩個系統元素 - 一個存在於 Web 服務器進程中的進程內連接器，一個外部的輔助進程。另外，ASP.NET 運行時結構的可伸縮能力很強，可以自動使用多處理器硬體中任意選定的處理器。這種模式被稱為“Web Garden”，它可以使多個輔助進程同時運行，而且各個進程均在獨立的處理器中。

　　高度概括起來，ASP.NET 運行時具有三大屬性：

　　應用程式和 ASP.NET 輔助進程之間完全分離。提供服務的輔助進程的壽命決不會影響應用程式的壽命。換句話說，當應用程式啟動並處於運行狀態時，輔助進程可以隨時終止。
儘管 ASP.NET 應用程式從不在 Web 服務器內採用進程內的方式運行，但大多數情況下，其總體效能仍接近於進程內應用程式的效能。

　　為 Web Garden 體繫結構提供了內建的和可配置的支援。只要簡單檢查一下設定檔中的設定，輔助進程就可以複製自己，以利用所有與進程密切相關的 CPU。因此，在大多數情況下，您在具備多處理器的電腦中獲得的可縮放性將呈線性增長的趨勢。（本文後面將詳細介紹此內容。）

　　本文將介紹 ASP.NET 運行時環境的組成元素，然後一步一步地講述從 URL 請求變為純 HTML 文本的“漫長而曲折”的過程。

　　除非另有說明，否則以下介紹中均指 ASP.NET 的預設進程模型，即 Microsoft? Internet Information Services (IIS) 5.x 中唯一的模型。
　　ASP.NET 結構的組件

　　執行 ASP.NET 應用程式需要宿主 Web 服務器的支援。在 Microsoft? Windows? 的 Server 平台中，Web 服務器由名為 inetinfo.exe 的 IIS 可執行檔表示。Windows 2000 及以上版本的作業系統本身均提供了 Web 服務器。但需要注意，在 Microsoft? Windows Server™ 2003 中，並未預設安裝 IIS 和 ASP.NET，必須通過單擊“控制台”中的“添加或刪除程式”小程式將其添加到系統中。

　　IIS 是一個未託管的可執行程式，它提供了一個基於 ISAPI 擴充模組和篩選器模組的可擴充模型。通過編寫此類別模組，開發人員可以直接管理對特定資源類型的請求，並在各個預定義的步驟中接收當前請求。擴充和篩選器是一些 DLL，可以匯出一些具有已知名稱和簽名的函數。這些外掛程式組件是在 IIS 設定資料庫中註冊並配置的。
　
　　只有少數幾種被用戶端請求的資源類型由 IIS 直接處理。例如，對 HTML 頁面、文字檔、JPEG 和 GIF 映像的傳入請求由 IIS 處理。對 Active Server Page (*.asp) 檔案的請求通過調用名為 asp.dll 的 ASP 專用擴充模組進行解析。同樣，對 ASP.NET 資源（例如，*.aspx、*.asmx、*.ashx）的請求將傳遞到 ASP.NET ISAPI 擴充。該系統組件是一個名為 aspnet_isapi.dll 的 Win32 DLL。ASP.NET 擴充可以處理多種資源類型，包括 Web 服務和 HTTP 處理常式調用。

　　ASP.NET ISAPI 擴充是一個 Win32 DLL，未整合Managed 程式碼。它是接收和指派對各種 ASP.NET 資源的請求的控制中心。按照設計，該模組存在於 IIS 進程中，在具有管理員權限的 SYSTEM 帳戶下運行。開發人員和系統管理員不能修改此帳戶。ASP.NET ISAPI 擴充負責調用 ASP.NET 輔助進程 (aspnet_wp.exe)，而該進程又負責控制請求的執行。除了對請求進行安排以外，ASP.NET ISAPI 還監視輔助進程的運行情況，並在效能降低到一定程度時將進程取消。

　　輔助進程是一小段 Win32 shell 代碼，整合了公用語言運行庫 (CLR) 並運行Managed 程式碼。它負責處理對 ASPX、ASMX 和 ASHX 資源的請求。一般來說，此進程在一台給定的電腦中只有一個執行個體。所有當前啟用的 ASP.NET 應用程式均在其中運行，每個應用程式都位於一個獨立的 AppDomain 中。但是，如前所述，輔助進程支援 Web Garden 模式，即進程的相同副本都運行在與進程密切相關的 CPU 中。（更多內容，請參閱本文後面的“Web Garden 模型”部分。）

　　ISAPI 和輔助進程之間的通訊是使用一組具名管道進行的。具名管道是一種 Win32 機制，用於跨進程邊界傳輸資料。顧名思義，具名管道的工作方式與管道相似：在一端輸入資料，在另一端輸出相同的資料。建立的管道既可以串連本地進程，也可以串連遠端電腦上啟動並執行進程。對於本地進程間通訊，管道是 Windows 中的最有效、最靈活的工具。

　　為確保獲得最優效能，aspnet_isapi 使用非同步具名管道來將請求轉寄給輔助進程並獲得響應。另一方面，輔助進程在需要查詢有關 IIS 環境的資訊（即伺服器變數）時又使用同步管道。aspnet_isapi 模組建立固定數量的具名管道，並使用重疊的操作以通過小的線程池處理同一時間進行的串連。當通過管道進行的資料交換操作結束後，完成常式將斷開用戶端，並重新使用管道執行個體為新的用戶端服務。線程池和重疊操作均可以保證使 ASP.NET ISAPI 的效能達到令人滿意的水平。但是，aspnet_isapi 擴充決不會處理 HTTP 要求。

　　ASP.NET 請求的處理邏輯可以概括為以下步驟：

　　當請求到達時，IIS 檢查資源類型並調用 ASP.NET ISAPI 擴充。如果啟用了預設的進程模型，aspnet_isapi 會將請求排隊，並將請求分配給輔助進程。所有的請求資料都通過非同步 I/O 發送。如果啟用了 IIS 6 進程模型，請求將自動在輔助進程 (w3wp.exe) 中排隊，此輔助進程用於處理應用程式所屬的 IIS 應用程式集區。IIS 6 輔助進程不瞭解 ASP.NET 和Managed 程式碼的任何情況，它只是處理 *.aspx 擴充並載入 aspnet_isapi 模組。當 ASP.NET ISAPI 在 IIS 6 進程模型中運行時，它的工作方式有所不同，僅在 w3wp.exe 輔助進程的上下文中載入 CLR。

　　收到請求後，ASP.NET 輔助進程將通知 ASP.NET ISAPI，它將為請求服務。通知通過同步 I/O 實現。之所以使用同步模型，是因為請求只有在 ISAPI 內部請求表中被標記為“executing”，輔助進程才能開始處理它。如果請求已經由特殊的輔助進程進行處理，則不能再將它指定到其他進程，除非原始進程已取消。
在輔助進程的上下文中執行請求。有時，輔助進程可能需要回調 ISAPI 以完成請求，也就是需要說枚舉伺服器變數。這種情況下，輔助進程將使用同步管道，因為這樣可以保持請求處理邏輯的順序。

　　完成後，響應被發送到開啟了非同步管道的 aspnet_isapi。現在，請求的狀態變為“Done”，之後將從請求表中被刪除。如果輔助進程崩潰，正在處理的所有請求仍將保持“executing”狀態並持續一段時間。如果 aspnet_isapi 檢測到輔助進程已取消，它將自動終止請求並釋放所有相關的 IIS 資源。

　　以上說明是指預設的 ASP.NET 進程模型，即在 IIS 5.x 中啟動並執行工作模型。IIS 6（Windows Server 2003 提供）的預設工作方式對 ASP.NET 進程模型也有影響。當整合在 IIS 6.0 中時，ASP.NET 1.1 會自動調整自己的工作方式以適應宿主環境。這時，不再需要使用 aspnet_wp 輔助進程，machine.config 檔案中定義的某些配置參數也被忽略。從 ASP.NET 的角度來看，IIS 6 的最大改變是有關請求的一切都在 aspnet_isapi 的控制之下，且都處在 w3wp.exe 輔助進程的上下文中。輔助進程的帳戶是為 Web 應用程式所屬的應用程式集區設定的帳戶。預設情況下，該帳戶是 NETWORKSERVICE—，它是一個內建的弱帳戶，在功能上與 ASPNET 等價。

[1] [2] [3] 下一頁