session

1.Session

由于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重写机制来保证会话标识回服务器。

2.session机制的实现：

 
(1.)session机制是一种服务器端的机制，
用来在无状态的HTTP协议下越过多个请求页面来维持状态和识别用户。
当程序需要为某个客户端的请求创建一个session的时候，
服务器首先检查这个客户端的请求里是否已包含了一个session标识。

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

那么这个session是什么时候创建的呢？
之前一直错误地理解为：
当用户向服务器发起请求时，这个session便会立刻建立起来，
但实际上却根本不是这样。

在Servlet中，你肯定用过下面这句话，

HttpSession session = request.getSession();如果当前没有session，则会立刻建立一个session；
如果有session则返回当前session。

这句话和

HttpSession session = request.getSession(true);的效果是一样的。

但是如果你写成

HttpSession session = request.getSession(false);则不会自动建立session。
若当前没有session，你所得到的seesion只会是一个null。

总结：
session不是一打开网站就会立刻建立。
它的建立需要基于下面两个条件中的任意一个：

   a：在servlet中手动调用

HttpSession session = request.getSession();或者

HttpSession session = request.getSession(true);2：jsp中没有写
(默认情况下它是的)

如果两个条件同时都不满足，那么你建立的只是一个无seesion的连接。

 

(2.) session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。 
      当程序需要为某个客户端的请求创建一个session的时候，

第一步： 
      服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为session id， 
此时就是两种可能，客户机有session id或者没有session id

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

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

的后面。

3.session与Cookie的实现原理

Session 与 Cookie 的作用都是为了保持访问用户与后端服务器的交互状态。它们有各自的优点也有各自的缺陷。然而具有讽刺意味的是它们优点和它们的使用场景又是矛盾的，例如使用 Cookie 来传递信息时，随着 Cookie 个数的增多和访问量的增加，它占用的网络带宽也很大，试想假如 Cookie 占用 200 个字节，如果一天的 PV 有几亿的时候，它要占用多少带宽。所以大访问量的时候希望用 Session，但是 Session 的致命弱点是不容易在多台服务器之间共享，所以这也限制了 Session 的使用。

不管 Session 和 Cookie 有什么不足，我们还是要用它们。下面详细讲一下，Session 如何基于 Cookie 来工作。实际上有三种方式能可以让 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 关联的 Cookie 与其它 Cookie 没有什么不同，这个配置的配置可以通过 web.xml 中的 session-config 配置项来指定。

4.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安全了。