大话SESSION
FROM http://www.cnblogs.com/shoru/archive/2010/02/19/1669395.html
晋哥哥的私房钱
创造支点，撬动地球
大话Session
转载请保留出处:shoru.cnblogs.com
引言
在web开发中，session是个非常重要的概念。在许多动态网站的开发者看来，session就是一个变量，而且其表现像个黑洞，他只需要将东西在合适的时机放进这个洞里，等需要的时候再把东西取出来。这是开发者对session最直观的感受，但是黑洞里的景象或者说session内部到底是怎么工作的呢？当笔者向身边的一些同事或朋友问及相关的更进一步的细节时，很多人往往要么含糊其辞要么主观臆断，所谓知其然而不知其所以然。
笔者由此想到很多开发者，包括我自己，每每都是纠缠于框架甚至二次开发平台之上，而对于其下的核心和基础知之甚少，或者有心无力甚至毫不关心，少了逐本溯源的精神，每忆及此，无不惭愧。曾经实现过一个简单的HttpServer，但当时由于知识储备和时间的问题，没有考虑到session这块，不过近期在工作之余翻看了一些资料，并进行了相关实践，小有所得，本着分享的精神，我将在本文中尽可能全面地将个人对于session的理解展现给读者，同时尽我所能地论及一些相关的知识，以期读者在对session有所了解的同时也能另有所悟，正所谓授人以渔。
Session是什么
Session一般译作会话，牛津词典对其的解释是进行某活动连续的一段时间。从不同的层面看待session，它有着类似但不全然相同的含义。比如，在web应用的用户看来，他打开浏览器访问一个电子商务网站，登录、并完成购物直到关闭浏览器，这是一个会话。而在web应用的开发者开来，用户登录时我需要创建一个数据结构以存储用户的登录信息，这个结构也叫做session。因此在谈论session的时候要注意上下文环境。而本文谈论的是一种基于HTTP协议的用以增强web应用能力的机制或者说一种方案，它不是单指某种特定的动态页面技术，而这种能力就是保持状态，也可以称作保持会话。
为什么需要session
谈及session一般是在web应用的背景之下，我们知道web应用是基于HTTP协议的，而HTTP协议恰恰是一种无状态协议。也就是说，用户从A页面跳转到B页面会重新发送一次HTTP请求，而服务端在返回响应的时候是无法获知该用户在请求B页面之前做了什么的。
对于HTTP的无状态性的原因，相关RFC里并没有解释，但联系到HTTP的历史以及应用场景，我们可以推测出一些理由：
1. 设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。那个时候没有动态页面技术，只有纯粹的静态HTML页面，因此根本不需要协议能保持状态；
2. 用户在收到响应时，往往要花一些时间来阅读页面，因此如果保持客户端和服务端之间的连接，那么这个连接在大多数的时间里都将是空闲的，这是一种资源的无端浪费。所以HTTP原始的设计是默认短连接，即客户端和服务端完成一次请求和响应之后就断开TCP连接，服务器因此无法预知客户端的下一个动作，它甚至都不知道这个用户会不会再次访问，因此让HTTP协议来维护用户的访问状态也全然没有必要；
3. 将一部分复杂性转嫁到以HTTP协议为基础的技术之上可以使得HTTP在协议这个层面上显得相对简单，而这种简单也赋予了HTTP更强的扩展能力。事实上，session技术从本质上来讲也是对HTTP协议的一种扩展。
总而言之，HTTP的无状态是由其历史使命而决定的。但随着网络技术的蓬勃发展，人们再也不满足于死板乏味的静态HTML，他们希望web应用能动起来，于是客户端出现了脚本和DOM技术，HTML里增加了表单，而服务端出现了CGI等等动态技术。
而正是这种web动态化的需求，给HTTP协议提出了一个难题：一个无状态的协议怎样才能关联两次连续的请求呢？也就是说无状态的协议怎样才能满足有状态的需求呢？
此时有状态是必然趋势而协议的无状态性也是木已成舟，因此我们需要一些方案来解决这个矛盾，来保持HTTP连接状态，于是出现了cookie和session。
对于此部分内容，读者或许会有一些疑问，笔者在此先谈两点：
1. 无状态性和长连接
可能有人会问，现在被广泛使用的HTTP1.1默认使用长连接，它还是无状态的吗？
连接方式和有无状态是完全没有关系的两回事。因为状态从某种意义上来讲就是数据，而连接方式只是决定了数据的传输方式，而不能决定数据。长连接是随着计算机性能的提高和网络环境的改善所采取的一种合理的性能上的优化，一般情况下，web服务器会对长连接的数量进行限制，以免资源的过度消耗。
2. 无状态性和session
Session是有状态的，而HTTP协议是无状态的，二者是否矛盾呢？
Session和HTTP协议属于不同层面的事物，后者属于ISO七层模型的最高层应用层，前者不属于后者，前者是具体的动态页面技术来实现的，但同时它又是基于后者的。在下文中笔者会分析Servlet/Jsp技术中的session机制，这会使你对此有更深刻的理解。
Cookie和Session
上面提到解决HTTP协议自身无状态的方式有cookie和session。二者都能记录状态，前者是将状态数据保存在客户端，后者则保存在服务端。
首先看一下cookie的工作原理，这需要有基本的HTTP协议基础。
cookie是在RFC2109（已废弃，被RFC2965取代）里初次被描述的，每个客户端最多保持三百个cookie，每个域名下最多20个Cookie（实际上一般浏览器现在都比这个多，如Firefox是50个），而每个cookie的大小为最多4K，不过不同的浏览器都有各自的实现。对于cookie的使用，最重要的就是要控制cookie的大小，不要放入无用的信息，也不要放入过多信息。
无论使用何种服务端技术，只要发送回的HTTP响应中包含如下形式的头，则视为服务器要求设置一个cookie：
Set-cookie:name=name;expires=date;path=path;domain=domain
支持cookie的浏览器都会对此作出反应，即创建cookie文件并保存（也可能是内存cookie），用户以后在每次发出请求时，浏览器都要判断当前所有的cookie中有没有没失效（根据expires属性判断）并且匹配了path属性的cookie信息，如果有的话，会以下面的形式加入到请求头中发回服务端：
Cookie: name="zj"; Path="/linkage"
服务端的动态脚本会对其进行分析，并做出相应的处理，当然也可以选择直接忽略。
这里牵扯到一个规范（或协议）与实现的问题，简单来讲就是规范规定了做成什么样子，那么实现就必须依据规范来做，这样才能互相兼容，但是各个实现所使用的方式却不受约束，也可以在实现了规范的基础上超出规范，这就称之为扩展了。无论哪种浏览器，只要想提供cookie的功能，那就必须依照相应的RFC规范来实现。所以这里服务器只管发Set-cookie头域，这也是HTTP协议无状态性的一种体现。
需要注意的是，出于安全性的考虑，cookie可以被浏览器禁用。
再看一下session的原理：
笔者没有找到相关的RFC，因为session本就不是协议层面的事物。它的基本原理是服务端为每一个session维护一份会话信息数据，而客户端和服务端依靠一个全局唯一的标识来访问会话信息数据。用户访问web应用时，服务端程序决定何时创建session，创建session可以概括为三个步骤：
1. 生成全局唯一标识符（sessionid）；
2. 开辟数据存储空间。一般会在内存中创建相应的数据结构，但这种情况下，系统一旦掉电，所有的会话数据就会丢失，如果是电子商务网站，这种事故会造成严重的后果。不过也可以写到文件里甚至存储在数据库中，这样虽然会增加I/O开销，但session可以实现某种程度的持久化，而且更有利于session的共享；
3. 将session的全局唯一标示符发送给客户端。
问题的关键就在服务端如何发送这个session的唯一标识上。联系到HTTP协议，数据无非可以放到请求行、头域或Body里，基于此，一般来说会有两种常用的方式：cookie和URL重写。
1. Cookie
读者应该想到了，对，服务端只要设置Set-cookie头就可以将session的标识符传送到客户端，而客户端此后的每一次请求都会带上这个标识符，由于cookie可以设置失效时间，所以一般包含session信息的cookie会设置失效时间为0，即浏览器进程有效时间。至于浏览器怎么处理这个0，每个浏览器都有自己的方案，但差别都不会太大（一般体现在新建浏览器窗口的时候）；
2. URL重写
所谓URL重写，顾名思义就是重写URL。试想，在返回用户请求的页面之前，将页面内所有的URL后面全部以get参数的方式加上session标识符（或者加在path info部分等等），这样用户在收到响应之后，无论点击哪个链接或提交表单，都会在再带上session的标识符，从而就实现了会话的保持。读者可能会觉得这种做法比较麻烦，确实是这样，但是，如果客户端禁用了cookie的话，URL重写将会是首选。
到这里，读者应该明白我前面为什么说session也算作是对HTTP的一种扩展了吧。如下两幅图是笔者在Firefox的Firebug插件中的截图，可以看到，当我第一次访问index.jsp时，响应头里包含了Set-cookie头，而请求头中没有。当我再次刷新页面时，图二显示在响应中不在有Set-cookie头，而在请求头中却有了Cookie头。注意一下Cookie的名字：jsessionid，顾名思义，就是session的标识符，另外可以看到两幅图中的jsessionid的值是相同的，原因笔者就不再多解释了。另外读者可能在一些网站上见过在最后附加了一段形如jsessionid=xxx的URL，这就是采用URL重写来实现的session。
（图一，首次请求index.jsp）
（图二，再次请求index.jsp）
Cookie和session由于实现手段不同，因此也各有优缺点和各自的应用场景：
1. 应用场景
Cookie的典型应用场景是Remember Me服务，即用户的账户信息通过cookie的形式保存在客户端，当用户再次请求匹配的URL的时候，账户信息会被传送到服务端，交由相应的程序完成自动登录等功能。当然也可以保存一些客户端信息，比如页面布局以及搜索历史等等。
Session的典型应用场景是用户登录某网站之后，将其登录信息放入session，在以后的每次请求中查询相应的登录信息以确保该用户合法。当然还是有购物车等等经典场景；
2. 安全性
cookie将信息保存在客户端，如果不进行加密的话，无疑会暴露一些隐私信息，安全性很差，一般情况下敏感信息是经过加密后存储在cookie中，但很容易就会被窃取。而session只会将信息存储在服务端，如果存储在文件或数据库中，也有被窃取的可能，只是可能性比cookie小了太多。
Session安全性方面比较突出的是存在会话劫持的问题，这是一种安全威胁，这在下文会进行更详细的说明。总体来讲，session的安全性要高于cookie；
3. 性能
Cookie存储在客户端，消耗的是客户端的I/O和内存，而session存储在服务端，消耗的是服务端的资源。但是session对服务器造成的压力比较集中，而cookie很好地分散了资源消耗，就这点来说，cookie是要优于session的；
4. 时效性
Cookie可以通过设置有效期使其较长时间内存在于客户端，而session一般只有比较短的有效期（用户主动销毁session或关闭浏览器后引发超时）；
5. 其他
Cookie的处理在开发中没有session方便。而且cookie在客户端是有数量和大小的限制的，而session的大小却只以硬件为限制，能存储的数据无疑大了太多。
Servlet/JSP中的Session
通过上述的讲解，读者应该对session有了一个大体的认识，但是具体到某种动态页面技术，又是怎么实现session的呢？下面笔者将结合session的生命周期（lifecycle），从源代码的层次来具体分析一下在servlet/jsp技术中，session是怎么实现的。代码部分以tomcat6.0.20作为参考。
创建
在我问过的一些从事java web开发的人中，对于session的创建时机大都这么回答：当我请求某个页面的时候，session就被创建了。这句话其实很含糊，因为要创建session请求的发送是必不可少的，但是无论何种请求都会创建session吗？错。我们来看一个例子。
众所周知，jsp技术是servlet技术的反转，在开发阶段，我们看到的是jsp页面，但真正到运行时阶段，jsp页面是会被“翻译”为servlet类来执行的，例如我们有如下jsp页面：
