使用場景有什么區別？

萬維網（www：World Wide Web）的誕生起源自1990年12月15日蒂姆·伯納斯·李利用網際網絡實現了超文本傳輸協議（http：Hyper Text Transfer Protocol）客戶端和服務器的第一次通訊。

http是運行在TCP之上的一種簡單的請求、響應協議，所謂的協議就是形成了固有的套路，客戶端指定向服務器發送什么信息，然后服務器就會做出與之對應的回應。

舉個例子：GET、POST、HEAD等方法中，post一般用于客戶端提交表單數據給服務器，或者上次文件給服務器，而head、get則是獲取URL中指定的資源。在使用get時請求的參數、值需要附加在URI(URI時URL的一種擴張，在HTTP協議中URI一般都是指URL)后面，利用"?"將資源的URI和請求參數、值隔離開來，參數、值之間使用“&”隔開。

萬維網的發展歷史要徹底理解session、cookie、token之間的區別，就不得不去翻開過去塵封的歷史。僅30年web發生了翻天覆地的變化。

早期的web其實是非常簡陋的，僅僅實現的是基本的文本瀏覽而已。用寒酸的表格來做框架定位還僅僅是后話。僅僅只是文本和文本包含的超鏈接而已，服務器僅僅只是機械式的請求，然后響應，并不需要記錄誰在某一個時間段里瀏覽了什么內容，也不需要記住是誰發的HTTP請求。

慢慢的網站就需要登錄、留言、發表內容、內容管理、在線購物等等交互，這時web就需要引入會話管理機制，記錄誰登錄了系統，誰又將商品放入了購物車中等等。由于早期的web本身就是無狀態請求，于是有人就想出了一個辦法，給每個訪問的人發一個不會重復的號碼牌，也就是session id（會話標識）。由于session id是服務器發給每個接收端的一串隨機字符串，這樣就能夠區分誰是誰了。

session id看似解決web無狀態請求的問題，但也造成了不小的困擾。比如在負載均衡組成的集群中，當我們通過機器A登錄，session id就會保持在機器A上。但如果下次請求轉發到了機器B，就需要將機器A的session id復制到機器B上，所以總是在session復制、粘貼的過程，如果保存了session的機器掛了新的問題接著又產生了。

除此之外每個人的設備確實是保存了屬于自己的session id，但服務器卻要保存所有的session id，這可不一定是幾個幾十個了，二十成千上萬，甚至幾十、上百萬個。

session其實也特別不安全，如果有人偽造了你的session id，也就意味著他可以為所欲為了。可以通過cookie的方式來保存session id，但cookie的區別在于其主要內容包括了名字、值、過期時間、路徑、域等信息，cookie可以實現類似于訪問者離開店鋪或者關閉瀏覽器，再打開店鋪就能馬上回復購物車的功能。但cookie一旦過期就會被清理，當訪問者再次打開網站時又會重新分配cookie。

這么看來session id和cookie在本質上并沒有完全的區別，別人想偽造很容易偽造。于是token就出現了，比如用HMAC-SHA256算法加上一個密鑰來對數據進行簽名，那么別人不知道密鑰，那么就沒有辦法偽造了，簽名和數據組合在一起就是token了。

token并不需要保存，只需要將發過來的token用同樣的HMAC-SHA256算法和密鑰再算一次比對相同就表示這個用戶已經登錄了，并且可以直接取到用戶的userID，相反不相同，則會提示認證失敗。token的優勢是非常明顯的，服務器只生產token和驗證token，所以服務器就變得非常輕松，沒有了各種附帶的狀態。

但由于token中的數據也是明文保存，所以一旦某個人的token被人偷走了，和本人是一樣的。

總之cookie依舊在，使用web api的互聯網大廠更加熱衷于token，token相對于session id、cookie會更加安全，并且無狀態、可擴展，支持移動設備，可以跨程序調用。

以上個人淺見，歡迎批評指正。

認同我的看法，請點個贊再走，感謝！

喜歡我的，請關注我，再次感謝！