文章原地址：https://segmentfault.com/a/1190000017831088

簡述

我在寫之前看了很多篇session，cookie的文章，有的人說先有了cookie，后有了session。也有人說先有session，后有cookie。感覺都沒有講的很清楚，泛泛而談。希望本篇文章對大家有所幫助
注：本文需要讀者有cookie，session，token的相關(guān)基礎(chǔ)知識。

http是一個無狀態(tài)協(xié)議

什么是無狀態(tài)呢？就是說這一次請求和上一次請求是沒有任何關(guān)系的，互不認(rèn)識的，沒有關(guān)聯(lián)的。這種無狀態(tài)的的好處是快速。壞處是假如我們想要把www.zhihu.com/login.html和www.zhihu.com/index.html關(guān)聯(lián)起來，必須使用某些手段和工具

cookie和session

由于http的無狀態(tài)性，為了使某個域名下的所有網(wǎng)頁能夠共享某些數(shù)據(jù)，session和cookie出現(xiàn)了?？蛻舳嗽L問服務(wù)器的流程如下

• 首先，客戶端會發(fā)送一個http請求到服務(wù)器端。
• 服務(wù)器端接受客戶端請求后，建立一個session，并發(fā)送一個http響應(yīng)到客戶端，這個響應(yīng)頭，其中就包含Set-Cookie頭部。該頭部包含了sessionId。Set-Cookie格式如下，具體請看Cookie詳解
  Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]
• 在客戶端發(fā)起的第二次請求，假如服務(wù)器給了set-Cookie，瀏覽器會自動在請求頭中添加cookie
• 服務(wù)器接收請求，分解cookie，驗證信息，核對成功后返回response給客戶端

image.png

注意

• cookie只是實現(xiàn)session的其中一種方案。雖然是最常用的，但并不是唯一的方法。禁用cookie后還有其他方法存儲，比如放在url中
• 現(xiàn)在大多都是Session + Cookie，但是只用session不用cookie，或是只用cookie，不用session在理論上都可以保持會話狀態(tài)?？墒菍嶋H中因為多種原因，一般不會單獨使用
• 用session只需要在客戶端保存一個id，實際上大量數(shù)據(jù)都是保存在服務(wù)端。如果全部用cookie，數(shù)據(jù)量大的時候客戶端是沒有那么多空間的。
• 如果只用cookie不用session，那么賬戶信息全部保存在客戶端，一旦被劫持，全部信息都會泄露。并且客戶端數(shù)據(jù)量變大，網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量也會變大

小結(jié)

簡而言之, session 有如用戶信息檔案表, 里面包含了用戶的認(rèn)證信息和登錄狀態(tài)等信息. 而 cookie 就是用戶通行證

token

token 也稱作令牌，由uid+time+sign[+固定參數(shù)]
token 的認(rèn)證方式類似于臨時的證書簽名, 并且是一種服務(wù)端無狀態(tài)的認(rèn)證方式, 非常適合于 REST API 的場景. 所謂無狀態(tài)就是服務(wù)端并不會保存身份認(rèn)證相關(guān)的數(shù)據(jù)。

組成

• uid: 用戶唯一身份標(biāo)識
• time: 當(dāng)前時間的時間戳
• sign: 簽名, 使用 hash/encrypt 壓縮成定長的十六進(jìn)制字符串，以防止第三方惡意拼接
• 固定參數(shù)(可選): 將一些常用的固定參數(shù)加入到 token 中是為了避免重復(fù)查庫

存放

token在客戶端一般存放于localStorage，cookie，或sessionStorage中。在服務(wù)器一般存于數(shù)據(jù)庫中

token認(rèn)證流程

token 的認(rèn)證流程與cookie很相似

• 用戶登錄，成功后服務(wù)器返回Token給客戶端。
• 客戶端收到數(shù)據(jù)后保存在客戶端
• 客戶端再次訪問服務(wù)器，將token放入headers中
• 服務(wù)器端采用filter過濾器校驗。校驗成功則返回請求數(shù)據(jù)，校驗失敗則返回錯誤碼

token可以抵抗csrf，cookie+session不行

假如用戶正在登陸銀行網(wǎng)頁，同時登陸了攻擊者的網(wǎng)頁，并且銀行網(wǎng)頁未對csrf攻擊進(jìn)行防護(hù)。攻擊者就可以在網(wǎng)頁放一個表單，該表單提交src為http://www.bank.com/api/transfer，body為count=1000&to=Tom。倘若是session+cookie，用戶打開網(wǎng)頁的時候就已經(jīng)轉(zhuǎn)給Tom1000元了.因為form 發(fā)起的 POST 請求并不受到瀏覽器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域發(fā)送 POST 請求，形成 CSRF 攻擊。在post請求的瞬間，cookie會被瀏覽器自動添加到請求頭中。但token不同，token是開發(fā)者為了防范csrf而特別設(shè)計的令牌，瀏覽器不會自動添加到headers里，攻擊者也無法訪問用戶的token，所以提交的表單無法通過服務(wù)器過濾，也就無法形成攻擊。

分布式情況下的session和token

我們已經(jīng)知道session時有狀態(tài)的，一般存于服務(wù)器內(nèi)存或硬盤中，當(dāng)服務(wù)器采用分布式或集群時，session就會面對負(fù)載均衡問題。

• 負(fù)載均衡多服務(wù)器的情況，不好確認(rèn)當(dāng)前用戶是否登錄，因為多服務(wù)器不共享session。這個問題也可以將session存在一個服務(wù)器中來解決，但是就不能完全達(dá)到負(fù)載均衡的效果。當(dāng)今的幾種解決session負(fù)載均衡的方法。

而token是無狀態(tài)的，token字符串里就保存了所有的用戶信息

• 客戶端登陸傳遞信息給服務(wù)端，服務(wù)端收到后把用戶信息加密（token）傳給客戶端，客戶端將token存放于localStroage等容器中?？蛻舳嗣看卧L問都傳遞token，服務(wù)端解密token，就知道這個用戶是誰了。通過cpu加解密，服務(wù)端就不需要存儲session占用存儲空間，就很好的解決負(fù)載均衡多服務(wù)器的問題了。這個方法叫做JWT(Json Web Token)

總結(jié)

• session存儲于服務(wù)器，可以理解為一個狀態(tài)列表，擁有一個唯一識別符號sessionId，通常存放于cookie中。服務(wù)器收到cookie后解析出sessionId，再去session列表中查找，才能找到相應(yīng)session。依賴cookie
• cookie類似一個令牌，裝有sessionId，存儲在客戶端，瀏覽器通常會自動添加。
• token也類似一個令牌，無狀態(tài)，用戶信息都被加密到token中，服務(wù)器收到token后解密就可知道是哪個用戶。需要開發(fā)者手動添加。
• jwt只是一個跨域認(rèn)證的方案

參考文章

Cookie、Session、Token那點事兒
cookie,token驗證的區(qū)別
有了cookie為什么需要session
CSRF Token的設(shè)計是否有其必要性
cookie,token,session三者的問題和解決方案
負(fù)載均衡集群中的session解決方案
JWT介紹
Json Web Token 入門教程