HTTP 協議是無狀態的。

• 即服務器對于客戶端每次發送的請求都認為它是一個新的請求。
• 本次請求和上次請求無法判斷是不是同一個客戶端操作的。

隨著 Web 應用的發展，如在線購物網站，需要登錄的網站等，馬上就面臨一個問題，那就是要管理會話，必須記住哪些用戶登錄了系統，哪些用戶往自己的購物車中放了商品， 也就是說必須把每個用戶區分開。

---

session 機制

• session 是一種記錄服務器和客戶端會話狀態的機制。
• session 主要用來存儲所有訪問過該服務端的客戶端的用戶信息（也可以存儲其他信息），從而實現保持用戶會話狀態。
• session 是基于 cookie 實現的，session 存儲在服務器端，sessionid 會被存儲到客戶端的 cookie 中。

注：cookie 是瀏覽器訪問服務器后，服務器傳給瀏覽器的一段數據(key-value)

cookie 特點：

• cookie 存放在客戶端
• cookie 有個數限制(不同瀏覽器的cookie個數不等) ，
• cookie 大小一般是4K，
• cookie 可設置失效時間(如果沒設置，默認是關閉瀏覽器時失效)，
• cookie 是不可跨域的(當前域名下有效)。

session 工作流程

• 瀏覽器在第一次訪問服務器時，服務器會創建一個 session，代表用戶的一次會話過程，服務器會為每一個 session 都分配一個唯一的 sessionid，以保證每個用戶都有一個不同的session 對象。
• 服務器在創建完 session 后，同時會創建一個特殊的 cookie（name為JSESSIONID，value為sessionid），并將該 cookie 發送至瀏覽器端。
• 當用戶向服務器發送新的請求時，瀏覽器會攜帶這個 cookie 對象，把 sessionid 傳回給服務器，服務器根據 sessionid 找到與該用戶對應的 session 對象，從而區分不同用戶。

session 登錄驗證機制

用戶在登錄認證成功之后，并且往 session 對象里面放入了用戶登錄成功的憑證，才能用來進行真正意義上的管理會話。

session 機制存在的不足

• 開銷問題：服務端需要保存每個用戶的 session 信息，當用戶越來越多時，內存的開銷也會不斷增加；
• 持久化問題：解決重啟服務器后session就消失的問題。在數據庫中存儲 session，而不是存儲在內存中；
• CORS問題（跨域共享）：在服務器A上登錄， sessionid 保存在A上，假設下一次請求被轉發到服務器B怎么辦？會限制了服務器擴展能力；
• CSRF問題（跨站請求偽造）：session 偽造/劫持等安全性問題。

---

token 驗證機制

token 是服務端生成的一串字符串，作為客戶端進行請求的一個令牌。

• token 認證流程：
• 客戶端使用用戶名跟密碼請求登錄
• 服務端收到請求，去驗證用戶名與密碼
• 驗證成功后，服務端會簽發一個 token 并把這個 token 發送給客戶端
• 客戶端收到 token ，會把它存儲起來，如存放在 cookie 或 localStorage 中
• 客戶端每次向服務端請求資源的時候需要帶著服務端簽發的 token(注：token 放到 HTTP 請求的 Header 里)
• 服務端收到請求，然后去驗證客戶端請求中的 token ，如果驗證成功，就向客戶端返回請求的數據。

token 驗證流程圖示

token 驗證流程

token 數字簽名

token 機制優點

• 服務端無狀態：服務端不存儲 token 信息， token 存在客戶端中。
• 可擴展性好：不存儲 session 信息，負載均衡器能夠將用戶信息從一個服務傳到其他服務器上。
• 支持跨域訪問：CORS(跨域資源共享)
• 安全性：token 通過HTTP header傳送，防止CSRF(跨站請求偽造)
• 基于標準：如JWT標準。JSON Web Token，最流行的跨域認證解決方案

總結

以上是生活随笔為你收集整理的[JAVA EE]session 和 token 机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。