Session的实现与存储

【集群中session安全和同步】

 

使用数据库来保存session,就算服务器宕机了也没事，session照样在。

每次请求都进行数据库读写开销不小(使用内存数据库可以提高性能，宕机就会丢失数据。可供选择的内存数据库有BerkeleyDB,Mysql的内存表);

数据库是一个单点，当然可以做数据库的ha来解决这个问题。

 

 

 

使用共享存储来保存session

和数据库类似,就算服务器宕机了也没事，session照样在。使用nfs或windows文件共享都可以,或者专用的共享存储设备。

问题：

程序需要定制；

频繁的进行数据的序列化和反序列化，性能是否有影响；

共享存储是一个单点，这个可以通过raid来解决。

 

 

使用memcached来保存session

这种方式跟数据库类似，不过因为是内存存取的，性能自然要比数据库好多了。

问题：

程序需要定制,增加了工作量；

存入memcached中的数据都需要序列化，效率较低；

memcached服务器一死，所有session全丢。memchached能不能做HA? 我也不知道，网站上没提。

 

 

用于保持HTTP连接状态的技术：Cookie和Session。

 

Cookie是客户端保存状态的解决方案，Cookie就是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。Cookie一般是放在http header中的。比如user id, user name, user的身份信息，user school, user company等.当然服务端也会保留这些Cookie信息的，并且可以给这些Cookie添加额外的属性，如过期时间等。

 

​

Session是服务器来保持状态的解决方案。 客户端浏览器与服务器之间一系列交互的动作称为一个Session，其不仅包含Session持续的时间，还包括操作，还有服务器端为客户端所开辟的存储空间，在 其中保存的信息就是用于保持状态。

 

服务器收到客户端请求时，会为该Session生成唯一的Session id，在Session被创建之后，就可以调用Session相关的方法往Session中增加内容了，而这些内容只会保存在服务器中， 发到客户端的只有Session id；

 

当客户端再次发送请求的时候，会将这个Session id带上，服务器接受到请求之后就会依据Session id找到相应的Session，从而再次使用之。这样用户先前的状态或请求也就得以保持了。

 

---

假设Web Server是一个商场的存包处，HTTP Request是一个顾客，第一次来到存包处，管理员把顾客的物品存放在某一个柜子里面（这个柜子就相当于Session），然后把一个号码牌交给这个顾客，作为取包凭证（这个号码牌就是Session ID）。

顾客（HTTP Request）下一次来的时候，就要把号码牌（Session ID）交给存包处（Web Server）的管理员。管理员根据号码牌（Session ID）找到相应的柜子（Session），根据顾客（HTTP Request）的请求，Web Server可以取出、更换、添加柜子（Session）中的物品，Web Server也可以让顾客（HTTP Request）的号码牌和号码牌对应的柜子（Session）失效。

顾客（HTTP Request）的忘性很大，管理员在顾客回去的时候（HTTP Response）都要重新提醒顾客记住自己的号码牌（Session ID）。这样，顾客（HTTP Request）下次来的时候，就又带着号码牌回来了。

Session ID实际上是在客户端和服务端之间通过HTTP Request和HTTP Response传来传去的。号码牌（Session ID）必须包含在HTTP Request里面。关于HTTP Request的具体格式，请参见HTTP协议（ http://www.w3.org/Protocols/）。  

【几种Session同步方案】

当一个用户提交表单时，浏览器将用户SessionId自动附加在HTTP头信息中。

 

集群中session安全和同步是个最大的问题，下面是我收集到的几种session同步的方案，希望能通过分析其各自的优劣找出其适应的场景。

1. 客户端cookie加密

这是我以前采用的方式，简单，高效。比较好的方法是自己采用cookie机制来实现一个session,在应用中使用此session实现。

问题：session中数据不能太多，最好只有个用户id。参考实现：http://rollerweblogger.org/

 

 

2. application server的session复制

可能大部分应用服务器都提供了session复制的功能来实现集群，tomcat,jboss,was都提供了这样的功能。

问题：性能随着服务器增加急剧下降，而且容易引起广播风暴；

session数据需要序列化，影响性能。

3. 使用数据库保存session

使用数据库来保存session,就算服务器宕机了也没事，session照样在。

问题：

程序需要定制；

每次请求都进行数据库读写开销不小(使用内存数据库可以提高性能，宕机就会丢失数据。可供选择的内存数据库有BerkeleyDB,Mysql的内存表);

