前言

今天就來理一理session、cookie、token這三者之間的關(guān)系！

1.為什么會(huì)有它們？

我們都知道 HTTP 協(xié)議是無狀態(tài)的，所謂的無狀態(tài)就是客戶端每次想要與服務(wù)端通信，都必須重新與服務(wù)端鏈接，意味著請求一次客戶端和服務(wù)端就連接一次，下一次請求與上一次請求是沒有關(guān)系的。

這種無狀態(tài)的方式就會(huì)存在一個(gè)問題：如何判斷兩次請求的是同一個(gè)人？就好比用戶在頁面 A 發(fā)起請求獲取個(gè)人信息，然后在另一個(gè)頁面同樣發(fā)起請求獲取個(gè)人信息，我們?nèi)绾未_定這倆個(gè)請求是同一個(gè)人發(fā)的呢？

為了解決這種問題，我們就迫切需要一種方式知道發(fā)起請求的客戶端是誰？此時(shí)，cookie、token、session 就出現(xiàn)了，它們就可以解決客戶端標(biāo)識的問題，在擴(kuò)大一點(diǎn)就是解決權(quán)限問題。

它們就好比讓每個(gè)客戶端或者說登錄用戶有了自己的身份證，我們可以通過這個(gè)身份證確定發(fā)請求的是誰！

2.什么是 cookie？

cookie 是保存在客戶端或者說瀏覽器中的一小塊數(shù)據(jù)，大小限制大致在 4KB 左右，在以前很多開發(fā)人員通常用 cookie 來存儲(chǔ)各種數(shù)據(jù)，后來隨著更多瀏覽器存儲(chǔ)方案的出現(xiàn)，cookie 存儲(chǔ)數(shù)據(jù)這種方式逐漸被取代，主要原因有如下：

• cookie 有存儲(chǔ)大小限制，4KB 左右。
• 瀏覽器每次請求會(huì)攜帶 cookie 在請求頭中。
• 字符編碼為 Unicode，不支持直接存儲(chǔ)中文。
• 數(shù)據(jù)可以被輕易查看。

cookie 主要有以下屬性：

我們介紹了 cookie，那么我們是如何通過 cookie 來實(shí)現(xiàn)用戶確定或者權(quán)限的確定呢？

我們就以一個(gè)普通網(wǎng)站的用戶登錄操作以及后續(xù)操作為例，主要過程可以簡單用下圖表示：

從上圖中可以看到使用 cookie 進(jìn)行用戶確認(rèn)流程是比較簡單的，大致分為以下幾步：

1. 客戶端發(fā)送請求到服務(wù)端（比如登錄請求）。
2. 服務(wù)端收到請求后生成一個(gè) session 會(huì)話。
3. 服務(wù)端響應(yīng)客戶端，并在響應(yīng)頭中設(shè)置 Set-Cookie。Set-Cookie 里面包含了 sessionId，它的格式如下：Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]。其中 sessionId 就是用來標(biāo)識客戶端的，類似于去飯店里面，服務(wù)員給你一個(gè)號牌，后續(xù)上菜通過這個(gè)號牌來判斷上菜到哪里。
4. 客戶端收到該請求后，如果服務(wù)器給了 Set-Cookie，那么下次瀏覽器就會(huì)在請求頭中自動(dòng)攜帶 cookie。
5. 客戶端發(fā)送其它請求，自動(dòng)攜帶了 cookie，cookie 中攜帶有用戶信息等。
6. 服務(wù)端接收到請求，驗(yàn)證 cookie 信息，比如通過 sessionId 來判斷是否存在會(huì)話，存在則正常響應(yīng)。

cookie 主要有以下特點(diǎn)：

• cookie 存儲(chǔ)在客戶端
• cookie 不可跨域，但是在如果設(shè)置了 domain，那么它們是可以在一級域名和二級域名之間共享的。

3.什么是 session？

在上一節(jié)中，我們通過 Cookie 來實(shí)現(xiàn)了用戶權(quán)限的確認(rèn)，在其中我們提到了一個(gè)詞：session。顧名思義它就是會(huì)話的意思，session 主要由服務(wù)端創(chuàng)建，主要作用就是保存 sessionId，用戶與服務(wù)端之間的權(quán)限確認(rèn)主要就是通過這個(gè) sessionId。

簡單描述下 session：

session 由服務(wù)端創(chuàng)建，當(dāng)一個(gè)請求發(fā)送到服務(wù)端時(shí)，服務(wù)器會(huì)檢索該請求里面有沒有包含 sessionId 標(biāo)識，如果包含了 sessionId，則代表服務(wù)端已經(jīng)和客戶端創(chuàng)建過 session，然后就通過這個(gè) sessionId 去查找真正的 session，如果沒找到，則為客戶端創(chuàng)建一個(gè)新的 session，并生成一個(gè)新的 sessionId 與 session 對應(yīng)，然后在響應(yīng)的時(shí)候?qū)?sessionId 給客戶端，通常是存儲(chǔ)在 cookie 中。如果在請求中找到了真正的 session，驗(yàn)證通過，正常處理該請求。

總之每一個(gè)客戶端與服務(wù)端連接，服務(wù)端都會(huì)為該客戶端創(chuàng)建一個(gè) session，并將 session 的唯一標(biāo)識 sessionId 通過設(shè)置 Set-Cookie 頭的方式響應(yīng)給客戶端，客戶端將 sessionId 存到 cookie 中。

通常情況下，我們 cookie 和 session 都是結(jié)合著來用，當(dāng)然你也可以單獨(dú)只使用 cookie 或者單獨(dú)只使用 session，這里我們就將 cookie 和 session 結(jié)合著來用。

我們可以在修改一下整個(gè)請求過程圖，如下所示：

