不管使用哪種底層平臺，可靠性和性能都是對所有 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，未集成托管代碼。它是接收和分派對各種 asp.net 資源的請求的控制中心。按照設計，該模塊存在于 iis 進程中，在具有管理員權限的 system 帳戶下運行。開發人員和系統管理員不能修改此帳戶。asp.net isapi 擴展負責調用 asp.net 輔助進程 (aspnet_wp.exe)，而該進程又負責控制請求的執行。除了對請求進行安排以外，asp.net isapi 還監視輔助進程的運行情況，并在性能降低到一定程度時將進程取消。

　　輔助進程是一小段 win32 shell 代碼，集成了公共語言運行庫 (clr) 并運行托管代碼。它負責處理對 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 和托管代碼的任何情況，它只是處理 *.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 等價。