您现在的位置： 
HTTP是一种无状态协议。当客户机向服务器发送一个请求时，服务器并不知道这是客户机的第1个还是第42个请求。这对ASP开发来说无异带来了比较严重的问题，因为经常有必要给特定的客户机关联服务器方变量。比方说，网站在向我发送我订购的Jethro Tull CD同时向其他人发送Barry Manilow CD就是因为这一关联的重要作用。ASP通过称为会话ID的唯一的客户标识符处理这种关联关系，当客户在开始他或她的浏览器会话时就会被分配这种会话ID。
现在让我们看看传统的ASP和现代的ASP.NET围绕会话ID的使用而存在的一些问题。然后，我们讨论下运行多个Web服务器时的会话问题。
什么是会话ID
会话ID是一种唯一标识当前访问服务器的客户的只读值。在经典的ASP环境下，会话ID是按照顺序方式被分配的，也就是说，会话ID 706616433之后跟着会话 ID 706616434等等。传统的ASP会话ID以加密的、非持久存在的cookie形式保存在客户机上。例如，会话ID 706616434就可能作为cookie ASPSESSIONIDGQQGQGCS=JHMBOBKCBINEHLPKJHOPABBE保存在客户机上。
ASP.NET下的会话ID有所变化。在使用 ASP.NET 时，会话ID是由URL合法ASCII字符组成的一个120位字符串。根据微软文档的说明，产生会话 ID 值采用了保证其唯一性的算法，从而避免出现两个客户试图采用同一ID时出现的会话冲突。另外，会话ID的随机性使得确定现有会话的ID变得非常困难从而带来了额外的安全性。同传统ASP一样，ASP.NET的会话ID通常也作为非持久保存的cookie存储在客户机上。这种cookie的格式同传统ASP相比稍有变化，例如，asp.net_sessionid=jhmbobkcbinehlpkjhopabbe。
除了维持状态的传统型的、非持久保存的cookie的方法之外，ASP.NET还支持一种不采用cookie的会话状态维持模式。在启用无cookie模式的情况下，ASP.NET在发送回客户机的URL中嵌入会话ID。这样就为使用不支持cookie或禁用cookie浏览器的客户提供了会话状态坚持。考虑到利用cookie跟踪客户信息的举动，我们有理由对无Cookie模式保持高度的关注。
如何使用会话ID
客户每发出一个请求，包含加密会话ID的cookie在存在的情况下即被发送给服务器。服务器随后确定cookie所关联的会话ID并恢复关联该客户的所有会话变量。如果cookie不存在就会生成一个新的会话ID，同时加密的会话ID cookie则被发送给客户机。这样就能让ASP跟踪访问网站的单个客户了。同时，以上机制还促使ASP建立服务器方会话变量同单一会话的关联关系。会话变量则被划分为两种类型：
内容集合
静态对象（StaticObject）集合
ASP和ASP.NET下的内容集合（Contents Collection）会话变量都根据会话ID关联特定的客户。这些变量其实就是一个联合数组，类似于Visual Basic的集合（Collection）对象。会话变量的原理完全一样；唯一的本质差别是它们同一个特定会话相联系。而集合对象则可以通过唯一键保存和检索任何类型的数组成员。
静态对象（StaticObject）集合包含了会话范围内、用GLOBAL.ASA的<OBJECT>标签添加到应用程序中所有对象。同内容集合一样，StaticObject集合也是一个联合数组，其访问方式也相同。不过，StaticObject集合仅仅包含了用<OBJECT>实例化的对象而并不包含那些用Server.CreateObject方法实例化的对象。
一个客户就只有一个会话ID吗
对单一Web服务器而言，维护状态在任何情况下都是自动的。客户能得到而且只能得到唯一的一个会话ID，而且，只要网站上客户保持在活动状态，会话信息就会受到服务器的维持。然而，如果Web服务器超过一个，或者单独的应用程序位于某一虚拟目录下而该目录又驻留在其他应用程序的虚拟目录下时，维持状态就变得更复杂了。
在分配会话ID时，每个服务器都是独立进行操作的。因为这一缘故，Web服务器A就并不知道Web服务器B已经把会话ID 706616434分配给了某一客户。因此，如果Web服务器A收到具有会话ID 706616434的客户请求，这一请求会被当作会话超时进行处理，Web服务器A随即分配一个新的会话ID。在发生这种情况时，客户在Web服务器B上就失去了自己的状态，而且在可能发生重复操作的情况下必须从头开始。避免出现这一问题方法之一就是保证客户的所有请求都被发送给了同一服务器。
在虚拟目录下运行应用程序是实现同一Web服务器上隔离运行多个应用程序的方法之一。但是你得记住，当某一个应用程序调用另一应用程序时就会产生新的会话ID。这样就会丢弃第1个会话 ID及其关联存储的所有会话变量。取决于应用程序的具体情况，状态的丢失可能并不成为问题，但在调试会话时对此问题必须有足够的认识。
小结
ASP足以应对创建持久的Web应用程序所面临的最大挑战??维护状态。ASP的状态维护机制令开发者无须创造自己专有的状态维护机制就能开发出满意的应用程序。使用ASP、事先周密计划再加上努力的工作就可能创建出稳固的持久性应用程序。
现在让我们看看传统的ASP和现代的ASP.NET围绕会话ID的使用而存在的一些问题。然后，我们讨论下运行多个Web服务器时的会话问题。
什么是会话ID
会话ID是一种唯一标识当前访问服务器的客户的只读值。在经典的ASP环境下，会话ID是按照顺序方式被分配的，也就是说，会话ID 706616433之后跟着会话 ID 706616434等等。传统的ASP会话ID以加密的、非持久存在的cookie形式保存在客户机上。例如，会话ID 706616434就可能作为cookie ASPSESSIONIDGQQGQGCS=JHMBOBKCBINEHLPKJHOPABBE保存在客户机上。
ASP.NET下的会话ID有所变化。在使用 ASP.NET 时，会话ID是由URL合法ASCII字符组成的一个120位字符串。根据微软文档的说明，产生会话 ID 值采用了保证其唯一性的算法，从而避免出现两个客户试图采用同一ID时出现的会话冲突。另外，会话ID的随机性使得确定现有会话的ID变得非常困难从而带来了额外的安全性。同传统ASP一样，ASP.NET的会话ID通常也作为非持久保存的cookie存储在客户机上。这种cookie的格式同传统ASP相比稍有变化，例如，asp.net_sessionid=jhmbobkcbinehlpkjhopabbe。
除了维持状态的传统型的、非持久保存的cookie的方法之外，ASP.NET还支持一种不采用cookie的会话状态维持模式。在启用无cookie模式的情况下，ASP.NET在发送回客户机的URL中嵌入会话ID。这样就为使用不支持cookie或禁用cookie浏览器的客户提供了会话状态坚持。考虑到利用cookie跟踪客户信息的举动，我们有理由对无Cookie模式保持高度的关注。
如何使用会话ID
客户每发出一个请求，包含加密会话ID的cookie在存在的情况下即被发送给服务器。服务器随后确定cookie所关联的会话ID并恢复关联该客户的所有会话变量。如果cookie不存在就会生成一个新的会话ID，同时加密的会话ID cookie则被发送给客户机。这样就能让ASP跟踪访问网站的单个客户了。同时，以上机制还促使ASP建立服务器方会话变量同单一会话的关联关系。会话变量则被划分为两种类型：
内容集合
静态对象（StaticObject）集合
ASP和ASP.NET下的内容集合（Contents Collection）会话变量都根据会话ID关联特定的客户。这些变量其实就是一个联合数组，类似于Visual Basic的集合（Collection）对象。会话变量的原理完全一样；唯一的本质差别是它们同一个特定会话相联系。而集合对象则可以通过唯一键保存和检索任何类型的数组成员。
静态对象（StaticObject）集合包含了会话范围内、用GLOBAL.ASA的<OBJECT>标签添加到应用程序中所有对象。同内容集合一样，StaticObject集合也是一个联合数组，其访问方式也相同。不过，StaticObject集合仅仅包含了用<OBJECT>实例化的对象而并不包含那些用Server.CreateObject方法实例化的对象。
一个客户就只有一个会话ID吗
对单一Web服务器而言，维护状态在任何情况下都是自动的。客户能得到而且只能得到唯一的一个会话ID，而且，只要网站上客户保持在活动状态，会话信息就会受到服务器的维持。然而，如果Web服务器超过一个，或者单独的应用程序位于某一虚拟目录下而该目录又驻留在其他应用程序的虚拟目录下时，维持状态就变得更复杂了。
在分配会话ID时，每个服务器都是独立进行操作的。因为这一缘故，Web服务器A就并不知道Web服务器B已经把会话ID 706616434分配给了某一客户。因此，如果Web服务器A收到具有会话ID 706616434的客户请求，这一请求会被当作会话超时进行处理，Web服务器A随即分配一个新的会话ID。在发生这种情况时，客户在Web服务器B上就失去了自己的状态，而且在可能发生重复操作的情况下必须从头开始。避免出现这一问题方法之一就是保证客户的所有请求都被发送给了同一服务器。
在虚拟目录下运行应用程序是实现同一Web服务器上隔离运行多个应用程序的方法之一。但是你得记住，当某一个应用程序调用另一应用程序时就会产生新的会话ID。这样就会丢弃第1个会话 ID及其关联存储的所有会话变量。取决于应用程序的具体情况，状态的丢失可能并不成为问题，但在调试会话时对此问题必须有足够的认识。
小结
ASP足以应对创建持久的Web应用程序所面临的最大挑战??维护状态。ASP的状态维护机制令开发者无须创造自己专有的状态维护机制就能开发出满意的应用程序。使用ASP、事先周密计划再加上努力的工作就可能创建出稳固的持久性应用程序。
