正文

1990 年。

蒂姆·伯納斯·李創建了 HTTP 協議。

李老的想法是把文檔存儲在服務器中，誰需要這個文檔直接從服務器獲取即可。

按照這個思想，當時的需求只有 GET。

并且按照拿文檔的思路：拿完了連接就可以斷了，也不需要什么交互。

所以 HTTP 起初的設計就是無狀態的。

也就是請求和請求之間是沒有關聯的。

而隨著互聯網的發展，交互開始興起。

人們不再滿足簡單的靜態文件獲取，各種購物、社交接踵而至。

這意味著服務器需要判斷每個請求的發起者是誰，也就是需要狀態。

你聊天總得表明你是誰，并且和誰聊吧？不然服務器可不知這聊天信息得發給誰。

你購物總得讓服務器知道是誰買了這玩意吧？

總不能你買完了下線，再上線發現你買的東西沒了。

這時候就是需要一種技術讓請求與請求之間建立起聯系，讓請求變得有狀態。

這技術叫 Cookie，就是一個以 Key-Value 格式存儲的小文件，保存在客戶端本地。

比如登錄之后，服務器就能設置 Cookie 返回給瀏覽器，然后保存在本地。

隨便截了個百度的，列出來的就是 key，下拉箭頭打開里面就有 value。

 

之后對百度的請求就可以帶著 Cookie 去訪問服務器，這里假設 BAIDUID 是用戶 ID。

百度的服務器一看原來是這個 ID 啊，就知道是“我”請求了，這就有狀態了。

簡單地說 Cookie 就是存儲在本地的一份文件，每次請求都會帶上 Cookie 去訪問服務器。

所以把一些用戶信息塞到 Cookie 里，這樣服務器就能判別是哪個用戶的請求了。

注意 Cookie 是有域的劃分的，來看下這個圖：

 

也就是每個域下面都有各自的 Cookie ，訪問不同的網站帶屬于這個網站的 Cookie ，不會帶別人的 Cookie ，不然就亂套了。

 

但是 Cookie 是明文存儲在用戶本地，而且帶有大量的用戶信息這不太安全。

并且每次請求都需要帶這么多 Cookie 對帶寬來說也不太劃算。

Session 就解決了這個問題，Session 就是會話，它有更加廣泛的含義，在和 Cookie 這些一起談論的場景，我們把它狹義化。

Session 就是把用戶的會話信息存儲在服務端。

然后頒發給客戶端一個 sessionId，讓客戶端之后帶著 sessionId 來請求。

這樣服務端就可以通過 sessionId 去找到這個用戶的信息，從而識別請求。

那客戶端是如何帶上 sessionId 的？

這個 sessionId 還是按照 Cookie 的形式存儲在用戶的本地，發起請求的時候帶上即可。

 

但是把這種狀態信息存儲到服務器中使得服務器就有狀態了。

一般我們部署在線上的服務器會有多臺來做負載均衡，也互相作為 backup。

所以如果 Session 的信息存在某一臺機器上，那么當下一次請求被負載分到另一臺機器那就找不到這個 Session 信息了。

也就不認得這個請求了，可能的現象就是告訴用戶沒登錄，那用戶不就傻了。

我這剛還登錄著呢，這就告訴我沒登錄了？

所以處理方式有 session 復制，就是服務器之間互相同步 session，這樣不論請求到哪個服務器都有用戶的信息。

不過這復制就冗余了，有額外的開銷。

還有一種就是 session sticky，其實就是把你的請求一直粘在某一個服務器上，如果你請求的一開始被指派的是 A 服務器，那么之后的所有請求都只會被指派到 A 服務器上。

但是如果 A 服務器掛了，你的請求還是會被指派到別的服務器上，這樣一來用戶登錄信息還是會丟了。

可以看到復制和 sticky 都有缺陷，所以可以把 session 放到第三方存儲，比如 Redis 里。

這樣服務器等于又沒狀態了。

而服務器的無狀態意味著可以隨意伸縮，服務集群根據流量加幾臺減幾臺，很方便。

但是把 session 放第三方存儲上只是把這個維護從服務器轉嫁到第三方身上。

第三方得保證它的高可用，不然用戶登錄信息又會丟了。

不過一般而言我們的系統本來就要維護的第三方存儲，所以影響不大。

小結一下：Cookie 明文存儲在本地不太安全，所以想著把用戶狀態存在服務端，而 Session 就是將用戶狀態信息保存在服務端。

就暴露 sessionId 給客戶端，這樣相對而言安全些，并且也減少了網絡流量。

但這樣服務端就有狀態了，難以擴展。

因此可以把 Session 放到第三方存儲上，但是等于狀態還是由服務端維護。

Token

其實仔細想想，是不是不需要在服務端存儲用戶的信息？

只需要一個能代表身份的憑證即可，一個服務端頒發給用戶憑證，之后的請求讓用戶帶著這個憑證就行。

就像我們的身份證，就代表我們。

這個憑證里面就包含了用戶的信息，有人可能怕憑證被偽造。

沒事，把憑證給簽名了，這樣我們服務器就能驗證憑證的真偽。

和別人做不得假身份證一樣。

這種憑證叫 Token。

如果一個用戶登錄了系統，我就返回一個 Token 給他，之后每次請求他帶著這個 Token 來就行。

服務器驗證了真偽之后拿到 Token 里面的用戶信息就知道這個請求是誰發的了。

 

這樣服務器就無狀態了，是真的無狀態了，當然客戶端有狀態了。

由客戶端來保存 Token ，這樣是最合理的，不需要在服務端冗余數據。

有了 Token 之后服務器因為無狀態所以可擴展，并且 Token 還能跨應用使用。

比如同一個公司不同應用之間的調用，所有應用只要能識別這個 Token 就都能登錄。

一個 Token 就搞定了，不用每個網站都登錄一遍，這就是單點登錄。

如果是第三方服務提供方也更容易地提供服務，只需要頒發一個 Token 給調用者即可。

Token  簡單的說就是一個含有憑證信息的令牌，只要服務器能識別這個令牌就能根據令牌的身份進行相應的響應。

其實這還蘊含了時間換空間的思想，把存儲在服務器的用戶信息暴露出去，利用簽名來驗證 Token 的真偽。

這樣每次請求都需要耗費時間去驗簽，不過好處就是不需要存儲信息，也就是時間換空間。