数据库是一个单点，当然可以做数据库的ha来解决这个问题。

4. 使用共享存储来保存session

和数据库类似,就算服务器宕机了也没事，session照样在。使用nfs或windows文件共享都可以,或者专用的共享存储设备。

问题：

程序需要定制；

频繁的进行数据的序列化和反序列化，性能是否有影响；

共享存储是一个单点，这个可以通过raid来解决。

5. 使用memcached来保存session

这种方式跟数据库类似，不过因为是内存存取的，性能自然要比数据库好多了。

问题：

程序需要定制,增加了工作量；

存入memcached中的数据都需要序列化，效率较低；

memcached服务器一死，所有session全丢。memchached能不能做HA? 我也不知道，网站上没提。

参考资料:

应用memcached保存session会话信息

正确认识memcached的缓存失效

扩展Tomcat 6.x，使用memcached存放session信息

6. 使用terracotta来保存session

跟memcached类似，但是数据不需要序列化，并且是Find-Grained Changes，性能更好。配置对原来的应用完全透明，原有程序几乎不用做任何修改。而且terracotta本身支持HA。

问题：

terracotta的HA本身进行数据复制性能如何？

参考资料：

JVM-level clustering

Terracotta集群Tomcat实现Session同步

使用Terracotta和Tomcat建立ACTIVE-PASSIVE模式的集群

用Spring Web Flow和Terracotta搭建Web应用

Terracotta实战示例——集群RIFE

Terracotta近况：转向开源，接受度，Hibernate支持

【Session介绍】【http://blog.csdn.net/zhll3377/article/details/7640452】
由于HTTP协议连接的无状态性，才使得session的不得已而产生。

既然Web应用并不了解有关同一用户以前请求的信息，那么解决这个问题的一个办法是使用Servlet/JSP容器提供的会话跟踪功能，Servlet API规范定义了一个简单的HttpSession接口，通过它我们可以方便地实现会话跟踪。

HttpSession接口提供了存储和返回标准会话属性的方法。标准会话属性如会话标识符、应用数据等，都以“名字-值”对的形式保存在服务器端。也就是说，HttpSession接口提供了一种把对象保存到内存、在同一用户的后继请求中提取这些对象的标准办法。在会话中保存数据的方法是setAttribute(String s, Object o)，从会话提取原来所保存对象的方法是getAttribute(String s)。

在服务器端，每当新用户请求了一个使用HttpSession对象的JSP页面，Servlet、JSP容器除了发回应答页面外，它还要以cookie的形式向浏览器发送一个特殊数字，即“绘画标识符”，它是一个唯一的用户标示符，浏览器在请求session时，服务器会先得到它的sessionId，再做处理。

会话标识符以Cookie的形式在服务器和浏览器组件传送，标准会话属性在服务器端也是以会话的形式存在，并且这个Cookie的生命周期只是临时的，即会话结束后就自动消失，没有为它指定固定的生命周期，因此可以说session是基于Cookie的技术。另外，如果客户端不支持Cookie，运用URL重写机制来保证会话标识回服务器。

session机制是一种服务器端的机制，用来在无状态的HTTP协议下越过多个请求页面来维持状态和识别用户。

当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识。这个标识称为session id。

如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用。

若没有创建过，则创建一个新的Session。

【保存session id 的方法】
cookie可以被人为的禁止，必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径。

Session 的致命弱点是不容易在多台服务器之间共享。

实际上有三种方式能可以让 Session 正常工作：
1.基于 URL Path Parameter，默认就支持
2.基于 Cookie，如果你没有修改 Context 容器个 cookies 标识的话，默认也是支持的
3.基于 SSL，默认不支持，只有 connector.getAttribute("SSLEnabled") 为 TRUE 时才支持

第一种情况下，当浏览器不支持 Cookie 功能时，浏览器会将用户的 SessionCookieName 重写到用户请求的 URL 参数中，它的传递格式如 /path/Servlet;name=value;name2=value2? Name3=value3，其中“Servlet；”后面的 K-V 对就是要传递的 Path Parameters，服务器会从这个 Path Parameters 中拿到用户配置的 SessionCookieName。关于这个 SessionCookieName，如果你在 web.xml 中配置 session-config 配置项的话，其 cookie-config 下的 name 属性就是这个 SessionCookieName 值，如果你没有配置 session-config 配置项，默认的 SessionCookieName 就是大家熟悉的“JSESSIONID”。接着 Request 根据这个 SessionCookieName 到 Parameters 拿到 Session ID 并设置到 request.setRequestedSessionId 中。

