下面来详细说明：


timeout：指定了活动结束后会话的生存期（以分钟计算）。如果用户在一段指定的时间内没有被激活，就会有一个新的会话被创建，而先前的状态将全部丢失。
cookieless：在默认状态下，所生成的会话ID被存储在一个cookie中，稍后，这个cookie会在其他请求中被ASP.NET读取，以便对会话状态进行判断，从而连接到当前用户。
如果有些用户禁用了浏览器中的cookie，我们就可以通过cookieless为这些用户起用会话状态。当设置为true时，ASP.NET会自动把会话ID追加到URL，以及存在于被请求页面中的任何相关的URL。

没有启用，设置为false
启用，设置为true


这个机制会增加一个处理步骤，因为页面中所有的链接都必须进行重写才能包含这个会话ID，以后所请求的URL必须经过解析才能提取它并获取实际的资源URL（没有会话ID）。
mode：状态模式。

InProc——这是一个默认设置。所有的状态都保存在运行应用程序的同一个进程的内存中。这样能够使性能达到最优，但是如果应用程序被重启，或者进程由于某种原因而被挂起，那么相关用户的所有会话数据都将丢失。

StateServer——可以利用这个设置从运行应用程序的进程中分离出状态存储器。它可以联合下面两个属性：
stateConnectionString="tcpip=server:port" stateNetworkTimeout="for network operations with State Server,in seconds"

可以通过指定机器的地址和端口，把状态信息保存到它自己的进程和内存中。这样可以把状态从应用程序中隔离出来，防止它出现故障。在状态服务器及其中，必须启动ASP.NET状态服务，这项服务的启动既可以通过Serivces控制台完成，也可以通过下面的命令提示完成：

>net start aspnet_state

还可以把这项服务设置为自动启动。通过设置好状态服务器的IP地址，就可以把相应的机器指定为保存应用程序的状态信息。这样可以防止应用程序服务器重启，但是却不能防止机器重新启动。还需要注意的是，把状态存储器放在应用进程外面会产生性能冲突，特别是当应用程序位于网络中的另一台机器上时。一定要弄清楚保留会话信息所引起的冲突是否是正常的。

SQLServer——如果决定不惜任何代价保留会话状态，就可以利用这个设置。这个模式可以把所有会话状态保存在SQL Server数据库中，因此它可以经受应用程序、服务器、甚至数据库服务器（假设数据库本身无故障）的任何失败操作。对这个模式进行设置其实就是对sessionState元素的以下属性进行配置：

sqlConnectionString="valid SqlConnection string,minus Initial Catalog"
还必须运行一个脚本，准备存储状态所需的数据库。脚本在D:\WINDOWS\Microsoft.NET\Framework\v1.1.4322路径下的installsqlstate.sql文件

运行这个脚本不需要使用SQL Server 2000 Query Analyzer（查询分析器）。MSDE为我们提供了一个命令行实用程序：osql。
>osql –S [servername] –U [login] –P [pwd] < InstallSqlState.sql
为了获取最大的可靠性，我们甚至可以对SQL Server进行分组。这种模式是保护会话状态的最有力的方法，不过从性能上而言，这种模式也是最为昂贵的。每个请求都需要在数据库之间进行往返，这会严重影响应用程序进行响应。同时，利用网络进行处理也会由于高负荷而产生瓶颈问题。