Tomcat session 实现

loyalxuan

今天看到rails 的session 实现方式时,突然对Tomcat的session 实现方式也产生了好奇心.

  一般会认为客户端在第一次访问Web容器时，容器会创建一个Session，这个Session被添加到一个Map 里，由容器负责维护。这个大家都很清楚，也很容易理解。但是关键是如何与客户端浏览器交换这个SessionId 的信息，很多书都提到有三种方式：cookie、URL重写、和隐藏表单，后两种是类似的。

如果是第一种，那么Sessionid被关联到一个浏览器一关闭就失效的cookie里，然后客户端浏览器每次用这个cookie来标示会话。注意这些都是Web容器替我们完成的。

如果是URL重写，则每个请求字符串后面会被附加如;jsessionid=XXXXXXXXX这样的标示，用于标示会话。

  容器何时决定使用哪一种方法？

我找了一个Winsock Expert的软件来监测IE 浏览器发送和接收的信息，IE的版本为6.0，Tomcat的版本为5.0.19，结果如下：当IE浏览器向Tomcat第一次发出请求时，
不包含任何Cookie信息，当然这是第一次访问这个站点。为了比对Cookie的内容，我在访问的index.jsp页面中使用了response.setCookie向响应放了一个名为newCookie的Cookie。

最后监测的结果如下，除了用户自定义的newCookie之外，还有一个名为JSESSIONID的Cookie被加入了响应。

在接下来的请求中，都包含了JSESSIONID这个Cookie，在请求内容中能清楚的看到这一点：

但是，如果用request.getCookies是无法看到JSESSIONID这个Cookie的，只能看到我自定义的那个newCookie，JSESSIONID这个Cookie被Tomcat隐藏起来了，对于编程人员来说，是不可见的（我无法使用${cookie.JSESSIONID.name}或是${cookie.JSESSIONID.value}来检查它的名称和值，虽然这些对我来说都是已知的）。

得出如下结论：如果客户端禁用cookie，就用jsessionid,它的内容不写在硬盘,而是被ie缓存在内存了,即便客户端禁用了cookie,jsessionid还是存在的,这样一来的话,服务器就可以知道来自客户端的请求是不是来自同一个流览器了.