[推薦]session原理詳解

關於HttpSession的誤解實在是太多了，本來是一個很簡單的問題，怎會搞的如此的複雜呢？下面說說我的理解吧：
1、HTTP協議本身是“串連-請求-應答-關閉串連”模式的，是一種無狀態協議（HTTP只是一個傳輸協議）；
2、Cookie規範是為了給HTTP增加狀態跟蹤用的（如果要精確把握，建議仔細閱讀一下相關的RFC），但不是唯一的手段；
3、所謂Session，指的是用戶端和服務端之間的一段互動過程的狀態資訊（資料）；這個狀態如何界定，生命期有多長，這是應用本身的事情；
4、由於B/S計算模型中計算是在伺服器端完成的，用戶端只有簡單的顯示邏輯，所以，Session資料對用戶端應該是透明的不可理解的並且應該受控於服務端；Session資料要麼儲存到服務端（HttpSession），要麼在用戶端和服務端之間傳遞（Cookie或url rewritting或Hidden input）；
5、由於HTTP本身的無狀態性，服務端無法知道用戶端相繼發來的請求是來自一個客戶的，所以，當使用服務端HttpSession儲存會話資料的時候用戶端的每個請求都應該包含一個session的標識(sid, jsessionid 等等)來告訴服務端；
6、會話資料儲存在服務端（如HttpSession）的好處是減少了HTTP請求的長度，提高了網路傳輸效率；用戶端session資訊儲存則相反；
7、用戶端Session儲存只有一個辦法：cookie(url rewritting和hidden input因為無法做到持久化，不算，只能作為交換session id的方式，即a method of session tracking)，而服務端做法大致也是一個道理：容器有個session管理器（如tomcat的org.apache.catalina.session包裡面的類），提供session的生命週期和持久化管理並提供訪問session資料的api；
8、使用服務端還是用戶端session儲存要看應用的實際情況的。一般來說不要求使用者註冊登入的公用服務系統（如google）採用cookie做用戶端session儲存（如google的使用者喜好設定），而有使用者管理的系統則使用服務端儲存。原因很顯然：無需使用者登入的系統唯一能夠標識使用者的就是使用者的電腦，換一台機器就不知道誰是誰了，服務端session儲存根本不管用；而有使用者管理的系統則可以通過使用者id來系統管理使用者個人資料，從而提供任意複雜的個人化服務；
9、用戶端和服務端的session儲存在效能、安全性、跨站能力、編程方便性等方面都有一定的區別，而且優劣並非絕對（譬如TheServerSide號稱不使用HttpSession，所以效能好，這很顯然：一個具有上億的訪問使用者的系統，要在服務端資料庫中檢索出使用者的偏好資訊顯然是低效的，Session管理器不管用什麼資料結構和演算法都要耗費大量記憶體和CPU時間；而用cookie，則根本不用檢索和維護session資料，伺服器可以做成無狀態的，當然高效）；
所謂的“會話cookie”簡單的說就是沒有明確指明有效期間的cookie，僅在瀏覽器當前進程生命期內有效，可以被後繼的Set-Cookie操作清除掉；holykeeper還是很有敬業精神的！記得3年前偶剛剛開始做J2EE的時候就做過同樣的事情，不過我用的是Effetech HTTP Sniffer和Charles HTTP Proxy，另外，我一口氣把HTTP RFC 2616，Cookie RFC，URI & URL，MIME等十多個與Web相關的協議標準通讀了一遍，在之後的工作中就再也沒有被具體的技術問題糾纏過。