通过

规划步骤 2：规划 ASP.NET 设置

  • 项目

作者：Keith Newman 和 Robert McMurray

2.1. 会话状态设置

在客户端访问站点时，它们通常会从一个页面转到另一个页面，并经常会更改它们访问的某些页面。 如果要跟踪用户在访问你的网站期间浏览的页面及其所做的更改，请配置会话状态。

在为应用程序启用会话状态后，用户会在首次从你的 ASP.NET 应用程序中请求网页时收到一个唯一的会话 ID。 会话状态数据采用以下方式之一存储在服务器上：

  • 进程内：会话状态存储在运行 ASP.NET 应用程序的工作进程内。
  • 状态服务器：会话状态存储在运行 ASP.NET 应用程序的工作进程外。
  • SQL Server：会话状态存储在 SQL Server 数据库中。

注意

你还可以为会话状态数据配置自定义状态外存储。 但是，它超出了本教程的范围。 Visual Studio 11 项目使用自定义存储来支持 SQL Server、SQL Compact 和 SQL Azure。

会话状态数据也可以存储在客户端的 Cookie 中。 Cookie 是一个文本文件，其中包含用于存储有关用户信息的数据，例如用户首选项和用户身份验证信息。

以下部分详细介绍了会话状态存储选项。

在进程内存储会话状态

在进程内会话状态模式下，ASP.NET 应用程序的会话状态数据存储在应用程序运行所在的工作进程中。 此模式是 IIS 8 的默认模式。

使用进程内会话状态的优点在于，你能够以最快的速度访问会话状态数据。 但是，随着在会话中存储的数据越来越多，将会占用更多的内存，进而降低服务器的性能。

在配置进程内会话状态之前，考虑工作进程回收对会话状态数据的影响。 如果回收工作进程，所有会话状态数据都将丢失。 如果 ASP.NET 应用程序必须保留会话状态数据，而数据访问速度并不是你寻求的主要目标，则可以考虑使用进程外会话状态模式来存储该数据。

重要

Windows 状态服务 (Aspnet_state.exe) 必须处于运行状态，才能使进程内会话状态生效。 默认情况下，在安装 Windows Server® 2012 并将其配置为手动启动时，将安装该服务。 建议将启动行为更改为“自动”。

默认情况下，如果用户在 20 分钟内未请求或刷新 ASP.NET 应用程序中的页面，该会话将过期。 由于 Session 对象会占用 Web 服务器上的内存，请考虑减小该超时值来保留资源。

重要提示：调整会话超时值时应十分谨慎，因为如果用户在超时期过后在网站上仍处于不活动状态，用户的 Session 对象中存储的信息将丢失。

如果你决定使用进程内会话状态存储，则还要决定是否要使用 Cookie。 有关 Cookie 的详细信息，请参阅会话状态的 Cookie 模式。

使用状态服务器存储会话状态

状态服务器在工作进程外的内存中维护会话状态日期。 此配置的优点是在应用程序的工作进程回收时保留会话状态。 建议对中型应用程序使用状态服务器。

状态服务器依赖于 Windows 状态服务 (Aspnet_state.exe)，并需要使用计算机密钥来验证连接上的会话状态。

当状态服务器与它要维护其状态的应用程序运行在同一台 Web 服务器上时，将支持 Web 园配置。 为增强对会话状态数据的保护，请考虑使用 Web 场配置，同时使用单独的服务器存储会话状态并在场中的所有服务器上共享该信息。 另一种方法是使用 SQL Server 维护进程外会话状态。

重要提示：Windows 状态服务 (Aspnet_state.exe) 必须处于运行状态，才能使进程内会话状态生效。 默认情况下，在安装 Windows Server 2012 并将其配置为手动启动时，将安装该服务。 将启动行为更改为“自动”。

如果你决定使用状态服务器存储会话状态，请作出以下设计决策：

  • 为状态服务器定义连接字符串。
  • 指定在连接超时前等待的秒数。
  • 决定是否启用压缩。
  • 决定是否将任何会话状态数据存储在 Cookie 中。 有关 Cookie 的详细信息，请参阅会话状态的 Cookie 模式。

使用 SQL Server 存储会话状态

有一种进程外会话状态使用 SQL Server 存储会话状态数据。 这种配置的优点在于：无论是否回收应用程序的工作进程，也不论 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 模式。

可以通过使用 Cookie 来跟踪连接到 Web 服务器的客户端的会话状态。 可以将 Web 服务器配置为使用 Cookie、不使用 Cookie 或根据用于连接的浏览器选择 Cookie 行为。

会话 Cookie 将会话信息与会话的客户端信息关联。 会话是用户连接到站点的持续时间。 Cookie（包含在 HTTP 头中）会随同所有请求一起在客户端与 Web 服务器之间传递。

使用 Cookie 跟踪会话状态比其他任何不使用 Cookie 的方法都高效，因为 Cookie 不要求重定向。 此外，Cookie 还允许用户制作网页书签。当用户离开一个站点而访问另一个站点，然后又回到原来的站点时，Cookie 还能保留该用户的状态。 用户 Cookie 的一个缺点是用户可以在他们的浏览器中禁用 Cookie。