请注意如果客户端也支持 Cookie 的话，Tomcat 仍然会解析 Cookie 中的 Session ID，并会覆盖 URL 中的 Session ID。

如果是第三种情况的话将会根据 javax.servlet.request.ssl_session 属性值设置 Session ID。

有了 Session ID 服务器端就可以创建 HttpSession 对象了，第一次触发是通过 request. getSession() 方法，如果当前的 Session ID 还没有对应的 HttpSession 对象那么就创建一个新的，并将这个对象加到 org.apache.catalina. Manager 的 sessions 容器中保存，Manager 类将管理所有 Session 的生命周期，Session 过期将被回收，服务器关闭，Session 将被序列化到磁盘等。只要这个 HttpSession 对象存在，用户就可以根据 Session ID 来获取到这个对象，也就达到了状态的保持。

session中的一些问题
    (1)、session在何时被创建
　　一个常见的误解是以为session在有客户端访问时就被创建，然而事实是直到某server端程序调用 HttpServletRequest.getSession(true)这样的语句时才被创建，注意如果JSP没有显示的使用 <%@pagesession="false"%> 关闭session，则JSP文件在编译成Servlet时将会自动加上这样一条语句HttpSession session = HttpServletRequest.getSession(true);这也是JSP中隐含的session对象的来历。
　　由于session会消耗内存资源，因此，如果不打算使用session，应该在所有的JSP中关闭它。
　(2)、session何时被删除
　　综合前面的讨论，session在下列情况下被删除a.程序调用HttpSession.invalidate();或b.距离上一次收到客户端发送的session id时间间隔超过了session的超时设置;或c.服务器进程被停止（非持久session）
　(3)、如何做到在浏览器关闭时删除session
　　严格的讲，做不到这一点。可以做一点努力的办法是在所有的客户端页面里使用网页特效代码window.onclose来监视浏览器的关闭 动作，然后向服务器发送一个请求来删
除session。但是对于浏览器崩溃或者强行杀死进程这些非常规手段仍然无能为力。
　(4)、有个HttpSessionListener是怎么回事
　　你可以创建这样的listener去监控session的创建和销毁事件，使得在发生这样的事件时你可以做一些相应的工作。注意是 session的创建和销毁动作触发listener，而不是相反。类似的与HttpSession有关的listener还有 HttpSessionBindingListener，HttpSessionActivationListener和 HttpSessionAttributeListener。
　(5)、存放在session中的对象必须是可序列化的吗
　　不是必需的。要求对象可序列化只是为了session能够在集群中被复制或者能够持久保存或者在必要时server能够暂时把session交换出内 存。在Weblogic Server的session中放置一个不可序列化的对象在控制台上会收到一个警告。我所用过的某个iPlanet版本如果session中有不可序列化 的对象，在session销毁时会有一个Exception，很奇怪。
　(6.)、如何才能正确的应付客户端禁止cookie的可能性
　　对所有的URL使用URL重写，包括超链接，form的action，和重定向的URL，具体做法参见[6]http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770
　(7.)、开两个浏览器窗口访问应用程序会使用同一个session还是不同的session
　　参见第三小节对cookie的讨论，对session来说是只认id不认人，因此不同的浏览器，不同的窗口打开方式以及不同的cookie存储方式都会对这个问题的答案有影响。
    (8.)、如何防止用户打开两个浏览器窗口操作导致的session混乱
　　这个问题与防止表单多次提交是类似的，可以通过设置客户端的令牌来解决。就是在服务器每次生成一个不同的id返回给客户端，同时保存在 session里，客户端提交表单时必须把这个id也返回服务器，程序首先比较返回的id与保存在session里的值是否一致，如果不一致则说明本次操 作已经被提交过了。可以参看《J2EE核心模式》关于表示层模式的部分。需要注意的是对于使用javascript window.open打开的窗口，一般不设置这个id，或者使用单独的id，以防主窗口无法操作，建议不要再window.open打开的窗口里做修改 操作，这样就可以不用设置。
      (9.)、为什么在Weblogic Server中改变session的值后要重新调用一次session.setValue做这个动作主要是为了在集群环境中提示Weblogic Server session中的值发生了改变，需要向其他服务器进程复制新的session值。
