ASP.NET Web Garden模型

Web Garden模型

Web Garden模型可以通過 machine.config 檔案中的 部分進行配置。請注意， 部分是唯一不能放在應用程式特定的 web.config 檔案中的配置部分。這就是說，Web Garden 模式可以應用到計算機中執行的所有應用程式。但通過使用 machine.config 原始檔中的 節點，可以針對各個應用程式調節計算機的設定。

部分有兩個屬性可以影響 Web Garden模型，它們是 Web Garden 和 cpuMask。Web Garden 屬性接受布林值，表示是否使用了多個輔助程式（一個相關的 CPU 對應一個程式）。預設情況下，該屬性的值為 false。cpuMask 屬性儲存一個 DWORD 值，該值的二進位制表示為能夠執行 ASP.NET 輔助程式的 CPU 提供了位遮蔽。其預設值為 -1 (0xFFFFFF)，表示可以使用所有可用的 CPU。如果 Web Garden 屬性為 false，則 cpuMask 屬性的內容將被忽略。cpuMask 屬性還為正在執行的 aspnet_wp.exe 的副本數設定了上限。

常言道“閃光的不都是金子”，用在這裡很合適。Web Garden 模式使得多個輔助程式可以同時執行。但是，需要注意的是所有程式都會有自己的應用程式狀態、程式內會話狀態、ASP.NET 快取、靜態資料以及執行應用程式所需的其他內容。啟用 Web Garden 模式之後，ASP.NET ISAPI 將根據 CPU 的數量儘可能多地啟動輔助程式，每個輔助程式都是下一程式的完整克隆（每一程式都與相應的 CPU 密切相關）。為平衡工作負荷，傳入的請求以單迴圈的方式在執行的程式之間進行劃分。輔助程式就象在單處理器中一樣被回收。請注意，ASP.NET 繼承了作業系統中所有的 CPU 使用限制，並且不包括實現限制的自定義語義。

總之，Web Garden模型並不適用於所有應用程式。應用程式的狀態越多，其的效能損失也越多。工作資料儲存在共享記憶體的塊中，以便一個程式輸入的變化可以立即被其他程式得知。但是，處理請求時，工作資料被複制到程式的上下文中。因此，各個輔助程式將處理自己的工作資料，而應用程式的狀態越多，效能損失就越大。鑑於此，仔細、明智的應用程式基準測試是絕對必要的。

只有重啟 IIS 後，對配置檔案中 部分所做的更改才會生效。在 IIS 6 中，Web Garden 模式的引數儲存在 IIS 配置資料庫中，Web Garden 和 cpuMask 屬性被忽略。
HTTP 管道

ASP.NET ISAPI 擴充套件啟動輔助程式後，它將傳遞部分命令列引數。輔助程式使用這些引數來執行載入 CLR 前需要執行的任務。傳遞的值包括：COM 和 DCOM 安全性所要求的身份驗證等級、可以使用的命名管道的數量和 IIS 程式標識。命名管道的名稱是使用 IIS 程式標識和允許的管道數隨機生成的。輔助程式不接收可用管道的名稱，但可以接收識別管道名稱所需的資訊。

COM 和 DCOM 安全性與 Microsoft® .NET Framework 有何關係？實際上，CLR 是作為 COM 物件提供的。更準確地說，CLR 本身不是由 COM 程式碼構成的，但是指向 CLR 的介面卻是一個 COM 物件。因此，輔助程式載入 CLR 的方式與載入 COM 物件的方式相同。

