1、前言

眾所周之，IM是個典型的快速數據流交換系統，當今主流IM系統（尤其移動端IM）的數據流交換方式都是Http短連接+TCP或UDP長連接來實現。Http短連接主要用于從服務器讀取各種持久化信息：比如用戶信息、聊天歷史記錄、好友列表等等，長連接則是用于實時的聊天消息或指令的接收和發送。

作為IM系統中不可或缺的技術，Http短連的重要性無可替代，但Http作為傳統互聯網信息交換技術，一些典型的概念比如：Cookie、Session、Token，對于IM新手程序員來說并不容易理解。鑒于Http短連接在IM系統中的重要性，如何正確地理解Cookie、Session、Token這樣的東西，決定了您的技術方案能否找到最佳實踐。本文將從基礎上講解這3者的原理、用途以及正確地應用場景。

題外話：本文討論的使用Http短連接的話題可能并不適用于微信這樣的IM，因為微信的短連接并非使用Http標準協議實現，而是基于自研的Mars網絡層框架再造了一套短連接機制，從而更適用于IM這種場景（更低延遲、更省流量、更好的弱網適應算法等），詳情請見《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》。當然，Mars雖好，但不一定適合您的團隊，因為定制的方案相較于標準通用方案來說，沒有強大的技術實力，還是不太容易掌控的了的。

文章：《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》、《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》、《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》詳述了現今移動網絡下http短連接的網絡層技術問題，有助于更好地理解本文，有興趣的話也推薦讀一讀。

小白必讀：如果本文對你來說有點枯燥，那么讀這篇吧：《小白必讀：閑話HTTP短連接中的Session和Token》。

2、系列文章

▼?IM開發干貨系列文章

• 《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》
• 《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》

3、什么是Cookie？

Cookie 技術產生源于 HTTP 協議在互聯網上的急速發展。隨著互聯網時代的策馬奔騰，帶寬等限制不存在了，人們需要更復雜的互聯網交互活動，就必須同服務器保持活動狀態（簡稱：保活）。于是，在瀏覽器發展初期，為了適應用戶的需求技術上推出了各種保持 Web 瀏覽狀態的手段，其中就包括了 Cookie 技術。Cookie 在計算機中是個存儲在瀏覽器目錄中的文本文件，當瀏覽器運行時，存儲在 RAM 中發揮作用 （此種 Cookies 稱作 Session Cookies），一旦用戶從該網站或服務器退出，Cookie 可存儲在用戶本地的硬盤上 （此種 Cookies 稱作 Persistent Cookies）。

Cookie 起源：1993 年，網景公司雇員 Lou Montulli 為了讓用戶在訪問某網站時，進一步提高訪問速度，同時也為了進一步實現個人化網絡，發明了今天廣泛使用的 Cookie。（所以，適當的偷懶也會促進人類計算機發展史的一小步~）

Cookie時效性：目前有些 Cookie 是臨時的，有些則是持續的。臨時的 Cookie 只在瀏覽器上保存一段規定的時間，一旦超過規定的時間，該 Cookie 就會被系統清除。

Cookie使用限制：Cookie 必須在 HTML 文件的內容輸出之前設置；不同的瀏覽器 (Netscape Navigator、Internet Explorer) 對 Cookie 的處理不一致，使用時一定要考慮；客戶端用戶如果設置禁止 Cookie，則 Cookie 不能建立。 并且在客戶端，一個瀏覽器能創建的 Cookie 數量最多為 300 個，并且每個不能超過 4KB，每個 Web 站點能設置的 Cookie 總數不能超過 20 個。

執行流程：
?

• A：首先，客戶端會發送一個http請求到服務器端；
• B： 服務器端接受客戶端請求后，發送一個http響應到客戶端，這個響應頭，其中就包含Set-Cookie頭部；
• C：在客戶端發起的第二次請求（注意：如果服務器需要我們帶上Cookie，我們就需要在B步驟上面拿到這個Cookie然后作為請求頭一起發起第二次請求），提供給了服務器端可以用來唯一標識客戶端身份的信息。這時，服務器端也就可以判斷客戶端是否啟用了cookies。盡管，用戶可能在和應用程序交互的過程中突然禁用cookies的使用，但是，這個情況基本是不太可能發生的，所以可以不加以考慮，這在實踐中也被證明是對的。

為了方便理解，可以先看下這張流程執行圖加深概念：

那么，在瀏覽器上面的請求頭和Cookie在那？下圖給大家截取了其中一種：

4、Cookie 和 Session

