cookie和session机制

一、cookie和session机制之间的差别和联系

1、cookie机制

Cookie意为“甜饼”，是由W3C组织提出，最早由Netscape社区发展的一种机制。

眼下Cookie已经成为标准。全部的主流浏览器如IE、Netscape、Firefox、Opera等都支持Cookie。

Cookie的含义是“server送给浏览器的甜点”，即server在响应请求时能够将一些数据以“键-值”对的形式通过响应信息保存在client。当浏览器再次訪问相同的应用时，会将原先的Cookie通过请求信息带到server端。

详细来说cookie机制採用的是在client保持状态的方案。它是在用户端的会话状态的存贮机制。他须要用户打开client的cookie支持。cookie的作用就是为了解决HTTP协议无状态的缺陷所作的努力。

查看某个站点颁发的Cookie非常easy。在浏览器地址栏输入javascript:alert(document. cookie)就能够了（须要有网才干查看）。

 

注意：Cookie功能须要浏览器的支持。

假设浏览器不支持Cookie（如大部分手机中的浏览器）或者把Cookie禁用了，Cookie功能就会失效。

不同的浏览器採用不同的方式保存Cookie。

IE浏览器会在“C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Cookies”目录下以文本文件形式保存。一个文本文件保存一个Cookie。当中Administrator改为自己的电脑名称。

Cookie具有不可跨域名性。根据Cookie规范。浏览器訪问Google仅仅会携带Google的Cookie。而不会携带Baidu的Cookie。Google也仅仅能操作Google的Cookie，而不能操作Baidu的Cookie。

Cookie在client是由浏览器来管理的。

浏览器能够保证Google仅仅会操作Google的Cookie而不会操作 Baidu的Cookie，从而保证用户的隐私安全。

浏览器推断一个站点能否操作还有一个站点Cookie的根据是域名。Google与Baidu的域名不一样，因此Google不能操作Baidu的Cookie。

须要注意的是。虽然站点images.google.com与站点www.google.com同属于Google。可是域名不一样，二者相同不能互相操作彼此的Cookie。

注意：用户登录站点www.google.com之后会发现訪问images.google.com时登录信息仍然有效。而普通的Cookie是做不到的。

这是因为Google做了特殊处理。

本章后面也会对Cookie做相似的处理。

HTTP协议不仅是无状态的。并且是不安全的。

使用HTTP协议的数据不经过不论什么加密就直接在网络上传播，有被截获的可能。

使用HTTP协议传输非常机密的内容是一种隐患。

假设不希望Cookie在HTTP等非安全协议中传输，能够设置Cookie的secure属性为true。

浏览器仅仅会在HTTPS和 SSL等安全协议中传输此类Cookie。

2、Session机制

当多个client运行程序时，server会保存多个client的Session。获取Session的时候也不须要声明获取谁的Session。Session机制决定了当前客户仅仅会获取到自己的Session，而不会获取到别人的Session。各客户的Session也彼此独立。互不可见。

而session机制採用的是一种在client与server之间保持状态的解决方式。

同一时候我们也看到，因为採用server端保持状态的方案在client也须要保存一个标识，所以session机制可能须要借助于cookie机制来达到保存标识的目的。而session提供了方便管理全局变量的方式。

session是针对每个用户的，变量的值保存在server上，用一个session ID来区分是哪个用户session变量,这个值是通过用户的浏览器在訪问的时候返回给server，当客户禁用cookie时，这个值也可能设置为由get来返回给server。

就安全性来说：当你訪问一个使用session的站点，同一时候在自己机子上建立一个cookie，建议在server端的SESSION机制更安全些。因为它不会随意读取客户存储的信息。

正统的cookie分发是通过扩展HTTP协议来实现的，server通过在HTTP的响应头中加上一行特殊的指示以提示浏览器依照指示生成对应的cookie。

从网络server观点看全部HTTP请求都独立于先前请求。

就是说每个HTTP响应全然依赖于对应请求中包括的信息。

状态管理机制克服了HTTP的一些限制并同意网络client及server端维护请求间的关系。在这样的关系维持的期间叫做会话(session)。

