为此ASP 的使用者不得不自己手工将会话信息以会话 ID 为主键同步到外部数据库中，以缓解类似问题。

而在 ASP.NET 中，因为设计时就考虑了这些问题，能够避免这些限制：1.支持进程外的状态管理，通过独立状态管理服务或 SQL Server 状态服务器管理会话状态2.支持不使用 Cookie 的状态维护，通过在 URL 中自动增加会话 ID 来避免使用 Cookie 3.通过独立的状态管理服务或SQL Server 状态服务器支持负载均衡时同步使用会话信息实现这些特性的正是上节提到的Session StateModule.InitModuleFromConfig 函数中，根据Session State 标记的 mode 属性选择的四种不同的状态管理器实现。

以下内容为程序代码：

    <system.web>
    <sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1：42424"
    stateNetworkTimeout="10" sqlConnectionString="data source=127.0.0.1；
    Integrated Security=SSPI" cookieless="false" timeout="20" />
    </system.web>

Off模式禁止会话管理，同时 ASP.NET 还允许通过在页面中以 Enable Session State 属性细粒度管理页面的会话支持状态以下内容为程序代码：

    <%@ Page EnableSessionState=" TrueFalseReadOnly" %>

InProc 模式兼容以前 ASP 的策略，在 ASP.NET 同一进程空间内实现基于内存的会话状态管理，速度最快但受到与 ASP 相同的限制；STATE SERVER 模式通过 ASP.NET 独立安装的 ASP.NET State Service 服务（aspnet_state.exe），以 stateConnectionString 指定的IP和端口响应会话状态服务；SQLServer 模式则通过 sqlConnectionString 指定的 SQL Server 服务器，以内存临时表（以 InstallSqlState.sql建库，使用 tempdb 内存数据库）或独立表（以InstallPersistSqlState.sql 监控，使用独立的 ASPState 库）维护会话状态。

这四种不同的状态管理器，在性能上据《Performance Tuning and Optimizing ASP.NET Appliation》一书的测试，相对值如下：以下为引用：Table 4-1： Normalized TTLB（Time to Last Byte） bySession State Mode （in Milliseconds per 100 Requests）

CONCURRENT BROWSERS MODE = OFF MODE = INPROC MODE = STATE SERVER MODE = SQLSERVER 1 7.81 4.54 8.27 8.47 5 28.28 20.25 27.25 29.29 10 89.38 46.08 77.29 85.11 Table 4-2： Average Requests per Second bySession State Mode CONCURRENT BROWSERS MODE = OFF MODE = INPROC MODE = STATE SERVER MODE = SQLSERVER 1 18.86 24.17 18.31 18.11 5 21.66 25.74 21.54 21.34 10 17.23 23.8 18.11 17.6可以看到，无论是从 TTLB 还是每秒平均请求数来说，进程外状态管理器的性能都是可以令人接受的，当然还需要针对状态管理情况在编写代码时做相关优化。不过要使用进程外状态管理器，则保存在会话中的对象受到必须提高二进制序列化支持的限制。

从使用角度来看，状态管理器实际上都是由上节提到的 HttpSessionModule 建立管理，并通过 Http Session State 接口提供访问的，结构如下图：MSDN 上的 Underpinnings of theSession State Implementation in ASP.NET 一文非常详细的解释了几种不同状态管理器的原理和使用，这儿就不罗嗦了。