今天看到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了