Cookies是server在本地机器上存储的小段文本并随每个请求发送至同一个server。IETF RFC 2965 HTTP State Management Mechanism是通用cookie规范。网络server用HTTP头向client发送 cookies。在客户终端，浏览器解析这些cookies并将它们保存为一个本地文件。它会自己主动将同一server的不论什么请求缚上这些cookies

 

二、理解session机制

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

1、Session的生命周期

Session保存在server端。为了获得更高的存取速度，server一般把Session放在内存里。

每个用户都会有一个独立的Session。假设Session内容过于复杂，当大量客户訪问server时可能会导致内存溢出。因此，Session里的信息应该尽量精简。

Session在用户第一次訪问server的时候自己主动创建。须要注意仅仅有訪问JSP、Servlet等程序时才会创建Session，仅仅訪问HTML、IMAGE等静态资源并不会创建Session。假设尚未生成Session，也能够使用request.getSession(true)强制生成Session。

Session生成后，仅仅要用户继续訪问，server就会更新Session的最后訪问时间。并维护该Session。

用户每訪问server一次。不管是否读写Session，server都觉得该用户的Session“活跃（active）”了一次。

 

2、client使用cookie

当程序须要为某个client的请求创建一个session的时候。server首先检查这个client的请求里是否已包括了一个session标识-称为sessionid，假设已包括一个sessionid则说明曾经已经为此client创建过session。server就依照sessionid把这个 session检索出来使用（假设检索不到，可能会新建一个），假设client请求不包括sessionid，则为此client创建一个session并且生成一 个与此session相关联的sessionid，sessionid的值应该是一个既不会反复，又不easy被找到规律以仿造的字符串，这个
sessionid将被在本次响应中返回给client保存。

保存这个sessionid的方式能够採用cookie，这样在交互过程中浏览器能够自己主动的依照规则把这个标识发挥给server。一般这个 cookie的名字都是相似于SEEESIONID。比方weblogic对于web应用程序生成的cookie，JSESSIONID = ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764，它的名字就是JSESSIONID。

3、client使用URL重写

因为cookie能够被人为的禁止，必须有其它机制以便在cookie被禁止时仍然能够把sessionid传递回server。经常被使用的一种技术叫做URL重写，就是把sessionid直接附加在URL路径的后面，附加方式也有两种，

1）一种是作为URL路径的附加信息，表现形式为http://...../xxx;jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764

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

　　这两种方式对于用户来说是没有差别的。仅仅是server在解析的时候处理的方式不同，採用第一种方式也有利于把sessionid的信息和正常程序參数区分开来。

注意：TOMCAT推断client浏览器是否支持Cookie的根据是请求中是否含有Cookie。虽然client可能会支持Cookie。可是因为第一次请求时不会携带不论什么Cookie（因为并无不论什么Cookie能够携带），URL地址重写后的地址中仍然会带有jsessionid。当第二次訪问时server已经在浏览器中写入Cookie了，因此URL地址重写后的地址中就不会带有jsessionid了。

三、总结　

为了在整个交互过程中始终保持状态。就必须在每个client可能请求的路径后面都包括这个sessionid。

　　在谈论session机制的时候，经常听到这样一种误解“仅仅要关闭浏览器，session就消失了”。事实上能够想象一下会员卡的样例，除非顾客主动对店家提出销卡，否则店家绝对不会轻易删除顾客的资料。对session来说也是一样的。除非程序通知server删除一个session，否则server会一直保留，程序一般都是在用户做logoff的时候发个指令去删除session。

然而浏览器从来不会主动在关闭之前通知server它将要关闭，因此server根本不会有机会知道浏览器已经关闭，之所以会有这样的错觉。是大部分session机制都使用会话cookie来保存sessionid。而关闭浏览器后这个
sessionid就消失了，再次连接server时也就无法找到原来的session。假设server设置的cookie被保存到硬盘上。或者使用某种手段改写浏览器发出的HTTP请求头，把原来的sessionid发送给server，则再次打开浏览器仍然能够找到原来的session。

恰恰是因为关闭浏览器不会导致session被删除，迫使server为seesion设置了一个失效时间，当距离client上一次使用session的时间超过这个失效时间时，server就能够觉得client已经停止了活动，才会把session删除以节省存储空间。

 

參考之：http://www.3lian.com/edu/2013/12-28/119837.html

http://blog.csdn.net/fangaoxin/article/details/6952954