今天看到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还是存在的,这样一来的话,服务器就可以知道来自客户端的请求是不是来自同一个流览器了.
==============================
你这里有个误解,当禁用cookie后,浏览器可以接受JSESSIONID,放到浏览器内存里,但是浏览器不能将这个JSESSIONID放在请求头里发送给服务器,所以实现不了会话,用户禁用cookie后,只能用你说的后两种方法
你的认识是对的，我在写这篇blog后，经过查阅资料意识到自己之前的认识有点偏差，但忘记改相应的blog了