　(10)、为什么session不见了
　　排除session正常失效的因素之外，服务器本身的可能性应该是微乎其微的，虽然笔者在iPlanet6SP1加若干补丁的Solaris版本上倒 也遇到过；浏览器插件的可能性次之，笔者也遇到过3721插件造成的问题；理论上防火墙或者代理服务器在cookie处理上也有可能会出现问题。
　　出现这一问题的大部分原因都是程序的错误，最常见的就是在一个应用程序中去访问另外一个应用程序。

关于Session和Cookie的关系，这里详细分析一些
1.Cookie
Cookie是服务器在本地机器上存储的小段文本，它是一个简单的字符串形式的键值对。
网络服务器用HTTP头向客户端发送cookie，
(一般情况下Cookie是由服务端生成的，当然js也能操作cookie)
在客户端，浏览器解析这些cookies并将它们保存到本地，
而后当浏览器访问这个服务器时，它会在任何请求上加上这些cookie。
说白了就是每次你和服务器的交互都会带着这些cookie。
2.Cookie 与Session的关系
我们知道session是在服务端的，http又是无状态协议，而seesion又是靠session id来区分的，
因此为了传递session id让服务器识别，这个session id就存放在了cookie中。
（另一种方式是将session id放到url后面，后面我会提到）
因为每次向服务器发送请求时，http头都会带着cookie，
所以服务端就很方便地根据cookie读取出来的session id来区分各个请求的session。
比如我现在访问我测试用的servlet，在servlet代码中写上
HttpSession session = request.getSession();这样我就能建立一个session了。
用火狐访问，查看firebug的网络信息，我们可以发现他的响应信息中有
Set-Cookie JSESSIONID=5A810D07A1FB78122FFC2A74CA04F255; Path=/Test01/; HttpOnly
这些字样，这说明访问服务器的时候，服务端把seesion id写入到了cookie，
让客户端浏览器把cookie保存起来。
到这里我们似乎可以发现些什么，不知道你看到没有？
发送请求的时候带着cookie信息，
从响应信息里我们又看到了让浏览器设置cookie的信息，
发送请求 响应
从而我们可以得出，在servlet中，想获得cookie，我们需要从request中取，
下面这段代码就可以在控制台中把客户端过来的cookie信息都打印出来。
Cookie[] cs=request.getCookies();
for(int i=0;i<cs.length;i++){
  System.out.println(cs[i].getName());
  System.out.println(cs[i].getValue());
}而当你想添加cookie时就得往response里添加。
Cookie c = new Cookie("mycookie","cookie1234");
c.setMaxAge(3000);//设置cookie有效期， 单位为秒
response.addCookie(c);添加了这个cookie后，你会在刚才控制台的cookie打印中看到你这个mycookie信息。
3. 当客户端禁用了Cookie时，如何识别各个session
其实servlet中可以重写url，让他在url后面加上
;jsessionid=52156A910E95E259B6A2C13CC4DAA916
来识别。
我们可以在servlet中写上response.encodeURL(“test”)，这样的话，
当session建立的时候，而客户端不支持cookie，则编码后的url为
test;jsessionid=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
若session没有建立，则编码后的url仍旧为test
当然如果session建立，客户端支持cookie的话，那么编码后的url也为test。
4.内存Cookie和普通Cookie的区别：
Session的是以cookie或URL重写实现的，默认是cookie来实现的。
系统会创造一个名为JSESSIONID的输出cookie，这种Cookie叫做session cookie，
这个session cookie有区别persistent cookies，也就是我们通常所说的普通的cookie。

特别值得注意的时：
session cookie是存储于浏览器内存中的，即所谓的内存cookie，并不是写到硬盘上的，
而普通的cookie则是存在硬盘上的。
我们刚才看到的JSESSIONID就是一个session cookie，我们通常情是看不到JSESSIONID的，
但是当我们把浏览器的cookie禁止后，web服务器会采用URL重写的方式传递session id，
我们就可以在地址栏看到JSESSIONID=XXXXXXXXXXXXXXXXXXXX之类的字符串了。
明白了这个，我们就可以很容易的分辨出persistent cookies和session cookie的区别了。
另外关于两者安全性也就很清楚了：
session cookie针对某一次会话而言，会话结束session cookie也就随着消失了；
而persistent cookie只是存在于客户端硬盘上的一段文本，
可以在服务端建立cookie时来设置任意有效期，
而且可能会遭到cookie欺骗以及针对cookie的跨站脚本攻击，
自然不如session cookie安全了。