采用“使用设备配置文件”Cookie 模式时，如果浏览器支持 Cookie，则会使用 Cookie；否则，不使用 Cookie。 如果设备配置文件指示支持 Cookie，则会使用它们，而不管用户是否禁用了 Cookie 支持。

重要

当使用“使用设备配置文件”Cookie 模式时，设置重新生成过期的会话 ID。 这样做会使 Web 服务器废弃原有的令牌而重新生成令牌，从而使得留给可能的攻击者捕获 Cookie 并访问 Web 服务器内容的时间减少。

在“自动检测”Cookie 模式下，如果移动设备配置文件支持 Cookie，则使用 Cookie；否则，不使用 Cookie。 对于已知支持 Cookie 的桌面浏览器，当在其中启用 Cookie 支持时，ASP.NET 将尝试使用 Cookie。 如果禁用 Cookie 支持，会话状态将存储在 URL 中。

重要

当使用“自动检测”Cookie 模式时，设置重新生成过期的会话 ID。 这样做会使 Web 服务器废弃原有的令牌并重新生成令牌，从而使得留给可能的攻击者捕获 Cookie 并访问 Web 服务器内容的时间减少。 考虑将超时值更改为小于默认的 20 分钟。

你可以不使用 Cookie 来配置会话状态。 当你使用统一资源标识符 (URI) 来处理会话状态时，会话 ID 将作为查询字符串嵌入在 URI 请求中，然后该 URI 将重定向到最初请求的 URL。 在整个会话持续期间会使用更改后的 URI 请求，因此不需要任何 Cookie。

重要

使用 URI 时，设置重新生成过期的会话 ID。 这样做会使 Web 服务器废弃原有的令牌并重新生成令牌，从而使得留给可能的攻击者捕获 Cookie 并访问 Web 服务器内容的时间减少。

使用 URI 跟踪会话状态可以帮助你避免 Cookie 带来的不足，包括浏览器支持问题以及用户禁用 Cookie 的可能性。 但是，使用 URI 存在以下缺点：

  • 使用绝对 URL 时不能确保不丢失会话状态，也就是说，如果用户转到其他应用程序，然后再回到之前的应用程序，则相应页面上将不再存在该用户的输入。
  • 不允许用户在网页上添加书签，因为会话状态已丢失。

如果你决定使用 Cookie 存储会话状态，请作出以下设计决策：

  • 选择 Cookie 模式：自动检测、使用 Cookie、使用设备配置文件或使用 URI。
  • 除非你已选择使用 URI，否则应指定 Cookie 的名称。
  • 除非你已选择使用 URI，否则应指定 Cookie 超时前等待的分钟数。
  • 除非你已选择使用 Cookie，否则应决定是否要重新生成过期的会话 ID。

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 文件中，你可以配置应用程序设置。 应用程序设置提供了一种快速而简便的方式来访问存储的应用程序配置数据。

若要管理自定义控件，可以查看包含特定配置级别的所有自定义控件的列表。 可以按标记前缀、源或程序集或者按范围（本地或继承）对此列表进行排序。 还可以按范围对控件进行分组，以便查看哪些自定义控件适用于当前配置级别，以及哪些自定义控件是从父级继承而来的。

如果要为将用在应用程序多个页面上的自定义控件指定标记前缀/命名空间映射，则需要添加该自定义控件。

注意

添加配置设置时，将在本地级别以及继承该设置的所有子级别上添加该设置。

如果决定配置应用程序设置，对于要配置的每个设置都需要提供以下信息：

  1. 为设置指定名称。
  2. 为设置指定值。

2.4。 .NET 编译设置

若要使应用程序代码能够为用户请求提供服务，必须先用 ASP.NET 将该代码编译为一个或多个程序集。 程序集是扩展名为 .dll 的文件。 如果要控制 ASP.NET 代码的编译方式，则需要在 IIS 8 中配置 .NET 编译设置。

IIS 允许你配置以下 .NET 编译设置：

  • 批处理设置，例如可以批处理的最大文件大小以及每次批处理编译可以处理的最大页数。
  • 行为设置，例如重新启动编译之前动态编译资源的次数。
  • 常规设置，例如动态编译文件中使用的默认编程语言。

2.5。 .NET 全球化设置

全球化是对应用程序代码进行国际化，然后将该应用程序本地化为其他语言和文化的过程。 国际化过程使你可以尽量使用同一个应用程序代码库来针对任何区域设置翻译、存储、检索和显示应用程序内容。 区域设置是语言和文化环境的组合。 此组合包括日期格式、时间、货币和电话号码等。 本地化即在尽量不触及代码的情况下，根据区域性来翻译内容并调整内容格式，从而使应用程序适应其他区域设置。

如果你要向服务器上的所有 ASP.NET 应用程序应用 ASP.NET 应用程序的全球化设置，可以在 Web 服务器级别上对其加以更改。 还可以编辑站点、应用程序、目录和文件的 ASP.NET 全球化设置。

IIS 允许你配置以下全球化设置：

  • 区域性设置，例如 UI 区域性或 UI 语言。
  • 编码设置，例如响应头的编码。

注意

编辑配置设置时，将更改本地级别以及继承该设置的所有子级别上的设置。