ASP.NET模塊

.NET Compilation模塊

在為一個請求提供服務之前，ASP.NET首先需要將代碼編譯為合適的程序集。這些程序集文件以.dll作為擴展名。利用IIS 7.0中的ASP.NET模塊，可以控制服務器如何編譯ASP.NET代碼。

.NET Globalization模塊

全球化是指開發人員設置應用程序時，需要讓應用程序能夠在全球化多種語言文化中使用，并且能夠在多個地區運行。通過完成本地化過程，我們可以對全球化應用程序進行定制，確定應用程序運行的具體語言和具體地點。利用全球化過程，我們可以令一個代碼庫適用于多個地區，同時還能夠提供特定地區的語言和文化背景信息。

.NET Trust Levels 模塊

ASP.NET代碼訪問安全（code access security，CAS）策略是通過設置應用程序的信任級別來實現的。CAS可以確定授予服務器中某個應用程序的權限。如果需要部署的代碼獲得了訪問服務器的提升權限，那么如何設置CAS就成了一項非常重要的工作。如果需要部署的代碼修改了服務器的文件系統，那么為了防止錯誤的訪問發生，必須嚴格控制CAS。
CAS具有兩種信任類型：完全信任（full trust）和部分信任（partial trust）如果一個應用程序具有完全信任權限，那么這個應用程序就可以訪問服務器中的所要資源，完成所有操作，在這種情況下，這個應用程序只能由操作系統的安全設置來限制其權限。
在默認設置中，我們可以使用5種不同的信任級別：完全（Full）、高級（High）、中級（Medium）、低級（Low）、最小（Minimal）。

Application Settings模塊

利用Application Settings模塊，可以在web.config文件中保存應用程序的配置數據，數據的保存格式為鍵/值對。這些設置所確定的值在整個應用程序范圍內有效，因此在Web應用程序的任何位置都是有效的。修改配置數據是一項非常簡單的任務，因為這些配置數據都集中保存在配置文件中。
必須牢記：對 .NET 設置進行任何修改都會導致一次 appDomain 回收，因此會影響到整個服務器。

連接字符串

連接字符串可以用來在應用程序和數據庫之間建立通信連接。連接字符串中不但包括服務器、數據庫名、用戶，還包括應用程序與數據庫進行通信時使用的密碼。

計算機密鑰

ASP.NET使用計算機密鑰來保護Forms身份驗證的cookie數據和頁面視圖的狀態數據。計算機密鑰本身是一種散列值，可以用于對cookie數據和頁面視圖狀態數據進行加密。計算機密鑰可以用于在進程之外運行會話。雖然我們可以在服務器級設置計算機密鑰，甚至可以在文件級設置計算機密鑰，但是在默認情況下，計算機密鑰均鎖定在服務器級和網站級。如果一個網站可以運行在多臺Web服務器中，那么這些密鑰便可以在不同的服務器之間共享。

ASP.NET使用了兩類計算機密鑰：驗證密鑰和解密密鑰。驗證密鑰可以用于創建消息驗證代碼（Message Authentication Code，MAC），利用MAC，我們可以驗證數據的完整性。驗證密鑰可以附加到Forms身份驗證cookie之后，也可以附加到視圖狀態數據之后。解密密鑰可以用于對Forms身份驗證票證和視圖狀態數據進行加密和解密。

如果要在多臺服務器上使用驗證密鑰，那么需要創建一個單獨的驗證密鑰，然后在多臺服務器之間共享這個驗證密鑰。如果要在多臺服務器上使用解密密鑰，那么需要創建一個單獨的解密密鑰，然后在多臺服務器之間共享這個解密密鑰。

頁面及控件

ASP.NET能夠識別和處理頁面運行過程中使用的基本元素。ASP.NET還可以支持使用定制的控件，這些定制的控件是可重用的，并且是在服務器方進行處理的。因此，服務器代碼可以用于配置ASP.NET的Web頁面屬性。

Providers模塊

使用.NET Framework創建的ASP.NET和應用程序可以使用數據庫保存信息。為了將應用程序映射到數據庫架構，需要使用一個名為Provider的軟件模塊。對于應用程序和數據庫來說，Provider軟件模塊等價于硬件抽象層。通過使用Provider模塊，IIS 7.0可以安裝定制的數據庫訪問模塊，也支持修改標準的ASP.NET數據庫訪問模塊。可以使用3種不同的數據庫訪問角色：.NET Roles、.NET Users、.NET Profile。
.NET Roles角色的數據庫提供程序可以創建授權存儲、SQL角色以及Windows令牌提供程序類型。.NET Users數據庫提供程序可以用于創建Active Directory成員類型，還可以用于創建SQL成員資格提供程序類型。.NET Profile 可以用于創建SQL配置文件提供程序。

會話狀態

IIS 7.0使用會話狀態來跟蹤用戶訪問網站過程中所瀏覽的頁面，通過為每個用戶創建一個會話ID，IIS可以區分相關用戶。HTTP是一種無狀態協議，因此，服務器不需要保存以前為請求提供服務過程中使用的變量的信息。IIS 7.0可以使用ASP.NET會話狀態保存數據和提取數據，這樣可以為在Web網站中漫游的用戶提供一些信息。
模式
我們可以使用以下5種模式設置會話狀態：

