前言

最近寫的專案是和使用者許可權與認證有關，所以學習了很多有關 Cookie、Session 以及 Token 的相關知識，在這裡做一個梳理。本文包括基礎概念、區別與聯絡。

Session

基礎概念

“會話控制”。Session 物件儲存特定使用者會話所需的屬性及配置資訊於伺服器中。這樣，當用戶在應用程式的 Web 頁之間跳轉時，儲存在 Session 物件中的變數將不會丟失。其實現方式有很多種，JDK有自己的實現，大家也可以根據不同的業務場景設計不同資料結構的session。

抽象理解

可以抽象理解為，session就是在伺服器的記憶體中放了一個盒子，可以在這個盒子中存放瀏覽器需要在頁面跳轉中持續儲存的資訊。

問題

伺服器是如何辨析不同請求屬於哪些的session呢？

在伺服器中，不同的 session 具有不同的 sessionid。在伺服器傳送響應報文的同時，將瀏覽器請求的 sessionid 放在 cookie 或 url 中進行回傳。之後，瀏覽器每次請求時都要帶著 sessionid，伺服器透過 sessionid 來進行請求和 session 的配對。 所以說，說瀏覽器或主機擁有自己的 session，這個說法是不準確的，因為只要拿到了 sessionid，就可以在伺服器訪問相應的 session。

Cookie

基礎概念

Cookie，有時也用其複數形式 Cookies。型別為“小型文字檔案”，是某些網站為了辨別使用者身份，進行Session跟蹤而儲存在使用者本地終端上的資料（通常經過加密），由使用者客戶端計算機暫時或永久儲存的資訊。

抽象理解

和 session 差不多，可以抽象理解為，cookie就是在客戶端本地放了一個小盒子，來存放伺服器相應的資訊。

問題

cookie 一般都存放什麼資訊？

因為 cookie 是存放在本地的小型文字檔案，非常容易被篡改。所以一般放在 cookie 中的資訊都是被加密過的 “id” 型資訊，或者非敏感型的資訊。

Token

基礎概念

token的意思是“令牌”，是使用者身份的驗證方式，最簡單的token組成：uid(使用者唯一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽以雜湊演算法壓縮成一定長的十六進位制字串，可以防止惡意第三方拼接token請求伺服器)。

抽象理解

與前兩者不同，token 可以理解為放在盒子裡的資訊。就像是現在如果我們要進入一棟大樓，根據身份的不同，訪客所能訪問的樓層也就不同。所以在進入大樓前，每一個訪客都需要辦理身份認證，這個身份認證就可以理解為 token。

問題

我們什麼時候會需要 token ？

一般在做後臺管理系統時候，token 的運用比較多。因為後臺管理系統涉及到很多角色的劃分，不同的角色所能訪問資源的範圍也不同。因此客戶端每次訪問伺服器時，伺服器都會驗證 token 的有效性，以此來檢驗使用者的登陸狀態。

區別與聯絡

Cookie 與 Session

它們的區別其實很明顯，cookie是存放在客戶端本地的 “盒子”，session是存放在伺服器的 “盒子”，本質都是用來記錄使用者的相關資訊，來保證會話的一個連續性。在上面的敘述中也不難看到，cookie 與 session 是可以一起使用的，在客戶端用 cookie 來記錄 sessionid（如果瀏覽器支援的話），在伺服器端用 session 來儲存使用者的資訊或登陸狀態。

Session 與 Token

如果 session 與 token 分別使用的話，token 相較與 session 可以用效率換取更多的空間，session 則是由於不需要解碼，所以是用空間換取更多的效率。

使用 Token 進行使用者認證時，伺服器是不需要一直儲存使用者會話狀態的。因為每一個客戶端請求都會在協議頭或其他地方帶上 token，伺服器拿到 token 後解碼獲取相關資訊。這個流程是怎樣的，感興趣的同學可以翻一下我之前的文章。

使用 Session 時，顯而易見速度是塊於 token 的，但也可能會因為保持的客戶端會話過多而導致記憶體不足。

擴充套件

實際上，目前越來越流行的做法是，session 與 token 組合使用，並且從使用之前 JDK 自有的 session，轉換為 redis 這樣的 nosql 快取。如此一來，在業務上使用的資料結構可以更貼合場景，在技術上擴充套件性和效能也得到了提升。

參考文章

https://blog.csdn.net/qq_1290259791/article/details/81193914