1、前言

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

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

題外話：本文討論的使用Http短連接的話題可能并不適用于微信這樣的IM，因?yàn)槲⑿诺亩踢B接并非使用Http標(biāo)準(zhǔn)協(xié)議實(shí)現(xiàn)，而是基于自研的Mars網(wǎng)絡(luò)層框架再造了一套短連接機(jī)制，從而更適用于IM這種場(chǎng)景（更低延遲、更省流量、更好的弱網(wǎng)適應(yīng)算法等），詳情請(qǐng)見《如約而至：微信自用的移動(dòng)端IM網(wǎng)絡(luò)層跨平臺(tái)組件庫Mars已正式開源》。當(dāng)然，Mars雖好，但不一定適合您的團(tuán)隊(duì)，因?yàn)槎ㄖ频姆桨赶噍^于標(biāo)準(zhǔn)通用方案來說，沒有強(qiáng)大的技術(shù)實(shí)力，還是不太容易掌控的了的。

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

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

2、系列文章

▼?IM開發(fā)干貨系列文章

• 《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(二)：如何設(shè)計(jì)大量圖片文件的服務(wù)端存儲(chǔ)架構(gòu)？》
• 《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫讀寫分離原理及實(shí)踐建議》

3、什么是Cookie？

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

Cookie 起源：1993 年，網(wǎng)景公司雇員 Lou Montulli 為了讓用戶在訪問某網(wǎng)站時(shí)，進(jìn)一步提高訪問速度，同時(shí)也為了進(jìn)一步實(shí)現(xiàn)個(gè)人化網(wǎng)絡(luò)，發(fā)明了今天廣泛使用的 Cookie。（所以，適當(dāng)?shù)耐祽幸矔?huì)促進(jìn)人類計(jì)算機(jī)發(fā)展史的一小步~）

Cookie時(shí)效性：目前有些 Cookie 是臨時(shí)的，有些則是持續(xù)的。臨時(shí)的 Cookie 只在瀏覽器上保存一段規(guī)定的時(shí)間，一旦超過規(guī)定的時(shí)間，該 Cookie 就會(huì)被系統(tǒng)清除。

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

執(zhí)行流程：
?

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

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

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

4、Cookie 和 Session

眾所周知，HTTP 是一個(gè)無狀態(tài)協(xié)議，所以客戶端每次發(fā)出請(qǐng)求時(shí)，下一次請(qǐng)求無法得知上一次請(qǐng)求所包含的狀態(tài)數(shù)據(jù)，如何能把一個(gè)用戶的狀態(tài)數(shù)據(jù)關(guān)聯(lián)起來呢？

比如在淘寶的某個(gè)頁面中，你進(jìn)行了登陸操作。當(dāng)你跳轉(zhuǎn)到商品頁時(shí)，服務(wù)端如何知道你是已經(jīng)登陸的狀態(tài)？

5、關(guān)于Session

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

總之：Session是對(duì)于服務(wù)端來說的，客戶端是沒有Session一說的。Session是服務(wù)器在和客戶端建立連接時(shí)添加客戶端連接標(biāo)志，最終會(huì)在服務(wù)器軟件（Apache、Tomcat、JBoss）轉(zhuǎn)化為一個(gè)臨時(shí)Cookie發(fā)送給給客戶端，當(dāng)客戶端第一請(qǐng)求時(shí)服務(wù)器會(huì)檢查是否攜帶了這個(gè)Session（臨時(shí)Cookie），如果沒有則會(huì)添加Session，如果有就拿出這個(gè)Session來做相關(guān)操作。

Session 的運(yùn)作通過一個(gè)session_id來進(jìn)行。session_id通常是存放在客戶端的 Cookie 中，比如在 express 中（說的是Nodejs），默認(rèn)是connect.sid這個(gè)字段，當(dāng)請(qǐng)求到來時(shí)，服務(wù)端檢查 Cookie 中保存的 session_id 并通過這個(gè) session_id 與服務(wù)器端的 Session data 關(guān)聯(lián)起來，進(jìn)行數(shù)據(jù)的保存和修改。

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

一個(gè)完整的Cookie+Session應(yīng)用過程如下圖所示：

Session 可以存放在：
?

• 1）內(nèi)存；
• 2）Cookie本身；
• 3）redis 或 memcached 等緩存中；
• 4）數(shù)據(jù)庫中。

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

傳統(tǒng)的身份驗(yàn)證方法從最早的Cookie到Session以及給Session Cookie做個(gè)加密，接下來我們來看看Token認(rèn)證。

6、什么是Token？

?

6.1Token的起源

諸如Ember，Angular，Backbone之類的Web前端框架類庫正隨著更加精細(xì)的Web應(yīng)用而日益壯大。正因如此，服務(wù)器端的組建也正正在從傳統(tǒng)的任務(wù)中解脫，轉(zhuǎn)而變的更像API。API使得傳統(tǒng)的前端和后端的概念解耦。開發(fā)者可以脫離前端，獨(dú)立的開發(fā)后端，在測(cè)試上獲得更大的便利。這種途徑也使得一個(gè)移動(dòng)應(yīng)用和網(wǎng)頁應(yīng)用可以使用相同的后端。

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

