規劃步驟 2：規劃 ASP.NET 設定

文章
07/19/2023

2.1. 工作階段狀態設定

當用戶端造訪網站時，他們通常會從某一個網頁瀏覽至另一個網頁，且會經常變更他們造訪的部分網頁。如果您要追蹤使用者瀏覽的網頁和他們在造訪您的網站時所做的變更，請設定工作階段狀態。

當您的應用程式已啟用工作階段狀態時，使用者就會在他們第一次從您的 ASP.NET 應用程式要求網頁時收到一個唯一的工作階段識別碼。工作階段狀態資料是以下列其中一種方式儲存在伺服器：

進程內：會話狀態會儲存在執行 ASP.NET 應用程式的背景工作進程中。
狀態伺服器：會話狀態會儲存在執行 ASP.NET 應用程式的背景工作進程之外。
SQL Server：會話狀態會儲存在SQL Server資料庫中。

注意

您也可以設定自訂的 out-of-state 儲存體來儲存工作階段狀態資料。但是，這已經超出此教學課程的範圍。 Visual Studio 11 專案是使用自訂的儲存體來支援 SQL Server、SQL Compact 及 SQL Azure。

工作階段狀態資料也可以儲存在用戶端上的 Cookie 中。 Cookie 是一個文字檔，包含用來儲存使用者相關資訊 (例如使用者喜好設定和使用者驗證資訊) 的資料。

以下各節將更詳細地描述您的工作階段狀態儲存體選項。

在處理序中儲存工作階段狀態
使用狀態伺服器儲存工作階段狀態
使用 SQL Server 儲存工作階段狀態
工作階段狀態的 Cookie 模式

在處理序中儲存工作階段狀態

同處理序工作階段狀態模式會將 ASP.NET 應用程式的工作階段狀態資料儲存在應用程式執行所在的工作者處理序中。此模式是 IIS 8 的預設值。

使用同處理序工作階段狀態的優點是它提供了最快速的工作階段狀態資料存取。但是，當您在工作階段中儲存更多資料時，會消耗更多的記憶體，這可能會降低伺服器效能。

在您設定同處理序工作階段狀態之前，請考量在工作階段狀態資料上使用工作者處理序回收的效果。如果回收工作者處理序，所有工作階段狀態資料都會遺失。如果您的 ASP.NET 應用程式必須保留工作階段狀態資料，而且如果資料存取速度不是您主要的目標，請考慮使用跨處理序工作階段狀態模式來儲存此資料。

重要

必須執行 Windows 狀態服務 (Aspnet_state.exe)，同處理序工作階段狀態才會生效。根據預設，安裝 Windows Server® 2012 並設定為手動啟動時，就會安裝此服務。建議您將此啟動行為變更為「自動」。

根據預設，工作階段會在使用者超過 20 分鐘未於 ASP.NET 應用程式中要求或重新整理網頁時過期。因為工作階段物件會耗用 Web 伺服器上的記憶體，所以請考慮降低逾時值以節約資源。

重要事項：當您調整會話逾時值時請小心，因為當使用者在網站上未使用逾時期間內，儲存在使用者 Session 物件中的資訊會遺失。

如果您決定使用同處理序工作階段狀態儲存體，請同時決定您是否也想要使用 Cookie。如需 Cookie 的詳細資訊，請參閱工作階段狀態的 Cookie 模式。

使用狀態伺服器儲存工作階段狀態

「狀態伺服器」會將工作階段狀態日期保留在工作者處理序外部的記憶體中。這項設定的優點是當應用程式工作者處理序回收時，會保留該工作階段狀態。建議針對中型應用程式使用狀態伺服器。

狀態伺服器與 Windows 狀態服務 (Aspnet_state.exe) 相依，並且需要機器金鑰來跨連線驗證工作階段狀態。

當狀態伺服器在包含伺服器為其維持狀態之應用程式的相同 Web 伺服器上執行時，支援網頁處理序區設定。為了加強工作階段狀態資料的保護能力，請考慮使用含有個別伺服器以儲存工作階段狀態，並在伺服陣列中的所有伺服器之間共用工作階段狀態的 Web 伺服陣列設定。另一種方法是使用 SQL Server 來維護跨處理序工作階段狀態。

重要事項：Windows 狀態服務 (Aspnet_state.exe) 必須執行，才能讓進程內會話狀態生效。根據預設，安裝 Windows Server 2012 並設定為手動啟動時，就會安裝此服務。將啟動行為變更為「自動」。

如果您決定使用狀態伺服器來儲存工作階段狀態，請依照以下方式設計：

定義狀態伺服器的連接字串。
指定連線逾時之前要等待的秒數。
決定是否要啟用壓縮。
決定是否要將任何工作階段狀態資料儲存在 Cookie 中。如需 Cookie 的詳細資訊，請參閱工作階段狀態的 Cookie 模式。

使用 SQL Server 儲存工作階段狀態