當 ASPX 請求遇到 IIS 時，Web 伺服器將根據選擇的身份驗證模型（匿名、Windows、Basic 或 Digest）來分配一個令牌。當輔助程式收到要處理的請求時，令牌被傳遞到輔助程式。請求由輔助程式中的執行緒獲取。該執行緒從最初獲取傳入請求的 IIS 執行緒繼承身份令牌。在 aspnet_wp.exe 中，負責處理請求的實際帳戶取決於在特殊的 ASP.NET 應用程式中是如何配置模擬的。如果模擬被禁用（預設設定），則執行緒將在輔助程式的帳戶下執行。預設情況下，該帳戶在 ASP.NET 程式模型中為 ASPNET，在 IIS 6 程式模型中為 NETWORKSERVICE。這兩個帳戶都是“弱”帳戶，提供的功能比較有限，可以有效抵擋回復性攻擊 (Revert-to-self Attack)。（回覆性攻擊是指將模擬的客戶端的安全性令牌回覆到父程式令牌。為輔助程式分配弱帳戶可以挫敗此類攻擊。）

高度概括起來，ASP.NET 輔助程式完成的一項主要任務就是將請求交給一系列稱為的 HTTP 管道的託管物件。要啟用 HTTP 管道，可以建立一個 HttpRuntime 類的新例項，然後呼叫其 ProcessRequest 方法。如前所述，ASP.NET 中始終只執行一個輔助程式（除非啟用了 Web Garden模型），該程式在獨立的 AppDomain 中管理所有的 Web 應用程式。每個 AppDomain 都有自己的 HttpRuntime 類例項，即管道中的輸入點。HttpRuntime 物件初始化一系列有助於實現請求的內部物件。Helper 物件包括快取管理器（Cache 物件）和內部檔案系統監視器（用於檢測構成應用程式的原始檔的更改）。HttpRuntime 為請求建立上下文，並用與請求相關的 HTTP 資訊填充上下文。上下文用 HttpContext 類的例項來表示。

另一個在 HTTP 執行時的設定初期建立的 Helper 物件是文字書寫器，用於包含瀏覽器的響應文字。文字書寫器是 HttpWriter 類的例項，此物件對頁面程式碼以程式設計方式傳送的文字進行快取。HTTP 執行時被初始化後，它將查詢實現請求的應用程式物件。應用程式物件是 HttpApplication 類的例項，該類就是 global.asax 檔案背後的類。global.asax 在程式設計時是可選的，但在構建結構時是必需的。因此，如果應用程式中沒有構建類，則必須使用預設物件。ASP.NET 執行時包括幾個中間工廠類，可以用來查詢並返回有效的 Handler 物件以處理請求。整個過程中用到的第一個工廠類是 HttpApplicationFactory。它的主要任務是使用 URL 資訊來查詢 URL 虛擬目錄和彙集的 HttpApplication 物件之間的匹配關係。

應用程式工廠類的行為可以概括為以下幾點：

1. 工廠類維護 HttpApplication 物件池，並使用它們來處理應用程式的請求。池的壽命與應用程式的壽命相同。
2. 應用程式的第一個請求到達時，工廠類提取有關應用程式型別的資訊（global.asax 類）、設定用於監視更改的檔案、建立應用程式狀態並觸發 Application_OnStart 事件。
3. 工廠類從池中獲取一個 HttpApplication 例項，並將要處理的請求放入例項中。如果沒有可用的物件，則建立一個新的 HttpApplication 物件。要建立 HttpApplication 物件，需要先完成 global.asax 應用程式檔案的編譯。
4. HttpApplication 開始處理請求，並且只能在完成這個請求後才能處理新的請求。如果收到來自同一資源的新請求，則由池中的其他物件來處理。
5. 應用程式物件允許所有註冊的 HTTP 模組對請求進行預處理，並找出最適合處理請求的處理程式型別。這通過查詢請求的 URL 的擴充套件和配置檔案中的資訊來完成。

HTTP 處理程式是一些實現 IHttpHandler 介面的類。.NET Framework 為常見的資源型別提供了一些預定義的處理程式，包括 ASPX 頁面和 Web 服務。machine.config 檔案中的 部分定義了 HttpApplication 物件必須例項化才能處理特定型別資源的請求的類名。如果 Helper 類是一個處理程式工廠，GetHandler 方法將確定要使用的處理程式型別。這時，將從一組類似的物件中獲取適當型別的處理程式，並對其進行配置以處理請求。