第1个回答 2013-09-17
一个术语届
在我的经验，会话字可能是仅次于滥用交易的程度，更有趣的是，在某些意义上是相同的会话的事务上下文。
会话，中文经常翻译成一个会话，其本义是指有始有终的一系列动作/消息，比如拿起电话拨打一个电话挂断时要调用的在中间的一系列的流程，可以称为会话。有时候，我们可以看到的话“在一个浏览器会话中，...”，其中的谈话是其本义使用的术语，是衡量一个浏览器窗口打开到关闭这个期间，E。最令人困惑的是“用户（客户端）在会话过程中，”的话，它可能指用户的一系列动作（正常情况下是与一系列具体行动的目的，如购买商品登录这样的网上购物结帐注销过程中，有时简称为交易），但有时也可能仅仅是指一个连接，有可能是指的意思，E，差异只能靠上下文来推断，E° 。
但是，当会话词是与网络协议，它也往往意味着“面向连接”和/或“持有”，这两个含义，“面向连接”指的是通信双方在通信之前，先来建立沟通的渠道，如电话，直到对方接到一个电话通信才能开始，与此相对的是一个字母，把信送给你，当你不能确认地址是否正确的对方，可能无法建立沟通渠道，但发件人，通信已经开始了。 “保留”是指党能够沟通了一系列的消息关联的消息之间可以互相依赖，例如，一个服务员可以识别老客户前来再次记得上一次的客户还欠一块钱存储。 “一个TCP会话”或“POP3会话”，E￠这种类型的例子。
到web服务器蓬勃发展的时代，会话上下文中的语义Web开发有一个新的扩展，它的含义是指用来保持溶液状态的客户端和服务器之间的一类，E￡ 。有时会话也用来指到该溶液中的存储结构，如“储存在一个会话中，其中xxx”，§。由于给各种语言的Web开发在一定程度上提供了这种解决方案的支持，所以在一个特定的语言的上下文中，会话也被用来指语言解决方案，如定期提供在Java javax.servlet.http.HttpSession称为会话，E。
鉴于这种混乱已不可改变的，这在会话中使用的术语将根据上下文有不同的含义，请注意区分。
在本文中，使用中国的“浏览器会话”表达的意思，E，使用“session机制”，要表达的意思，英镑，使用“会话”表达的意思，E“，使用特定的“的HttpSession的”要表达的意思，E
二，HTTP协议和国家仍然
HTTP协议本身是无状态的HTTP协议，它与原来的目的是一致的，客户端只需要一个简单的请求到服务器下载某些文件，无论是客户端或服务器记录彼此的行为，在过去是没有必要的，每次请求之间是独立的，像一个客户和一个自动售货机或正常（非成员），如超市之间的关系。
但是，聪明的（或贪婪？），人们很快发现，如果我们能够提供一些需求的网页上生成的动态信息将变得更加有用，像有线电视加上点播功能相同。这种需求一方面迫使逐步添加HTML表单，脚本，DOM和其他客户端的行为，其他服务器侧出现了CGI规范的动态响应客户端的请求，作为传输载体的HTTP协议也添加一个文件上传，这些功能的cookie。 Cookie是解决无状态的HTTP协议中的缺陷的努力的作用。至于后来出现的会话机制又是一个客户端和服务器之间保持状态的解决方案。
让我们来看看几个例子来说明会话cookie和机制之间的差异和相似之处。我曾经常去的一家咖啡店，免费赠品喝五杯咖啡，一杯咖啡的优惠，然而，消费5杯咖啡的机会不大，那么你需要一些方式来记录消费一定数量的客户。试想一下，其实没什么低于以下几种选择：
1，店员是非常强大的，能够记住每个顾客的消费，只要顾客一走进咖啡店，店员会知道如何对待。支持这种做法的协议本身规定。
2，给客户一张卡，记录消费金额，是一个普遍的有效性。每一个消费者，如果顾客出示这张卡，你将之前或之后与消费者的消费联系在一起。这种方法是在客户端保持状态。
3，给顾客一张会员卡，除了卡号信息没有记录超出每个消费者，如果客户生产出的卡，然后店员在店里找到相应的卡号记录记录添加一些消费者信息。这种做法是在服务器端保持状态。
由于HTTP协议是无状态的，但出于种种考虑不想成为一个国家，因此，后两种方案已成为一个现实的选择。具体而言，cookie机制用于保持状态的客户端程序，并且会话的机制是用来保持的状态的服务器端解决方案。我们也看到，利用服务器端程序在客户端保持状态也需要保存一个标识，所以会话cookie机制可能需要的帮助机制，以实现节能的目的确定，但实际上它还有其他选项。
三，理解cookie机制
的cookie机制的基本原理是一样的，在上面的例子很简单，但有几个问题要解决：“会员卡”如何分发;会员卡“的内容，以及客户如何使用”会员卡“。
正统的cookie分发是通过扩展HTTP协议，服务器通过HTTP响应头一排，添加特殊说明，按照说明进行操作提示浏览器将生成相应的cookie。然而，纯粹的客户端脚本如JavaScript或VBScript也可以生成cookie中。
使用cookie是由浏览器按照一定的原则在后台自动发送到服务器。浏览器检查所有存储的cookie，如果声明一个cookie范围大于或等于所请求的资源，把附在请求资源的HTTP请求发送到服务器的头的cookie。意思是麦当劳的会员卡只能在麦当劳的店里出示，如果一个商店也发行了自己的会员卡，然后进店除了麦当劳的会员卡到现在的时间，而且还产生一个成员的存储卡。
的cookie内容包括：名字，值，过期，路径和域。
在那里你可以指定一个特定的领域，如域。 google.com，相当于总店招牌，比如宝洁公司（Procter＆Gamble），你也可以指定一个特定的领域，如机器或froogle.google.com，您可以用飘柔做比。
如下的URL路径的路径后，该域名，比如/或者/ foo的等，可以做一定比例飘柔专柜。
路径和域共同构成的cookie的范围。
如果不设置过期时间，然后为浏览器会话cookie的寿命，只要关闭浏览器窗口，cookie的消失。这一时期的生活的浏览器会话cookie被称为会话cookie。会话cookie一般不存储在硬盘上，但存储在内存中，当然，这种行为是不是规范。如果你设置的过期时间，浏览器cookie保存到硬盘驱动器，打开浏览器后，再次关闭这些cookie仍然有效，直到过期时间超过设定。
存储在硬盘上的Cookie在不同的浏览器，可以在进程间共享，比如两个IE窗口。并存储在内存中的cookie，不同的浏览器有不同的方法。对于IE浏览器，在打开的窗口中，按Ctrl-N（或者从文件菜单）打开的窗口可以与原窗口共享，而使用其他方式来打开IE进程不会共享内存窗口已经打开饼干;对于Mozilla Firefox0.8中，所有的流程和标签可以共享相同的cookie。一般用javascript的window.open打开的窗口与原窗口共享内存cookie。只认cookie的浏览器会话cookie不承认这样的人造成了很大的困扰，使用常规的网络应用程序开发人员的会话处理机制。
这里是GOOLGE集一个cookie的响应头的例子
HTTP/1.1 302找到
位置：
的Set-Cookie：PREF = ID = 0565f77e132de138：净重= 1 ：TM = 1098082649：LM = 1098082649：S = KaeaCFPo49RiA_d8到期=星期日，1月17日 - 2038年19时14分07秒GMT;路径= /;域=。 google.com
的Content-Type：text / html类型
这是使用HTTPLook这个HTTP Sniffer软件捕获记录的一部分，HTTP通信
浏览器再次访问GOOLGE自动送出当资源的cookie
使用Firefox可以很容易地观察现有的cookie值，
请使用HTTPLook Firefox可以很容易理解的cookie工程。
IE也可以设置在询价之前接受cookie
这是一个对话框，要求接受Cookie。
四，理解机制
会话的会话机制是一种机制，为服务器，服务器使用一个哈希表状结构（也可能是使用一个哈希表）来保存信息。
当程序需要为客户端请求创建一个会话时，服务器首先检查客户端的请求已被列入会话标识符 - 所谓的会话ID，如果已包含一个session id，然后在客户端有先前已创建服务器会话的会话ID将主持本届会议，检索使用（如果没有检索到，它可以创建一个），如果客户端请求不包含会话ID，然后为这个客户端创建一个会话，并生成一个会话这个会话ID，会话ID值应该既不是重复的，不容易找到规律复制字符串，这个session id将返回响应这个客户端保存。
这种方式可以使用会话cookie保存，以便根据规则把这个标识服务器的一个互动的过程中浏览器可以自动播放。一般来说，cookie的名称是类似SEEESIONID的。对于Web应用程序生成的cookie如WebLogic，JSESSIONID = ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng！ -145788764，它的名字是JSESSIONID。
由于cookie可以被人为的禁止，必须有其他的机制被禁止的cookie会话ID仍然能够回传给服务器。经常使用的一种技术叫做URL重写，会话ID被附加到URL路径直接背后，还有另外两种方法，一种是在JSESSIONID = ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng的形式，为更多的信息，表现的URL路径！ -145788764
另一种是作为查询字符串附加到URL后面的表现！ -145788764
这两种方式为用户没有任何区别，只有服务器解析不同的方式处理时，第一种方法是会话ID信息也有利于区分正常程序参数。
整个交互过程中，为了始终保持状态，就必须要求每个客户端后路径可能包含会话ID。
另一种技术称为隐藏的表单字段。是服务器会自动表单，添加一个隐藏字段，这样，当表单被提交到这个session id传递回服务器。例如，下面的表格
被传递到客户端之前被改写
现在已很少使用这种技术，我谈到一个非常古老的iPlanet6（SUNONE应用服务器的前身）上使用这种技术。
其实，这种技术可以应用，只需使用URL重写的行动，而不是。
谈论的会话机制，我经常听到这样的误会“，只要在浏览器关闭，会话就消失了。”事实上，想象例子会员卡除非客户作出商店卖卡，否则店里会不会轻易删除客户数据。同样是真实的会话，除非程序通知服务器删除会话，否则服务器将仍然存在，程序通常都是在用户注销时发出命令删除会话。然而，浏览器从来不会主动关闭之前通知服务器将被关闭，服务器将不会有机会知道浏览器已经关闭，之所以有这样的误解最多的一届机制使用会话cookie来存储会话ID，会话ID消失后关闭浏览器，它不能连接到服务器，再找到原来的session。如果服务器设置的cookie存储在您的硬盘上，或者使用某种手段改写浏览器发送一个HTTP请求头，原来的session id发送到服务器，然后重新打开浏览器仍然能够找到原来的会话。
正是因为浏览器被关闭，并不导致会话被删除，迫使服务器SEESION设立了故障时间，当距离客户端上使用，盘中一度时间超过届满时间，服务器，客户端已停止其活动，该会话将被删除以节省存储空间。
五，理解javax.servlet.http.HttpSession
HttpSession会话的机制是Java平台的实施规范，因为它是唯一的，具体到每一个Web应用程序服务器提供商的接口，除了规范的支持，仍然会有一些规范未指定的细微差别。在这里，我们与BEA公司的Weblogic Server8.1作为例子来演示。
第一，WebLogic Server提供的一组参数来控制它的HttpSession实现，包括使用cookie的开关选项，使用URL重写的开关选项，会话持久性设置，会话过期时间设置，并为各种cookie的设置，比如设置cookie的名称，路径，域，cookie的生存时间。
当服务器进程停止或重新启动，正常情况下，将被保存在内存中，内存的会议将被清除，如果你将它设置为会话持久性功能，将服务器会话保存到您的硬盘驱动器，当服务器进程重新启动或信息将能够被再次使用时，WebLogic Server支持持久的方法，包括文件，数据库，客户端cookie保存和繁殖。
持续复制是没有严格保持，因为会话实际上是存储在内存中，但同样的信息被复制到每个集群内的服务器进程，这样即使服务器进程停止工作能在这个过程中仍然可以实现从其他会话。
cookie设置会影响生成的cookie，如果浏览器是一个会话cookie的生存时间。默认是使用会话cookie。有兴趣的人士可以用它来测试在第四季度，我们提到的那个误解。
Cookie路径的Web应用程序是一个非常重要的选项，此选项的默认处理，使得它有着明显的区别与其他服务器Weblogic服务器。稍后我们将讨论的话题。
会话设置参考[5]
六，HttpSession中常见问题
（本条所指的混合会话，E§ E）
1，创建会话时
一个常见的误解是，在客户端的会话访问，当它被创建，但事实是，直到服务器端程序调用HttpServletRequest的。 getSession（）这样的语句只被创建，注意不显示，如果使用JSP 闭门会议中，JSP文件被编译成Servlet会自动添加这样的语句的HttpSession会话= HttpServletRequest.getSession（真），这是JSP隐式会话对象的原点。
因为会话会消耗内存资源，因此，如果你不打算使用会话，所有的JSP应该把它关闭。
综合前面的讨论，都将被删除2，会话，会话在下列情况下被删除。程序调用HttpSession.invalidate（）令;或b。从最后客户收到发送的session id时间间隔超过会话超时设置，或c。服务器进程被停止（非持久性会议）
3，如何做到在浏览器关闭时删除会话
严格地说，这是不可能的。你可以做一点努力接近客户的所有页面使用javascript代码window.oncolose的监视浏览器的关闭动作，然后向服务器发送一个请求删除会话。但是，浏览器崩溃或强制杀进程仍然无能为力这些非常规手段。
4，有
，HttpSessionListener补偿是如何创建这样的监听监视会话的创建和销毁事件，发生这样的事件，你可以做一些相应的工作。请注意，创建和销毁的会话或动作触发的监听器，而不是相反。类似的HttpSession中伴有以及HttpSessionBindingListener接口，的HttpSessionActivationListener HttpSessionAttributeListener的听者。
5，存储在会话对象必须是可序列化
不是必需的。需要对象可以序列化会话，只是为了能够在集群中被复制，或者可以坚持，在必要的情况下，会话服务器可以暂时换出内存。在WebLogic Server控制台上放置一个非序列化对象的会话将收到一个警告。我用过的iPlanet版本如果会话已经没有序列化的对象在会话中有将是一个例外破坏，很奇怪。
6，如何正确处理与客户端的可能性禁止饼干
所有的URL使用URL重写，包括超链接，form的action，和重定向URL，具体做法参见[6
7，打开两个浏览器窗口访问应用程序将使用同一时段或不同的会话
见第三部分讨论的cookie，会话ID只认不认人，因此不同浏览器，不同的窗口开放和不同的cookie将被存储在受影响这个问题的答案。
8，如何防止用户打开两个浏览器窗口操作导致会话混乱
防止多次提交的问题是类似的形式，你可以设置客户端的令牌来解决。也就是说，服务器每次生成一个不同的ID返回给客户端，同时保存在会话中，客户端提交表单时，必须返回到服务器也是这个id，程序首先比较返回的id的值存储在会话是相同的，如果不一致，在此操作中所示前已经提交。可以发现在“J2EE核心模式”表示层模式的部分。需要注意的是，使用的javascript的window.open打开的窗口，一般不设置这个id，或者使用一个单独的ID，无法操作，以防止在主窗口，建议不要做window.open打开的窗口操作，这样就可以不设置。
9，为什么做这个动作的目的主要是为集群环境中提示Weblogic服务器会话发生在在Weblogic服务器改变会话的价值后，重新调用一次session.setValue
值的变化，你需要复制到其他服务器进程的价值，新的会话。
10，为什么会话了
排除会话正常的故障因素，服务器本身的可能性应该是微乎其微，虽然笔者iPlanet6SP1的加若干补丁Solaris版本是相当遇到;通过浏览器插件的可能性，我也遇到过3721插件造成的问题;理论上防火墙或者代理服务器在cookie处理也可能会造成问题。
发生，主要是因为这个问题是程序的错误，最常见的是在应用程序中访问另一个应用程序。在下一节中，我们将讨论这个问题。
七，跨应用程序的会话共享
这是通常的情况下，一个大型开发项目划分成若干小项目，为了能够干扰对方，要求每个小项目作为一个单独的Web应用程序开发中，但在最后突然发现了几个小项目需要之间共享一些信息，或者想使用session来实现SSO（单点登录），存储在会话登录用户信息，最自然的要求是应用程序之间互相访问对方的会话。
但是，按照Servlet规范，会话的范围应仅限于当前的应用程序，不同的应用程序之间是不能够访问每个会话。从实际的效果是每个应用服务器在遵守本规范，但其执行细节可能会有所不同，因此解决跨应用程序的会话共享方法也是不同的。
先看看Tomcat的Web应用程序是如何实现会话之间的隔离，从Tomcat视图设置cookie路径，其不同的应用程序设置的cookie路径是不同的，所以不同的应用程序所用的session id是不同的，即使在同一个浏览器窗口访问不同的应用程序，发送到服务器的会话ID可以是不同的。
根据这一特点，我们可以在会话推测Tomcat的内存结构如下。
我用过的iPlanet也采用同样的方式，估计SUNONE和iPlanet没有太大的区别。对于这样的服务器，解决方案是非常简单的想法，它的实际执行情况并不难。要么让所有的应用程序共享一个session id，或者让应用程序能够获得其他应用程序会话ID。
的iPlanet是一个非常简单的方式来实现共享一个session id，那就是每个应用程序的cookie路径都设为/（实际上应该是/ NASApp的，在其行为中的应用为根）。
</路径/ NASApp >
注操作共享会议应该遵循一些编程约定，如在会话属性名称前面的应用程序的前缀，使的setAttribute（“名称”，“新”）成为的setAttribute（的“app1.name”，“新”）中，为了防止命名空间冲突，领导互相覆盖。
在Tomcat中是不太方便的选择。在Tomcat版本3中，我们还可以有一些手段来共享会话。对于版本4以上的Tomcat，现在我还没有找到一个简单的解决方案。只能借助于第三方的力量，比如使用文件，数据库，JMS或者客户端cookie，URL参数或者隐藏字段等手段。
让我们来看看如何处理与WebLogic Server是会话。
从截图可以看到WebLogic Server应用程序设置的cookie路径为/，这是不是意味着在默认情况下，WebLogic服务器可以共享会话它？然而，一个小实验证明，即使不同的应用程序使用同一个会话，每个应用程序仍然只能访问自己设置这些属性。这表明，本次会议的WebLogic Server的内存结构可能看起来
对于这样的结构，机制本身的会话共享解决问题的会议应该是不可能的。另外电源通过一个第三个政党，比如使用文件，数据库，JMS或者客户端cookie，URL参数或者隐藏字段和其他手段，以及更方便的方式，就是以把一个应用程序的会话ServletContext的，所以从ServletContext的引用到应用程序之前，另一个应用程序可以通过以下方式获得。示例代码如下
应用á
context.setAttribute（“阿帕”，会话）;
应用程序B，
contextA =上下文。的getContext（“/ APPA”）;
HttpSession中sessionA =（HttpSession中）contextA.getAttribute（APPA）;
值得注意的是，这种用法是不可移植的，因为根据ServletContext的的JavaDoc，应用服务器可以在出于安全原因context.getContext（“/ APPA”）;返回一个空值，通过上述方法在WebLogic Server 8.1。
那么，为什么要所有的WebLogic Server应用程序设置的cookie路径/？正是在SSO，谁分享了本次会议的应用程序可以共享认证信息。一个简单的实验可以证明这一点，第一个日志，应用程序描述符weblogic.xml，cookie路径是/ APPA访问的另一个应用程序的要求重新登录，甚至如果反过来，先访问cookie路径为/应用程序，然后访问的路径，虽然不再提示登录，但注册用户的信息将会丢失。请注意，这个实验验证表单时，应使用基本身份验证方法其他的方式来处理第二个请求认证，因为浏览器和Web服务器没有达到通过会话。具体见文献[7] 14.8 secion授权，你可以所附的示例程序来做这些测试。
八，总结
session机制本身并不复杂，但其实施和配置灵活性的具体情况复杂。它还需要，我们可以不只是一个第一次的经验或者某一个浏览器，服务器的经验作为普遍的经验，但总是需要具体情况具体分析。