跨處理序工作階段狀態的其中一種類型是使用 SQL 伺服器來儲存工作階段狀態資料。這個設定的優點是無論是否回收應用程式工作者處理序，或如果 Windows 狀態服務或 Web 伺服器其中之一當機，都會保留工作階段狀態。

注意

此設定不支援 SQL Azure。

當 SQL Server 在包含 Web 伺服器為其維持狀態之應用程式的相同 Web 伺服器上執行時，它會支援網頁處理序區設定，這可以提高 Web 伺服器延展性。當 SQL Server 在另一部伺服器上執行時，它會支援 Web 伺服陣列設定，這可以大幅度提升伺服器群組的延展性。

重要

必須執行 Windows 狀態服務 (Aspnet_state.exe)，跨處理序工作階段狀態才會生效。根據預設，安裝 Windows Server 2012 並設定為手動啟動時，就會安裝此服務。將啟動行為變更為「自動」。

重要

在您為工作階段狀態設定 SQL Server 之前，請先在伺服器上執行 InstallSqlState.sql 指令碼。根據預設，此腳本會儲存在中 %systemroot%\Microsoft.NET\Framework\V4.0.30319 。

如果您決定將工作階段狀態儲存在 SQL Server 資料庫中，請依照以下方式設計：

定義資料庫的連接字串。
指定連線逾時之前要等待的秒數。
指定嘗試重新連線之前要等待的秒數。
決定是否要啟用自訂資料庫。
決定是否要啟用壓縮。
決定是否要將任何工作階段狀態資料儲存在 Cookie 中。如需 Cookie 的詳細資訊，請參閱工作階段狀態的 Cookie 模式。

其中一種追蹤連線到 Web 伺服器之用戶端的工作階段狀態的方法是使用 Cookie。您可以設定 Web 伺服器使用 Cookie，不使用 Cookie，或依據用來連線的瀏覽器選擇 Cookie 行為。

工作階段 Cookie 會將工作階段資訊與工作階段的用戶端資訊關聯。會話是使用者與網站連線的持續時間。 Cookie 會在 HTTP 標頭中與所有要求一起在用戶端和 Web 伺服器之間傳遞。

使用 Cookie 來追蹤會話狀態比不使用 Cookie 的任何其他方法更有效率，因為 Cookie 不需要任何重新導向。此外，它們允許使用者將網頁加入書籤，而且它們會在使用者離開網站以造訪另一個網站，然後再返回原始網站時保留狀態。使用者 Cookie 的一個缺點是使用者可以停用其瀏覽器中的 Cookie。

使用裝置設定檔Cookie 模式會導致瀏覽器在瀏覽器支援 Cookie 時使用 Cookie;否則，不會使用 Cookie。如果裝置設定檔指示有支援 Cookie，那麼無論使用者是否已經停用 Cookie 支援，都會使用 Cookie。

重要

當您使用「使用裝置設定檔」Cookie 模式時，請設定重新產生過期的工作階段識別碼。這樣做可讓 Web 伺服器過期並重新產生權杖，以縮短潛在攻擊者能夠擷取 Cookie 並取得 Web 伺服器內容存取權的時間。

自動偵測 Cookie 模式可使行動裝置在其設定檔支援 Cookie 時使用 Cookie，否則不會使用 Cookie。對於已知支援 Cookie 的傳統型瀏覽器而言，ASP.NET 會在瀏覽器中已啟用 Cookie 支援時嘗試使用 Cookie。如果停用 Cookie 支援，工作階段狀態就會儲存在 URL 中。

重要

當您使用「自動偵測」Cookie 模式時，請設定重新產生過期的工作階段識別碼。這樣做可讓 Web 伺服器過期並重新產生權杖，以縮短潛在攻擊者能夠擷取 Cookie 並取得 Web 伺服器內容存取權的時間。請考慮將逾時值變更為比 20 分鐘預設值更短的時間。

您可以在不使用 Cookie 的情況下設定工作階段狀態。當您使用統一資源識別項 (URI) 來處理工作階段狀態時，工作階段識別碼會以查詢字串的方式內嵌在 URI 要求中，然後該 URI 會被重新導向到到原先要求的 URL。變更的 URI 要求是用於工作階段的持續時間，因此不需要 Cookie。

重要

當您使用 URI 時，請設定重新產生過期的工作階段識別碼。這樣做可讓 Web 伺服器過期並重新產生權杖，以縮短潛在攻擊者能夠擷取 Cookie 並取得 Web 伺服器內容存取權的時間。

使用 URI 來追蹤工作階段狀態可協助您避免 Cookie 的缺點，包括瀏覽器支援問題以及使用者停用 Cookie 的可能性。但是，使用 URI 有下列缺點：

無法在不遺失工作階段狀態的情況下使用絕對 URL，這表示如果使用者移至另一個應用程式，然後返回前一個應用程式，網頁上將不再存在使用者輸入的內容。
請勿允許使用者將網頁加入書籤，因為工作階段狀態會遺失。

