【網絡通信與信息安全】之深入分析Token、session和cookie的使用場景和區別

在 Web 開發領域，相信大家對于 Cookie 和 Session 都很熟悉，Cookie 和 Session 都是會話保持技術的解決方案。隨著技術的發展，Token 機制出現在我們面前，不過很多開發者對于 Token 和 Cookie、Session 的區別及使用場景分辨不清。

首先要知道HTTP請求是無狀態的，也就是不知道這一次的請求和上一次請求是否有關系，比如我們登錄一個系統的時候，驗證用戶名密碼之后，打開系統各個頁面的時候就不需要再進行登錄操作了，直到我們主動退出登錄或超時退出登錄；這里為了避免訪問每個都登錄一下，就要用到 session、cookie；

cookie 是在客戶端(瀏覽器)保存用戶信息的一種機制；而且每種瀏覽器存儲大小會有一些差異，一般不超過4KB；

session是在服務端保存，可以用于記錄客戶狀態，比如我們經常會用 session 保存客戶的基本信息、權限信息等；用戶第一次登錄之后，服務器就會創建一個 session，瀏覽器再次訪問時，只需要從該 session 中查找該客戶的信息就可以了。

要知道我們訪問網站都是通過 HTTP 協議或 HTTPS 協議來完成的，HTTP 協議它本身是無狀態的協議（即：服務器無法分辨哪些請求是來源于同個客戶）。而業務層面會涉及到客戶端與服務器端的交互（同網站下多個頁面間能共享數據），此時服務器端必須要保持會話狀態，這樣才能進行用戶身份的鑒別。

由于 HTTP 無狀態的特性，如果要實話客戶端和服務器端的會話保持，那就需要其它機制來實現，于是 Cookie 和 Session 應運而生。

通常情況下，Session 和 Cookie 是搭配在一起使用的。

在這里會有個問題，服務器要保存所有用戶的 session 信息，開銷會很大，如果在分布式的架構下，就需要考慮 session 共享的問題，需要做額外的設計和開發，例如把 session 中的信息保存到 Redis 中進行共享；所以因為這個原因，有人考慮這些信息是否可以讓客戶端保存，可以保存到任何地方，并且保證其安全性，于是就有了Token。

Token 是服務端生成的一串字符串，可以看做客戶端進行請求的一個令牌。

當客戶端第一次訪問服務端，服務端會根據傳過來的唯一標識 userId，運用一些加密算法，生成一個 Token，客戶端下次請求時，只需要帶上 Token，服務器收到請求后，會驗證這個 Token。

有些公司會建設統一登錄系統（單點登錄），客戶端先去這個系統獲取 Token，驗證通過再拿著這些 Token 去訪問其他系統；API Gateway 也可以提供類似的功能，我們公司就是這樣，客戶端接入的時候，先向網關獲取 Token，驗證通過了才能訪問被授權的接口，并且一段時間后要重新或者 Token。

Token 俗稱為“令牌”，它的構成是：

uid：用戶唯一身份標識；

timestamp：當前時間戳；

sign：簽名字符串，防止第三方偽造數據；簽名密鑰是存儲在服務器端的，其它人無法知道；

其它附加參數。

客戶端使用用戶名、密碼做身份驗證；

服務端收到請求后進行身份驗證(也可能是統一登錄平臺、網關)；

驗證成功后，服務端會簽發一個 Token 返回給客戶端；

客戶端收到 Token 以后可以把它存儲起來（可以放在）；每次向服務端發送請求的時候，都要帶著 Token；

Token 會有過期時間，過期后需要重新進行驗證；

服務端收到請求，會驗證客戶端請求里面的 Token，驗證成功，才會響應客戶端的請求；

cookie：

保存在瀏覽器中，有大小限制，有狀態；

由于存放在客戶端，所以是不安全的，人為可以清除；

cookie 有過期時間設定，如果不設置過期時間，說明這個 cookie 就是當前瀏覽器的會話時間，瀏覽器關了，cookie 就存在了。如果有過期時間，cookie 就會存儲到硬盤上，瀏覽器關閉不影響 cookie。下次打開瀏覽器，cookie 還存在；

cookie 有大小的限制，4KB。

session：保存在服務器中，服務器有資源開銷，分布式、跨系統不好實現；

Token：客戶端可以將 Token 保存到任何地方，無限制，無狀態，利于分布式部署。

網絡

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。