眾所周知，HTTP 是一個無狀態協議，所以客戶端每次發出請求時，下一次請求無法得知上一次請求所包含的狀態數據，如何能把一個用戶的狀態數據關聯起來呢？

比如在淘寶的某個頁面中，你進行了登陸操作。當你跳轉到商品頁時，服務端如何知道你是已經登陸的狀態？

5、關于Session

Cookie 雖然很方便，但是使用 Cookie 有一個很大的弊端，Cookie 中的所有數據在客戶端就可以被修改，數據非常容易被偽造，那么一些重要的數據就不能存放在 Cookie 中了，而且如果 Cookie 中數據字段太多會影響傳輸效率。為了解決這些問題，就產生了 Session，Session 中的數據是保留在服務器端的。

總之：Session是對于服務端來說的，客戶端是沒有Session一說的。Session是服務器在和客戶端建立連接時添加客戶端連接標志，最終會在服務器軟件（Apache、Tomcat、JBoss）轉化為一個臨時Cookie發送給給客戶端，當客戶端第一請求時服務器會檢查是否攜帶了這個Session（臨時Cookie），如果沒有則會添加Session，如果有就拿出這個Session來做相關操作。

Session 的運作通過一個session_id來進行。session_id通常是存放在客戶端的 Cookie 中，比如在 express 中（說的是Nodejs），默認是connect.sid這個字段，當請求到來時，服務端檢查 Cookie 中保存的 session_id 并通過這個 session_id 與服務器端的 Session data 關聯起來，進行數據的保存和修改。

這意思就是說，當你瀏覽一個網頁時，服務端隨機產生一個 1024 比特長的字符串，然后存在你 Cookie 中的connect.sid字段中。當你下次訪問時，Cookie 會帶有這個字符串，然后瀏覽器就知道你是上次訪問過的某某某，然后從服務器的存儲中取出上次記錄在你身上的數據。由于字符串是隨機產生的，而且位數足夠多，所以也不擔心有人能夠偽造。偽造成功的概率比坐在家里編程時被鄰居家的狗突然闖入并咬死的幾率還低。

一個完整的Cookie+Session應用過程如下圖所示：

Session 可以存放在：
?

• 1）內存；
• 2）Cookie本身；
• 3）redis 或 memcached 等緩存中；
• 4）數據庫中。

線上來說，緩存的方案比較常見，存數據庫的話，查詢效率相比前三者都太低，不推薦；Cookie Session 有安全性問題，下面會提到。

傳統的身份驗證方法從最早的Cookie到Session以及給Session Cookie做個加密，接下來我們來看看Token認證。

6、什么是Token？

?

6.1Token的起源

諸如Ember，Angular，Backbone之類的Web前端框架類庫正隨著更加精細的Web應用而日益壯大。正因如此，服務器端的組建也正正在從傳統的任務中解脫，轉而變的更像API。API使得傳統的前端和后端的概念解耦。開發者可以脫離前端，獨立的開發后端，在測試上獲得更大的便利。這種途徑也使得一個移動應用和網頁應用可以使用相同的后端。

當使用一個API時，其中一個挑戰就是認證（authentication）。在傳統的web應用中，服務端成功的返回一個響應（response）依賴于兩件事。一是，他通過一種存儲機制保存了會話信息（Session）。每一個會話都有它獨特的信息（id），常常是一個長的，隨機化的字符串，它被用來讓未來的請求（Request）檢索信息。其次，包含在響應頭（Header）里面的信息使客戶端保存了一個Cookie。服務器自動的在每個子請求里面加上了會話ID，這使得服務器可以通過檢索Session中的信息來辨別用戶。這就是傳統的web應用逃避HTTP面向無連接的方法（This is how traditional web applications get around the fact that HTTP is stateless）。

API應該被設計成無狀態的（Stateless）。這意味著沒有登陸，注銷的方法，也沒有sessions，API的設計者同樣也不能依賴Cookie，因為不能保證這些request是由瀏覽器所發出的。自然，我們需要一個新的機制。Token這種東西就應運而生了。
?

6.2Token是什么

token是用戶身份的驗證方式，我們通常叫它：令牌。最簡單的token組成:uid(用戶唯一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽以哈希算法壓縮成一定長的十六進制字符串，可以防止惡意第三方拼接token請求服務器)。還可以把不變的參數也放進token，避免多次查庫。

我們可以把Token想象成一個安全的護照。你在一個安全的前臺驗證你的身份（通過你的用戶名和密碼），如果你成功驗證了自己，你就可以取得這個。當你走進大樓的時候（試圖從調用API獲取資源），你會被要求驗證你的護照，而不是在前臺重新驗證。