API應(yīng)該被設(shè)計(jì)成無狀態(tài)的（Stateless）。這意味著沒有登陸，注銷的方法，也沒有sessions，API的設(shè)計(jì)者同樣也不能依賴Cookie，因?yàn)椴荒鼙ＷC這些request是由瀏覽器所發(fā)出的。自然，我們需要一個(gè)新的機(jī)制。Token這種東西就應(yīng)運(yùn)而生了。
?

6.2Token是什么

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

我們可以把Token想象成一個(gè)安全的護(hù)照。你在一個(gè)安全的前臺(tái)驗(yàn)證你的身份（通過你的用戶名和密碼），如果你成功驗(yàn)證了自己，你就可以取得這個(gè)。當(dāng)你走進(jìn)大樓的時(shí)候（試圖從調(diào)用API獲取資源），你會(huì)被要求驗(yàn)證你的護(hù)照，而不是在前臺(tái)重新驗(yàn)證。

簡(jiǎn)單來說，就像下圖這樣：

6.3Token的應(yīng)用場(chǎng)景

Token的使用流程：
?

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

Token的身份認(rèn)證邏輯：
?

• 對(duì)比一：如果兩個(gè) token 值相同， 說明用戶登錄成功過!當(dāng)前用戶處于登錄狀態(tài)！
• 對(duì)比二：如果沒有這個(gè) token 值, 則說明沒有登錄成功；
• 對(duì)比三：如果 token 值不同: 說明原來的登錄信息已經(jīng)失效,讓用戶重新登錄。

?

6.4Token的安全性

我們可以保存認(rèn)證過的Token記錄在服務(wù)器上，來添加一個(gè)附加的安全層，然后在每一步驗(yàn)證Token的時(shí)候驗(yàn)證這個(gè)記錄（比如每次客戶端請(qǐng)求API時(shí)檢查這個(gè)Token的合法性）。這將會(huì)阻止第三方偽裝一個(gè)Token，也將會(huì)使得服務(wù)器可以失效一個(gè)Token。

7、Cookie和Session的區(qū)別小結(jié)

?

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

所以個(gè)人建議：
?

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

?

8、Token 和 Session 的區(qū)別小結(jié)

Session和 token并不矛盾，作為身份認(rèn)證token安全性比Session好，因?yàn)槊總€(gè)請(qǐng)求都有簽名還能防止監(jiān)聽以及重放攻擊，而Session就必須靠鏈路層來保障通訊安全了。如上所說，如果你需要實(shí)現(xiàn)有狀態(tài)的會(huì)話，仍然可以增加session來在服務(wù)器端保存一些狀態(tài)

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

Session是一種HTTP存儲(chǔ)機(jī)制，目的是為無狀態(tài)的HTTP提供的持久機(jī)制。所謂Session認(rèn)證只是簡(jiǎn)單的把User信息存儲(chǔ)到Session里，因?yàn)镾ID的不可預(yù)測(cè)性，暫且認(rèn)為是安全的。這是一種認(rèn)證手段。而Token，如果指的是OAuth Token或類似的機(jī)制的話，提供的是 認(rèn)證 和 授權(quán) ，認(rèn)證是針對(duì)用戶，授權(quán)是針對(duì)App。其目的是讓 某App有權(quán)利訪問 某用戶 的信息。這里的Token是唯一的。不可以轉(zhuǎn)移到其它App上，也不可以轉(zhuǎn)到其它 用戶 上。轉(zhuǎn)過來說Session。Session只提供一種簡(jiǎn)單的認(rèn)證，即有此SID，即認(rèn)為有此User的全部權(quán)利。是需要嚴(yán)格保密的，這個(gè)數(shù)據(jù)應(yīng)該只保存在站方，不應(yīng)該共享給其它網(wǎng)站或者第三方App。所以簡(jiǎn)單來說，如果你的用戶數(shù)據(jù)可能需要和第三方共享，或者允許第三方調(diào)用API接口，用Token。如果永遠(yuǎn)只是自己的網(wǎng)站，自己的App，用什么就無所謂了。

Token就是令牌，比如你授權(quán)（登錄）一個(gè)程序時(shí)，他就是個(gè)依據(jù)，判斷你是否已經(jīng)授權(quán)該軟件；cookie就是寫在客戶端的一個(gè)txt文件，里面包括你登錄信息之類的，這樣你下次在登錄某個(gè)網(wǎng)站，就會(huì)自動(dòng)調(diào)用cookie自動(dòng)登錄用戶名；session和cookie差不多，只是Session是寫在服務(wù)器端的文件，也需要在客戶端寫入cookie文件，但是文件里是你的瀏覽器編號(hào)。Session的狀態(tài)是存儲(chǔ)在服務(wù)器端，客戶端只有Session id；而Token的狀態(tài)是存儲(chǔ)在客戶端。

網(wǎng)易云信，你身邊的即時(shí)通訊和音視頻技術(shù)專家，了解我們，請(qǐng)戳網(wǎng)易云信官網(wǎng)

想要行業(yè)洞察和技術(shù)干貨，請(qǐng)關(guān)注網(wǎng)易云信博客

本文轉(zhuǎn)載自52im,作者：JackJiang

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。