cookie、session、sessionid 与jsessionid[转]

cookie、session、sessionid 与jsessionid，要想明白他们之间的关系，下面来看个有趣的场景来帮你理解。

 

　　我们都知道银行，银行的收柜台每天要接待客户存款/ 取款 业务，可以有几种方案：

　　凭借柜台职员的记忆，由收柜台职员来为每位顾客办理存款/ 取款业务，单凭职员的记忆力，要记到每位顾客的相貌，并迅速这个顾客当前的存款以及存取的次数，每次存取的金额是多少。 -----------这种方式表示协议本身支持状态。

 

 

     使用存折的方式，然后柜台职员就把每个顾客的存款/ 取款的信息保存在这张折子，然后交给顾客保管，当顾客来存款 / 取款时，只要拿出存折，职员查看存折就对当前这位顾客的存款 / 取款信息一目了然。当然，你马上会想到，顾客修改这个信息怎么办？我们也有措施对每次存款 / 取款记录后面盖章。无盖章的就是假冒信息。但如果顾客是 真的要伪造，当然印章也是可以伪造的。-------------这种方式就是在客户端端保持状态。

 使用银行卡的方式，发给每位银行用户一张银行卡，银行卡上有一个唯一的卡号，没有其它任何信息，当顾客来存款/ 取款时 ，拿出银行卡，银行把卡号输入的电脑，很快就显示当前用户的存/ 取款 记录。这种方式的安全性就会有很大的提高。用户想要手脚只有攻破银行的服务器来修改自己的存/取款信息，这样做难度会很大。 --------- 这种方式就是服务器端保持状态。

 

Cookie 与 session 的产生过程                                

 

　　我们都知道HTTP 协议本身是无状态的，客户只需要简单的向服务器来发送请求下载某些文件，客户端向服务器端发送的每次请求都是独立的。对于当前的 web 应用， HTTP 的“无状态”，导致许多应用都不得不花费大量的精力来记录用户的操作步骤。就像我们上面介绍的第一种情况，银行职员要花费大量的精力来记忆每一位用户的存 / 取款记录。

　　程序员很快发现，如果能够提供一些按需生成的动太信息，会使web 的交互能力大大增强。程序员一方面在 HTML 中添加表单、脚本、 DOM 等客户端行为，来增加 web 应用与客户端的交互性。另一方面在服务器端测出现了 CGI 规范以响应客户端的动态请求，作为传输载体的 HTTP 协议添加了文件上载、 cookie  等特性。那 cookie 的原理与我们上面介绍的使用存折记录用户应为的方式是一样一样的。

　　通过前面的例子我们已经发现，通过cookie 的方式存储信息，可能会存在一点定的安全性，因为所有的信息都是写在客户端的，客户可能会对这些信息进行修改或清除。然后就又出现 session 的方式用于保存用户行为，这种方式的原理与前面介绍银行卡的方式是一样的。

　　具体来说cookie 机制采用的是在客户端保持状态的方案，而 session 机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以 session 机制可能需要借助于 cookie 机制来达到保存标识的目的，但实际上它还有其他选择。

 

cookie与session的机制与原理                              

 

　　 cookie机制。正统的 cookie 分发是通过扩展 HTTP 协议来实现的，服务器通过在 HTTP 的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的 cookie 。然而纯粹的客户端脚本如 JavaScript 或者 VBScript 也可以生成 cookie 。而 cookie 的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的 cookie ，如果某个 cookie 所声明的作用范围大于等于将要请求的资源所在的位置，则把该 cookie 附在请求资源的 HTTP 请求头上发送给服务器。

    　cookie的内容主要包括：名字，值，过期时间，路径和域。路径与域一起构成 cookie 的作用范围。若不设置过期时间，则表示这个 cookie 的生命期为浏览器会话期间，关闭浏览器窗口， cookie 就消失。这种生命期为浏览器会话期的 cookie 被称为会话 cookie 。会话 cookie 一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。若设置了过期时间，浏览器就会把 cookie 保存到硬盘上，关闭后再次打开浏览器，这些 cookie 仍然有效直到超过设定的过期时间。存储在硬盘上的 cookie 可以在不同的浏览器进程间共享，比如两个 IE 窗口。而对于保存在内存里的 cookie ，不同的浏览器有不同的处理方式 。 

　　session机制。 session 机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。  

　　当程序需要为某个客户端的请求创建一个session 时，服务器首先检查这个客户端的请求里是否已包含了一个 session 标识 ------------称为session  id，如果已包含则说明以前已经为此客户端创建过 session ，服务器就按照 session id 把这个 session 检索出来使用（检索不到，会新建一个），如果客户端请求不包含 session id ，则为此客户端创建一个 session 并且生成一个与此 session 相关联的 session id ， session id 的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个 session id 将被在本次响应中返回给客户端保存。

        保存这个session id 的方式可以采用 cookie ，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个 cookie 的名字都是类似于 SEEESIONID 。但 cookie 可以被人为的禁止，则必须有其他机制以便在 cookie 被禁止时仍然能够把 session id 传递回服务器。
       经常被使用的一种技术叫做URL 重写，就是把 session id 直接附加在 URL 路径的后面。还有一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把 session id 传递回服务器。

 

Jsessionid?

　　Jsessionid只是 tomcat 的对 sessionid 的叫法，其实就是 sessionid ；在其它的容器也许就不叫 jsessionid 了。

 

这个jsessionid是session的一个标识。

       session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

       当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为 session id，如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个 session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个 session id将被在本次响应中返回给客户端保存。

       保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于 SEEESIONID，而。比如weblogic对于web应用程序生成的cookie，JSESSIONID= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764，它的名字就是 JSESSIONID。

       由于cookie可以被人为的禁止，必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面，附加方式也有两种，一种是作为URL路径的附加信息，表现形式为http://...../xxx;jsessionid = ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764

另一种是作为查询字符串附加在URL后面，表现形式为http://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764

这两种方式对于用户来说是没有区别的，只是服务器在解析的时候处理的方式不同，采用第一种方式也有利于把session id的信息和正常程序参数区分开来。

为了在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。

       另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如下面的表单

<form name="testform" action="/xxx"><input type="text"></form>

 

       在被传递给客户端之前将被改写成

<form name="testform" action="/xxx"><input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764"><input type="text"></form>

 

       这种技术现在已较少应用，笔者接触过的很古老的iPlanet6(SunONE应用服务器的前身)就使用了这种技术。实际上这种技术可以简单的用对action应用URL重写来代替。

       在谈论session机制的时候，常常听到这样一种误解“只要关闭浏览器，session就消失了”。其实可以想象一下会员卡的例子，除非顾客主动对店家 提出销卡，否则店家绝对不会轻易删除顾客的资料。对session来说也是一样的，除非程序通知服务器删除一个session，否则服务器会一直保留，程 序一般都是在用户做log off的时候发个指令去删除session。然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所 以会有这种错觉，是大部分session机制都使用会话cookie来保存session id，而关闭浏览器后这个 session id就消失了，再次连接服务器时也就无法找到原来的session。

       如果服务器设置的cookie被保存到硬盘上，或者使用某种手段改写浏览器发出的HTTP请求头，把原来的session id发送给服务器，则再次打开浏览器仍然能够找到原来的session。

       恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为seesion设置了一个失效时间，当距离客户端上一次使用session的时间超过这个失效时间时，服务器就可以认为客户端已经停止了活动，才会把session删除以节省存储空间