4.cookie 和 session 的區(qū)別？

前面兩節(jié)我們介紹了 cookie 和 session，它們兩者之間主要是通過 sessionId 關(guān)聯(lián)起來的，所以我們總結(jié)出：sessionId 是 cookie 和 session 之間的橋梁。我們?nèi)粘５南到y(tǒng)中如果在鑒權(quán)方面如果使用的是 cookie 方式，那么大部分的原理就和我們前面說的一樣。

或者我們可以換個(gè)說法，session 是基于 cookie 實(shí)現(xiàn)的，它們兩個(gè)主要有以下特點(diǎn)：

• session 比 cookie 更加安全，因?yàn)樗谴嬖诜?wù)端的，cookie 是存在客戶端的。
• cookie 只支持存儲(chǔ)字符串?dāng)?shù)據(jù)，session 可以存儲(chǔ)任意數(shù)據(jù)。
• cookie 的有效期可以設(shè)置較長時(shí)間，session 有效期都比較短。
• session 存儲(chǔ)空間很大，cookie 有限制。

系統(tǒng)想要實(shí)現(xiàn)鑒權(quán)，可以單獨(dú)使用 cookie，也可以單獨(dú)使用 session，但是建議結(jié)合兩者使用。

5.token 是什么？

前面我們說的 sessionId 可以叫做令牌，令牌顧名思義就是確認(rèn)身份的意思，服務(wù)端可以通過令牌來確認(rèn)身份。

cookie+session 是實(shí)現(xiàn)認(rèn)證的一種非常好的方式，但是凡事都有兩面性，它們實(shí)現(xiàn)的認(rèn)證主要有以下缺點(diǎn)：

• 增加請求體積，浪費(fèi)性能，因?yàn)槊看握埱蠖紩?huì)攜帶 cookie。
• 增加服務(wù)端資源消耗，因?yàn)槊總€(gè)客戶端連接進(jìn)來都需要生成 session，會(huì)占用服務(wù)端資源的。
• 容易遭受 CSRF 攻擊，即跨站域請求偽造。

那么為了避免這些缺點(diǎn)，token 方式的鑒權(quán)出現(xiàn)了，它可以說是一個(gè)民間的認(rèn)證方式，但是不得不說它帶來了非常多的好處。

token 的組成：

token 其實(shí)就是一串字符串而已，只不過它是被加密后的字符串，它通常使用 uid(用戶唯一標(biāo)識)、時(shí)間戳、簽名以及一些其它參數(shù)加密而成。我們將 token 進(jìn)行解密就可以拿到諸如 uid 這類的信息，然后通過 uid 來進(jìn)行接下來的鑒權(quán)操作。

token 是如何生成的：

前面我們說 cookie 是服務(wù)端設(shè)置了 set-cookie 響應(yīng)頭之后，瀏覽器會(huì)自動(dòng)保存 cookie，然后下一次發(fā)送請求的時(shí)候會(huì)自動(dòng)把 cookie 攜帶上。但是我們說 cookie 算是一種民間的實(shí)現(xiàn)方式，所以說瀏覽器自然不會(huì)對它進(jìn)行成么處理。token 主要是由服務(wù)器生成，然后返回給客戶端，客戶端手動(dòng)把 token 存下來，比如利用 localstorage 或者直接存到 cookie 當(dāng)中也行。

token 認(rèn)證流程：

1. 客戶端發(fā)起登錄請求，比如用戶輸入用戶名和密碼后登錄。
2. 服務(wù)端校驗(yàn)用戶名和密碼后，將用戶 id 和一些其它信息進(jìn)行加密，生成 token。
3. 服務(wù)端將 token 響應(yīng)給客戶端。
4. 客戶端收到響應(yīng)后將 token 存儲(chǔ)下來。
5. 下一次發(fā)送請求后需要將 token 攜帶上，比如放在請求頭中或者其它地方。
6. 服務(wù)端 token 后校驗(yàn)，校驗(yàn)通過則正常返回?cái)?shù)據(jù)。

用圖表示大致如下：

總結(jié)

雖然前面解釋 cookie、session、token 用了不少口舌，但是歸根結(jié)底啊，它們的目的都是一樣的：鑒權(quán)和認(rèn)證。

總結(jié)下來就是：session 是空間換時(shí)間，token 是時(shí)間換空間。

附：cookie/session的聯(lián)系

session雖說存放在服務(wù)器端，但是仔細(xì)看剛才的執(zhí)行流程你會(huì)明白，session是依賴于cookie的，這一點(diǎn)也是本篇文章想要著重強(qiáng)調(diào)的

7.cookie/session使用注意事項(xiàng)

1.cookie大小有限制 4k

2.cookie不能跨瀏覽器

3.cookie不支持中文

4.如果是安全性較高的數(shù)據(jù)應(yīng)存放在session中，因?yàn)閏ookie存放在客戶端總會(huì)輕易被不法分子獲取

5.如果是訪問量特別大的網(wǎng)站，盡量不要在session中存儲(chǔ)用戶數(shù)據(jù)，因?yàn)槊總€(gè)用戶存一個(gè)session會(huì)給服務(wù)器造成很大的壓力

但需要注意的是，若服務(wù)器做了負(fù)載均衡，用戶的下一次請求可能會(huì)被定向到其它服務(wù)器節(jié)點(diǎn)，若那臺節(jié)點(diǎn)上沒有用戶的Session信息，就會(huì)導(dǎo)致會(huì)話驗(yàn)證失敗。所以Session默認(rèn)機(jī)制下是不適合分布式部署的。

到此這篇關(guān)于session、cookie、token區(qū)別的文章就介紹到這了,更多相關(guān)session、cookie、token區(qū)別內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論