聊聊Cookie、Session、Token背后的故事
大家好，我是所長大白(●—●)。
今天和大家聊一下關于cookie、session、token的那些事兒。
這是我的一個讀者朋友面試微信的實習崗位時遇到的，在此和大家分享一下。
圖片
話不多說，直接開車。
1. 網(wǎng)站交互體驗升級
作為網(wǎng)友的我們，每天都會使用瀏覽器來逛各種網(wǎng)站，來滿足日常的工作生活需求。
圖片
現(xiàn)在的交互體驗還是很絲滑的，但早期并非如此，而是一錘子買賣。
1.1 無狀態(tài)的http協(xié)議
無狀態(tài)的http協(xié)議是什么鬼？
HTTP無狀態(tài)協(xié)議，是指協(xié)議對于業(yè)務處理沒有記憶能力，之前做了啥完全記不住，每次請求都是完全獨立互不影響的，沒有任何上下文信息。
缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳關鍵信息，這樣可能導致每次連接傳送的數(shù)據(jù)量增大。
如果大家沒明白，可以想一下《夏洛特煩惱》里面的橋段：
大概明白了吧，假如一直用這種原生無狀態(tài)的http協(xié)議，我們每換一個頁面可能就得重新登錄一次，那還玩?zhèn)€球。
所以必須要解決http協(xié)議的無狀態(tài)，提升網(wǎng)站的交互體驗，否則星辰大海是去不了的。
1.2 解決之道
整個事情交互的雙方只有客戶端和服務端，所以必然要在這兩個當事者身上下手。
- 客戶端來買單
客戶端每次請求時把自己必要的信息封裝發(fā)送給服務端，服務端查收處理一下就行。
圖片
- 服務端來買單
客戶端第一次請求之后，服務端就開始做記錄，然后客戶端在后續(xù)請求中只需要將最基本最少的信息發(fā)過來就行，不需要太多信息了。
圖片
2.Cookie方案
Cookie總是保存在客戶端中，按在客戶端中的存儲位置，可分為內(nèi)存Cookie和硬盤Cookie，內(nèi)存Cookie由瀏覽器維護，保存在內(nèi)存中，瀏覽器關閉后就消失了，其存在時間是短暫的，硬盤Cookie保存在硬盤里，有一個過期時間，除非用戶手工清理或到了過期時間，硬盤Cookie不會被刪除，其存在時間是長期的。
圖片
2.1 Cookie定義和作用
HTTP Cookie（也叫 Web Cookie 或瀏覽器 Cookie）是服務器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)，它會在瀏覽器下次向同一服務器再發(fā)起請求時被攜帶并發(fā)送到服務器上。
通常Cookie用于告知服務端兩個請求是否來自同一瀏覽器，如保持用戶的登錄狀態(tài)。Cookie 使基于無狀態(tài)的HTTP協(xié)議記錄穩(wěn)定的狀態(tài)信息成為了可能。
Cookie 主要用于以下三個方面：
- 會話狀態(tài)管理（如用戶登錄狀態(tài)、購物車等其它需要記錄的信息）
- 個性化設置（如用戶自定義設置、主題等）
- 瀏覽器行為跟蹤（如跟蹤分析用戶行為等）
2.2 服務端創(chuàng)建Cookie
當服務器收到 HTTP 請求時，服務器可以在響應頭里面添加一個 Set-Cookie 選項。
瀏覽器收到響應后通常會保存下 Cookie，之后對該服務器每一次請求中都通過 Cookie 請求頭部將 Cookie 信息發(fā)送給服務器。另外，Cookie 的過期時間、域、路徑、有效期、適用站點都可以根據(jù)需要來指定。
圖片
2.3 B/S的Cookie交互
圖片
服務器使用 Set-Cookie 響應頭部向用戶瀏覽器發(fā)送 Cookie信息。
一個簡單的 Cookie 可能像這樣：
Set-Cookie: <cookie名>=<cookie值>
HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry客戶端對該服務器發(fā)起的每一次新請求，瀏覽器都會將之前保存的Cookie信息通過 Cookie 請求頭部再發(fā)送給服務器。
GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry我來訪問下淘寶網(wǎng)，抓個包看看這個真實的過程：
圖片
2.4 存在的問題
Cookie 常用來標記用戶或授權會話，被瀏覽器發(fā)出之后可能被劫持，被用于非法行為，可能導致授權用戶的會話受到攻擊，因此存在安全問題。
還有一種情況就是跨站請求偽造CSRF，簡單來說 比如你在登錄銀行網(wǎng)站的同時，登錄了一個釣魚網(wǎng)站，在釣魚網(wǎng)站進行某些操作時可能會獲取銀行網(wǎng)站相關的Cookie信息，向銀行網(wǎng)站發(fā)起轉賬等非法行為。
跨站請求偽造（英語：Cross-site request forgery），也被稱為 one-click attack 或者 session riding，通常縮寫為 CSRF 或者 XSRF， 是一種挾制用戶在當前已登錄的Web應用程序上執(zhí)行非本意的操作的攻擊方法。跟跨網(wǎng)站腳本（XSS）相比，XSS 利用的是用戶對指定網(wǎng)站的信任，CSRF 利用的是網(wǎng)站對用戶網(wǎng)頁瀏覽器的信任。
跨站請求攻擊，簡單地說，是攻擊者通過一些技術手段欺騙用戶的瀏覽器去訪問一個自己曾經(jīng)認證過的網(wǎng)站并運行一些操作（如發(fā)郵件，發(fā)消息，甚至財產(chǎn)操作如轉賬和購買商品）。
由于瀏覽器曾經(jīng)認證過，所以被訪問的網(wǎng)站會認為是真正的用戶操作而去運行。這利用了web中用戶身份驗證的一個漏洞：簡單的身份驗證只能保證請求發(fā)自某個用戶的瀏覽器，卻不能保證請求本身是用戶自愿發(fā)出的。
不過這種情況有很多解決方法，特別對于銀行這類金融性質的站點，用戶的任何敏感操作都需要確認，并且敏感信息的 Cookie 只能擁有較短的生命周期。
同時Cookie有容量和數(shù)量的限制，每次都要發(fā)送很多信息帶來額外的流量消耗、復雜的行為Cookie無法滿足要求。
圖片
特別注意：以上存在的問題只是Cookie被用于實現(xiàn)交互狀態(tài)時存在的問題，但并不是說Cookie本身的問題。
試想一下：菜刀可以用來做菜，也可以被用來從事某些暴力行為，你能說菜刀應該被廢除嗎？
3. Session方案
3.1 Session機制的概念
如果說Cookie是客戶端行為，那么Session就是服務端行為。
圖片
Cookie機制在最初和服務端完成交互后，保持狀態(tài)所需的信息都將存儲在客戶端，后續(xù)直接讀取發(fā)送給服務端進行交互。
Session代表服務器與瀏覽器的一次會話過程，并且完全由服務端掌控，實現(xiàn)分配ID、會話信息存儲、會話檢索等功能。
Session機制將用戶的所有活動信息、上下文信息、登錄信息等都存儲在服務端，只是生成一個唯一標識ID發(fā)送給客戶端，后續(xù)的交互將沒有重復的用戶信息傳輸，取而代之的是唯一標識ID，暫且稱之為Session-ID吧。
3.2 簡單的交互流程
- 當客戶端第一次請求session對象時候，服務器會為客戶端創(chuàng)建一個session，并將通過特殊算法算出一個session的ID，用來標識該session對象。
- 當瀏覽器下次請求別的資源的時候，瀏覽器會將sessionID放置到請求頭中，服務器接收到請求后解析得到sessionID，服務器找到該id的session來確定請求方的身份和一些上下文信息。
3.3 Session的實現(xiàn)方式
首先明確一點，Session和Cookie沒有直接的關系，可以認為Cookie只是實現(xiàn)Session機制的一種方法途徑而已，沒有Cookie還可以用別的方法。
Session和Cookie的關系就像加班和加班費的關系，看似關系很密切，實際上沒啥關系。
session的實現(xiàn)主要兩種方式：cookie與url重寫，而cookie是首選方式，因為各種現(xiàn)代瀏覽器都默認開通cookie功能，但是每種瀏覽器也都有允許cookie失效的設置，因此對于Session機制來說還需要一個備胎。
圖片
將會話標識號以參數(shù)形式附加在超鏈接的URL地址后面的技術稱為URL重寫。
原始的URL：
http://taobao.com/getitem?name=baymax&actinotallow=buy
重寫后的URL:
http://taobao.com/getitem?sessinotallow=1wui87htentg&?name=baymax&actinotallow=buy3.4 存在的問題
圖片
由于Session信息是存儲在服務端的，因此如果用戶量很大的場景，Session信息占用的空間就不容忽視。
對于大型網(wǎng)站必然是集群化&分布式的服務器配置，如果Session信息是存儲在本地的，那么由于負載均衡的作用，原來請求機器A并且存儲了Session信息，下一次請求可能到了機器B，此時機器B上并沒有Session信息。
這種情況下要么在B機器重復創(chuàng)建造成浪費，要么引入高可用的Session集群方案，引入Session代理實現(xiàn)信息共享，要么實現(xiàn)定制化哈希到集群A，這樣做其實就有些復雜了。
圖片
4. Token方案
Token是令牌的意思，由服務端生成并發(fā)放給客戶端，是一種具有時效性的驗證身份的手段。
Token避免了Session機制帶來的海量信息存儲問題，也避免了Cookie機制的一些安全性問題，在現(xiàn)代移動互聯(lián)網(wǎng)場景、跨域訪問等場景有廣泛的用途。
4.1 簡單的交互流程
圖片
- 客戶端將用戶的賬號和密碼提交給服務器
- 服務器對其進行校驗，通過則生成一個token值返回給客戶端，作為后續(xù)的請求交互身份令牌
- 客戶端拿到服務端返回的token值后，可將其保存在本地，以后每次請求服務器時都攜帶該token，提交給服務器進行身份校驗
- 服務器接收到請求后，解析關鍵信息，再根據(jù)相同的加密算法、密鑰、用戶參數(shù)生成sign與客戶端的sign進行對比，一致則通過，否則拒絕服務
- 驗證通過之后，服務端就可以根據(jù)該Token中的uid獲取對應的用戶信息，進行業(yè)務請求的響應
4.2 Token的設計思想
以JSON Web Token（JWT）為例，Token主要由3部分組成：
- Header頭部信息
記錄了使用的加密算法信息 - Payload 凈荷信息
記錄了用戶信息和過期時間等 - Signature 簽名信息
根據(jù)header中的加密算法和payload中的用戶信息以及密鑰key來生成，是服務端驗證服務端的重要依據(jù)
圖片
header和payload的信息不做加密，只做一般的base64編碼，服務端收到token后剝離出header和payload獲取算法、用戶、過期時間等信息，然后根據(jù)自己的加密密鑰來生成sign，并與客戶端傳來的sign進行一致性對比，來確定客戶端的身份合法性。
這樣就實現(xiàn)了用CPU加解密的時間換取存儲空間，同時服務端密鑰的重要性就顯而易見，一旦泄露整個機制就崩塌了，這個時候就需要考慮HTTPS了。
4.3 Token方案的特點
- Token可以跨站共享，實現(xiàn)單點登錄
- Token機制無需太多存儲空間，Token包含了用戶的信息，只需在客戶端存儲狀態(tài)信息即可，對于服務端的擴展性很好
- Token機制的安全性依賴于服務端加密算法和密鑰的安全性
- Token機制也不是萬金油
5.總結
Cookie、Session、Token這三者是不同發(fā)展階段的產(chǎn)物，并且各有優(yōu)缺點，三者也沒有明顯的對立關系，反而常常結伴出現(xiàn)，這也是容易被混淆的原因。
Cookie側重于信息的存儲，主要是客戶端行為，Session和Token側重于身份驗證，主要是服務端行為。
三者方案在很多場景都還有生命力，了解場景才能選擇合適的方案，沒有銀彈。
就寫這些吧，我們下期見。