簡單來說，就像下圖這樣：

6.3Token的應用場景

Token的使用流程：
?

• A：當用戶首次登錄成功（注冊也是一種可以適用的場景）之后, 服務器端就會生成一個 token 值，這個值，會在服務器保存token值(保存在數據庫中)，再將這個token值返回給客戶端；
• B：客戶端拿到 token 值之后,進行本地保存。（SP存儲是大家能夠比較支持和易于理解操作的存儲）；
• C：當客戶端再次發送網絡請求(一般不是登錄請求)的時候,就會將這個 token 值附帶到參數中發送給服務器；
• D：服務器接收到客戶端的請求之后,會取出token值與保存在本地(數據庫)中的token值做對比。

Token的身份認證邏輯：
?

• 對比一：如果兩個 token 值相同， 說明用戶登錄成功過!當前用戶處于登錄狀態！
• 對比二：如果沒有這個 token 值, 則說明沒有登錄成功；
• 對比三：如果 token 值不同: 說明原來的登錄信息已經失效,讓用戶重新登錄。

?

6.4Token的安全性

我們可以保存認證過的Token記錄在服務器上，來添加一個附加的安全層，然后在每一步驗證Token的時候驗證這個記錄（比如每次客戶端請求API時檢查這個Token的合法性）。這將會阻止第三方偽裝一個Token，也將會使得服務器可以失效一個Token。

7、Cookie和Session的區別小結

?

• 1）cookie數據存放在客戶的瀏覽器上，session數據放在服務器上；
• 2）cookie不是很安全，別人可以分析存放在本地的cookie并進行cookie欺騙,考慮到安全應當使用session；
• 3）session會在一定時間內保存在服務器上。當訪問增多，會比較占用你服務器的性能,考慮到減輕服務器性能方面，應當使用cookie；
• 4）單個cookie保存的數據不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。

所以個人建議：
?

• 將登陸信息等重要信息存放為session；
• 其他信息如果需要保留，可以放在cookie中。

?

8、Token 和 Session 的區別小結

Session和 token并不矛盾，作為身份認證token安全性比Session好，因為每個請求都有簽名還能防止監聽以及重放攻擊，而Session就必須靠鏈路層來保障通訊安全了。如上所說，如果你需要實現有狀態的會話，仍然可以增加session來在服務器端保存一些狀態

App通常用restful api跟server打交道。Rest是stateless的，也就是app不需要像browser那樣用cookie來保存Session,因此用Session token來標示自己就夠了，session/state由api server的邏輯處理。如果你的后端不是stateless的rest api,那么你可能需要在app里保存Session.可以在app里嵌入webkit,用一個隱藏的browser來管理cookie Session.

Session是一種HTTP存儲機制，目的是為無狀態的HTTP提供的持久機制。所謂Session認證只是簡單的把User信息存儲到Session里，因為SID的不可預測性，暫且認為是安全的。這是一種認證手段。而Token，如果指的是OAuth Token或類似的機制的話，提供的是 認證 和 授權 ，認證是針對用戶，授權是針對App。其目的是讓 某App有權利訪問 某用戶 的信息。這里的Token是唯一的。不可以轉移到其它App上，也不可以轉到其它 用戶 上。轉過來說Session。Session只提供一種簡單的認證，即有此SID，即認為有此User的全部權利。是需要嚴格保密的，這個數據應該只保存在站方，不應該共享給其它網站或者第三方App。所以簡單來說，如果你的用戶數據可能需要和第三方共享，或者允許第三方調用API接口，用Token。如果永遠只是自己的網站，自己的App，用什么就無所謂了。

Token就是令牌，比如你授權（登錄）一個程序時，他就是個依據，判斷你是否已經授權該軟件；cookie就是寫在客戶端的一個txt文件，里面包括你登錄信息之類的，這樣你下次在登錄某個網站，就會自動調用cookie自動登錄用戶名；session和cookie差不多，只是Session是寫在服務器端的文件，也需要在客戶端寫入cookie文件，但是文件里是你的瀏覽器編號。Session的狀態是存儲在服務器端，客戶端只有Session id；而Token的狀態是存儲在客戶端。

網易云信，你身邊的即時通訊和音視頻技術專家，了解我們，請戳網易云信官網

想要行業洞察和技術干貨，請關注網易云信博客

本文轉載自52im,作者：JackJiang

總結

以上是生活随笔為你收集整理的IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。