（1）Not Enabled模式

在該模式下，Web網站沒有使用會話狀態。

（2）In Process模式

在該模式下，內存中的會話狀態是與應用程序的工作進程綁定的，In Process模式也是IIS 7.0的默認模式。在系統為會話狀態提供響應時，這種模式下系統的響應速度最快。然而使用In Process會話狀態的缺點是會話中需要保存比較多的數據，因此需要消耗比較多的內存，最終可能會導致服務器性能下降。
如果在In Process模式下保存會話狀態，那么必須牢記：當回收工作進程時，保存在內存中的所有數據都將丟失。如果應用程序需要繼續使用會話狀態數據，那么就必須使用其他的會話狀態模式。
IIS 7.0安裝了Aspnet_state.exe服務。在默認情況下，該服務沒有運行。如果需要在In Process模式下保存會話狀態，那么就必須運行Aspnet_state.exe服務。

（3）Custom模式

使用Custom模式保存會話狀態時，進程外會話可以使用一個自定義的處理程序來創建一個與數據庫的連接。使用自定義的處理程序時，會話狀態可以保存在MS SQL之外的數據庫中，如Oracle或Access。此時還可以使用一個不是由.NET Framework提供的數據庫架構來管理會話狀態。為了使用自定義的處理程序，必須在<sessionState> /<providers>集合中實現一個完整的會話狀態提供程序。

（4）State Server模式

第二種在進程外保存會話狀態的方法是使用State Server模式。在State Server模式中，我們既可以令狀態服務進程運行于同一臺服務器上，也可以令狀態服務進程運行于一個外部服務器中。以State Server模式維護數據時，需要一個單獨的工作進程，這個工作進程與ASP.NET應用程序運行的工作進程是分離的。
如果狀態服務程序與Web網站運行于同一臺服務器上，那么Web網站可以支持運行Web garden。如果Web網站運行于多臺服務器上，那么必須指定一臺服務器運行狀態服務程序，這臺服務器可以共享所有Web服務器的狀態數據。
與In Process模式類似，State Server模式也需要使用Aspnet_state.exe服務。

（5）SQL Server模式

最后一種保存會話狀態的模式是SQL Server模式，這種模式需要使用SQL Server數據庫。SQL Server模式與State Server模式類似：可以與Web服務器運行于同一臺服務器上，此時這臺服務器可以支持一個Web garden；也可以運行于一個外部服務器上，此時這臺服務器可以支持一個Web Farm。優勢：即使工作進程被回收，會話數據仍然存在。
為了使用SQL Server模式保存會話狀態數據，我們同樣需要令Aspnet_state.exe服務自動啟動運行。此外，SQL Server模式還需要運行InstallSqlState.sql腳本來配置會話狀態。該腳本保存在C:\Windows\Microsoft.NET\Framework\v2.0.50727目錄下。

與cookie有關的設置

Cookie是保存了用戶信息的文本文件，這些用戶信息包括身份驗證信息，還記錄了用戶瀏覽網站的偏好。跟蹤會話狀態的方法之一就是使用cookie。Cookie都保存在客戶的計算機中，由Web服務器使用。當客戶向服務器發出請求時，cookie將被放在HTTP頭中，隨請求一同發給服務器。
我們可以將cookies設置為使用以下4種模式之一：

（1）Auto Detect模式
如果瀏覽器支持cookie，那么Auto Detect模式將啟用cookie。如果一臺移動設備連接到了Web服務器，同時這臺移動設備禁用了cookie，那么就無法使用cookie。如果某臺臺式計算機或筆記本計算機連接到了Web服務器，同時這臺臺式計算機或筆記本計算機禁用了cookie，那么會話狀態將保存在URL中。
如果使用了Auto Detect模式，那么需要將會話ID設置為可重新生成的。這樣，***者就不會有充分的時間來獲取cookie，也不會有充足的時間利用cookie來***Web服務器并非法獲取服務器中的內容。Cookie的默認存活時間是20min，可以修改這個時間屬性，使cookie的默認存活時間減少到一個安全水平。

（2）Use Cookies模式
如果使用Use Cookies模式，那么，可以在會話過程中利用會話cookie，從而把會話信息和用戶信息關聯起來。

（3）Use Device Profile模式
如果客戶瀏覽器支持使用cookie，那么Use Device Profile模式可以用cookie保存會話狀態。如果客戶不瀏覽器支持使用cookie，那么該模式無法使用cookie。如果設備支持使用cookie，那么無論用戶怎樣設置cookie，會話狀態仍然將使用cookie。
會話ID應該設置為可重新生成的，其原因與Auto Detect模式相同。

（4）Use URI模式
用過使用URI（Uniform Resource Identifier，統一資源標識符）保存會話狀態，可以將會話ID作為一個查詢字符串，嵌入到URI中。URI隨即被重定向到原先的URL。在整個會話過程中都需要使用上述URI。
盡管Use URI模式消除了cookie存在的缺陷，但是Use URI模式仍然具有自身的缺陷。Web頁面是不能加入書簽的，而且，在不丟失會話狀態的情況下，我們無法使用絕對URL。