Cookie和Session都為了用來儲存狀態資訊，都是儲存客戶端狀態的機制，它們都是為了解決HTTP無狀態的問題而所做的努力。

Session可以用Cookie來實現，也可以用URL回寫的機制來實現。用Cookie來實現的Session可以認為是對Cookie更高階的應用。

3.1.1兩者比較

Cookie和Session有以下明顯的不同點：

1）Cookie將狀態儲存在客戶端，Session將狀態儲存在伺服器端；

2）Cookies是伺服器在本地機器上儲存的小段文字並隨每一個請求傳送至同一個伺服器。Cookie最早在RFC2109中實現，後續RFC2965做了增強。網路伺服器用HTTP頭向客戶端傳送cookies，在客戶終端，瀏覽器解析這些cookies並將它們儲存為一個本地檔案，它會自動將同一伺服器的任何請求縛上這些cookies。Session並沒有在HTTP的協議中定義；

3）Session是針對每一個使用者的，變數的值儲存在伺服器上，用一個sessionID來區分是哪個使用者session變數,這個值是通過使用者的瀏覽器在訪問的時候返回給伺服器，當客戶禁用cookie時，這個值也可能設定為由get來返回給伺服器；

4）就安全性來說：當你訪問一個使用session 的站點，同時在自己機子上建立一個cookie，建議在伺服器端的SESSION機制更安全些.因為它不會任意讀取客戶儲存的資訊。

3.1.2 Session機制

Session機制是一種伺服器端的機制，伺服器使用一種類似於散列表的結構（也可能就是使用散列表）來儲存資訊。

當程式需要為某個客戶端的請求建立一個session的時候，伺服器首先檢查這個客戶端的請求裡是否已包含了一個session標識 - 稱為 session id，如果已包含一個session id則說明以前已經為此客戶端建立過session，伺服器就按照session id把這個 session檢索出來使用（如果檢索不到，可能會新建一個），如果客戶端請求不包含session id，則為此客戶端建立一個session並且生成一個與此session相關聯的session id，session id的值應該是一個既不會重複，又不容易被找到規律以仿造的字串，這個 session id將被在本次響應中返回給客戶端儲存。

3.1.6 Session的實現方式

3.1.6.1  使用Cookie來實現

伺服器給每個Session分配一個唯一的JSESSIONID，並通過Cookie傳送給客戶端。

當客戶端發起新的請求的時候，將在Cookie頭中攜帶這個JSESSIONID。這樣伺服器能夠找到這個客戶端對應的Session。

流程如下圖所示：
    

3.1.6.2  使用URL回顯來實現

URL回寫是指伺服器在傳送給瀏覽器頁面的所有連結中都攜帶JSESSIONID的引數，這樣客戶端點選任何一個連結都會把JSESSIONID帶會伺服器。

如果直接在瀏覽器輸入服務端資源的url來請求該資源，那麼Session是匹配不到的。

Tomcat對Session的實現，是一開始同時使用Cookie和URL回寫機制，如果發現客戶端支援Cookie，就繼續使用Cookie，停止使用URL回寫。如果發現Cookie被禁用，就一直使用URL回寫。jsp開發處理到Session的時候，對頁面中的連結記得使用response.encodeURL() 。

3.1.3在J2EE專案中Session失效的幾種情況

1）Session超時：Session在指定時間內失效，例如30分鐘，若在30分鐘內沒有操作，則Session會失效，例如在web.xml中進行了如下設定：

<session-config> 
        <session-timeout>30</session-timeout> //單位：分鐘
    </session-config>

2）使用session.invalidate()明確的去掉Session。

3.1.4與Cookie相關的HTTP擴充套件頭

1）Cookie：客戶端將伺服器設定的Cookie返回到伺服器；

2）Set-Cookie：伺服器向客戶端設定Cookie；

3）Cookie2 (RFC2965)）：客戶端指示伺服器支援Cookie的版本；

4）Set-Cookie2 (RFC2965)：伺服器向客戶端設定Cookie。

3.1.5Cookie的流程

伺服器在響應訊息中用Set-Cookie頭將Cookie的內容回送給客戶端，客戶端在新的請求中將相同的內容攜帶在Cookie頭中傳送給伺服器。從而實現會話的保持。

流程如下圖所示：