如果您決定使用 Cookie 來儲存工作階段狀態，請依照以下方式設計：

選取 Cookie 模式：自動偵測、使用 Cookie、使用裝置設定檔，或使用 URI。
除非您選擇使用 URI，否則請指定 Cookie 名稱。
除非您選擇使用 URI，否則請指定 Cookie 逾時之前的分鐘數。
除非您選擇使用 Cookie，否則請決定是否要重新產生過期的工作階段識別碼。

2.2. 網頁及控制項設定

ASP.NET 網頁包括 ASP.NET 在網頁執行時辨識及處理的額外元素。 ASP.NET 網頁也可以包含自訂、可重複使用的控制項。這些自訂控制項會在伺服器上處理。這可以讓您使用伺服器程式碼設定 ASP.NET 網頁內容。

注意

這些設定只會套用 ASP.NET Web Forms。它們並不適用於 ASP.NET MVC 或 ASP.NET 網頁。

IIS 8 可讓您設定下列 ASP.NET 網頁和使用者控制項設定：

行為設定：例如，網頁是否會維護其檢視狀態，以及當目前頁面要求結束時，它所包含的任何伺服器控制項的檢視狀態。
一般設定：例如，所有頁面都包含的命名空間。
編譯設定：例如，是否編譯或解譯頁面。
服務：例如，是否啟用會話狀態。

IIS 8 提供 ASP.NET 網頁和控制項的預設設定，但您可以視需要變更這些設定。例如，您可以設定網站的主版頁面檔案，或啟用檢視狀態。

Web 自訂控制項是編譯過的元件，在伺服器上執行，並且可將使用者介面和其他相關功能封裝成可重複使用的套件。在 IIS 8 中，您可以為可在應用程式中多個頁面使用的自訂控制項指定標籤前置詞和命名空間對應。

當您想要為在應用程式內的多個頁面中使用的自訂控制項指定標記首碼/命名空間對應時，請新增自訂控制項。

注意

新增組態設定可將本機層級的設定新增至繼承設定的任何子層級。

如果您決定設定 ASP.NET 自訂控制項，您需要您想要設定之每個控制項的下列資訊：

指定控制項的標記首碼。
指定控制項的 .NET 命名空間。
指定控制項所在的組件。

2.3. 應用程式設定

當您想要將機碼/值組儲存為 Web.config 檔案中設定的一部分時，請設定應用程式設定。應用程式設定提供快速且容易的存取方式來存取您應用程式的預存設定資料。

若要管理自訂控制項，您可以檢視包含特定設定層級之所有自訂控制項的清單。您可以依據標記首碼、來源或組件，或範圍 (本機或繼承) 來排序此清單。您也可以依據範圍來將控制項組成群組，以查看目前的設定層級套用了哪些自訂控制項，以及從父系層級範圍繼承了哪些自訂控制項。

當您想要為在應用程式內的多個頁面中使用的自訂控制項指定標記首碼/命名空間對應時，請新增自訂控制項。

注意

新增組態設定可將本機層級的設定新增至繼承設定的任何子層級。

如果您決定設定應用程式設定，您需要您想要設定之每個設定的下列資訊：

指定設定的名稱。
指定設定的值。

2.4. .NET 編譯設定

若要讓應用程式程式碼為使用者提出的要求提供服務，ASP.NET 必須先將程式碼編譯成一或多個組件。組件是副檔名為 .dll 的檔案。當您想要控制 ASP.NET 程式碼的編譯方式時，請在 IIS 8 中設定 .NET 編譯設定。

IIS 可讓您設定下列 .NET 編譯設定：

批次設定，例如，您可以建立的最大批次檔案大小，以及您在每個批次編譯中可以包含的頁面數目上限。
行為設定，例如，在應用程式重新啟動之前，動態編譯資源的次數。
一般設定，例如動態編譯檔案中使用的預設程式設計語言。

2.5. .NET 全球化設定

全球化是將應用程式程式碼國際化，然後將應用程式當地語系化為其他語言或文化特性的程序。國際化程序讓您能夠使用相同的應用程式程式碼基底，來為任何地區設定翻譯、儲存、擷取及提供應用程式內容 (如果可能的話)。地區設定是語言和文化特性環境的組合。這包括日期格式、時間、貨幣、電話號碼等等。當地語系化表示最好在不影響程式碼的情況下，根據文化特性來翻譯和格式化內容，讓您的應用程式適應其他地區設定。

當您想要將全球化設定套用至伺服器上的所有 ASP.NET 應用程式時，您可以在 Web 伺服器層級變更 ASP.NET 應用程式的全球化設定。您也可以編輯網站、應用程式、目錄和檔案的 ASP.NET 全球化設定。

IIS 可讓您設定下列全球化設定：

文化特性設定，例如 UI 文化特性或 UI 語言。
編碼設定，例如回應標頭的編碼。

注意

編輯組態設定可變更本機層級的設定，以及變更繼承設定之任何子層級的設定。

分享方式：