一文徹底理清session、cookie、token的區(qū)別
前言
今天就來理一理session、cookie、token這三者之間的關(guān)系!
1.為什么會有它們?
我們都知道 HTTP 協(xié)議是無狀態(tài)的,所謂的無狀態(tài)就是客戶端每次想要與服務(wù)端通信,都必須重新與服務(wù)端鏈接,意味著請求一次客戶端和服務(wù)端就連接一次,下一次請求與上一次請求是沒有關(guān)系的。
這種無狀態(tài)的方式就會存在一個問題:如何判斷兩次請求的是同一個人?就好比用戶在頁面 A 發(fā)起請求獲取個人信息,然后在另一個頁面同樣發(fā)起請求獲取個人信息,我們?nèi)绾未_定這倆個請求是同一個人發(fā)的呢?
為了解決這種問題,我們就迫切需要一種方式知道發(fā)起請求的客戶端是誰?此時,cookie、token、session 就出現(xiàn)了,它們就可以解決客戶端標(biāo)識的問題,在擴(kuò)大一點(diǎn)就是解決權(quán)限問題。
它們就好比讓每個客戶端或者說登錄用戶有了自己的身份證,我們可以通過這個身份證確定發(fā)請求的是誰!
2.什么是 cookie?
cookie 是保存在客戶端或者說瀏覽器中的一小塊數(shù)據(jù),大小限制大致在 4KB 左右,在以前很多開發(fā)人員通常用 cookie 來存儲各種數(shù)據(jù),后來隨著更多瀏覽器存儲方案的出現(xiàn),cookie 存儲數(shù)據(jù)這種方式逐漸被取代,主要原因有如下:
- cookie 有存儲大小限制,4KB 左右。
- 瀏覽器每次請求會攜帶 cookie 在請求頭中。
- 字符編碼為 Unicode,不支持直接存儲中文。
- 數(shù)據(jù)可以被輕易查看。
cookie 主要有以下屬性:
屬性名稱 | 屬性含義 |
---|---|
name | cookie 的名稱 |
value | cookie 的值 |
comment | cookie 的描述信息 |
domain | 可以訪問該 cookie 的域名 |
expires | cookie 的過期時間,具體某一時間 |
maxAge | cookie 的過期時間,比如多少秒后 cookie 過期。 |
path | cookie 的使用路徑, |
secure | cookie 是否使用安全協(xié)議傳輸,比如 SSL 等 |
version | cookie 使用的版本號 |
isHttpOnly | 指定該 Cookie 無法通過 JavaScript 腳本拿到,比如 Document.cookie 屬性、XMLHttpRequest 對象和 Request API 都拿不到該屬性。這樣就防止了該 Cookie 被腳本讀到,只有瀏覽器發(fā)出 HTTP 請求時,才會帶上該 Cookie。 |
我們介紹了 cookie,那么我們是如何通過 cookie 來實(shí)現(xiàn)用戶確定或者權(quán)限的確定呢?
我們就以一個普通網(wǎng)站的用戶登錄操作以及后續(xù)操作為例,主要過程可以簡單用下圖表示:
從上圖中可以看到使用 cookie 進(jìn)行用戶確認(rèn)流程是比較簡單的,大致分為以下幾步:
- 客戶端發(fā)送請求到服務(wù)端(比如登錄請求)。
- 服務(wù)端收到請求后生成一個 session 會話。
- 服務(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ù)員給你一個號牌,后續(xù)上菜通過這個號牌來判斷上菜到哪里。
- 客戶端收到該請求后,如果服務(wù)器給了 Set-Cookie,那么下次瀏覽器就會在請求頭中自動攜帶 cookie。
- 客戶端發(fā)送其它請求,自動攜帶了 cookie,cookie 中攜帶有用戶信息等。
- 服務(wù)端接收到請求,驗(yàn)證 cookie 信息,比如通過 sessionId 來判斷是否存在會話,存在則正常響應(yīng)。
cookie 主要有以下特點(diǎn):
- cookie 存儲在客戶端
- cookie 不可跨域,但是在如果設(shè)置了 domain,那么它們是可以在一級域名和二級域名之間共享的。
3.什么是 session?
在上一節(jié)中,我們通過 Cookie 來實(shí)現(xiàn)了用戶權(quán)限的確認(rèn),在其中我們提到了一個詞:session。顧名思義它就是會話的意思,session 主要由服務(wù)端創(chuàng)建,主要作用就是保存 sessionId,用戶與服務(wù)端之間的權(quán)限確認(rèn)主要就是通過這個 sessionId。
簡單描述下 session:
session 由服務(wù)端創(chuàng)建,當(dāng)一個請求發(fā)送到服務(wù)端時,服務(wù)器會檢索該請求里面有沒有包含 sessionId 標(biāo)識,如果包含了 sessionId,則代表服務(wù)端已經(jīng)和客戶端創(chuàng)建過 session,然后就通過這個 sessionId 去查找真正的 session,如果沒找到,則為客戶端創(chuàng)建一個新的 session,并生成一個新的 sessionId 與 session 對應(yīng),然后在響應(yīng)的時候?qū)?sessionId 給客戶端,通常是存儲在 cookie 中。如果在請求中找到了真正的 session,驗(yàn)證通過,正常處理該請求。
總之每一個客戶端與服務(wù)端連接,服務(wù)端都會為該客戶端創(chuàng)建一個 session,并將 session 的唯一標(biāo)識 sessionId 通過設(shè)置 Set-Cookie 頭的方式響應(yīng)給客戶端,客戶端將 sessionId 存到 cookie 中。
通常情況下,我們 cookie 和 session 都是結(jié)合著來用,當(dāng)然你也可以單獨(dú)只使用 cookie 或者單獨(dú)只使用 session,這里我們就將 cookie 和 session 結(jié)合著來用。
我們可以在修改一下整個請求過程圖,如下所示:
4.cookie 和 session 的區(qū)別?
前面兩節(jié)我們介紹了 cookie 和 session,它們兩者之間主要是通過 sessionId 關(guān)聯(lián)起來的,所以我們總結(jié)出:sessionId 是 cookie 和 session 之間的橋梁。我們?nèi)粘5南到y(tǒng)中如果在鑒權(quán)方面如果使用的是 cookie 方式,那么大部分的原理就和我們前面說的一樣。
或者我們可以換個說法,session 是基于 cookie 實(shí)現(xiàn)的,它們兩個主要有以下特點(diǎn):
- session 比 cookie 更加安全,因?yàn)樗谴嬖诜?wù)端的,cookie 是存在客戶端的。
- cookie 只支持存儲字符串?dāng)?shù)據(jù),session 可以存儲任意數(shù)據(jù)。
- cookie 的有效期可以設(shè)置較長時間,session 有效期都比較短。
- session 存儲空間很大,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)槊看握埱蠖紩y帶 cookie。
- 增加服務(wù)端資源消耗,因?yàn)槊總€客戶端連接進(jìn)來都需要生成 session,會占用服務(wù)端資源的。
- 容易遭受 CSRF 攻擊,即跨站域請求偽造。
那么為了避免這些缺點(diǎn),token 方式的鑒權(quán)出現(xiàn)了,它可以說是一個民間的認(rèn)證方式,但是不得不說它帶來了非常多的好處。
token 的組成:
token 其實(shí)就是一串字符串而已,只不過它是被加密后的字符串,它通常使用 uid(用戶唯一標(biāo)識)、時間戳、簽名以及一些其它參數(shù)加密而成。我們將 token 進(jìn)行解密就可以拿到諸如 uid 這類的信息,然后通過 uid 來進(jìn)行接下來的鑒權(quán)操作。
token 是如何生成的:
前面我們說 cookie 是服務(wù)端設(shè)置了 set-cookie 響應(yīng)頭之后,瀏覽器會自動保存 cookie,然后下一次發(fā)送請求的時候會自動把 cookie 攜帶上。但是我們說 cookie 算是一種民間的實(shí)現(xiàn)方式,所以說瀏覽器自然不會對它進(jìn)行成么處理。token 主要是由服務(wù)器生成,然后返回給客戶端,客戶端手動把 token 存下來,比如利用 localstorage 或者直接存到 cookie 當(dāng)中也行。
token 認(rèn)證流程:
- 客戶端發(fā)起登錄請求,比如用戶輸入用戶名和密碼后登錄。
- 服務(wù)端校驗(yàn)用戶名和密碼后,將用戶 id 和一些其它信息進(jìn)行加密,生成 token。
- 服務(wù)端將 token 響應(yīng)給客戶端。
- 客戶端收到響應(yīng)后將 token 存儲下來。
- 下一次發(fā)送請求后需要將 token 攜帶上,比如放在請求頭中或者其它地方。
- 服務(wù)端 token 后校驗(yàn),校驗(yàn)通過則正常返回數(shù)據(jù)。
用圖表示大致如下:
總結(jié)
雖然前面解釋 cookie、session、token 用了不少口舌,但是歸根結(jié)底啊,它們的目的都是一樣的:鑒權(quán)和認(rèn)證。
鑒權(quán)認(rèn)證方式 | 特點(diǎn) | 優(yōu)點(diǎn) | 缺點(diǎn) |
---|---|---|---|
cookie | 1.存儲在客戶端。2.請求自動攜帶 cookie。3.存儲大小 4KB。 | 1.兼容性好,因?yàn)槭潜容^老的技術(shù)。2.很容易實(shí)現(xiàn),因?yàn)?cookie 會自動攜帶和存儲。 | 1.需要單獨(dú)解決跨域攜帶問題,比如多臺服務(wù)器如何共享 cookie。2.會遭受 CSRF 攻擊。3.存儲在客戶端,不夠安全。 |
session | 1.存儲在服務(wù)端。2.存儲大小無限制。 | 1.查詢速度快,因?yàn)槭莻€會話,相當(dāng)于是在內(nèi)存中操作。2.結(jié)合 cookie 后很容易實(shí)現(xiàn)鑒權(quán)。3.安全,因?yàn)榇鎯υ诜?wù)端。 | 1.耗費(fèi)服務(wù)器資源,因?yàn)槊總€客戶端都會創(chuàng)建 session。2.占據(jù)存儲空間,session 相當(dāng)于存儲了一個完整的用戶信息。 |
token | 1.體積很小。2.自由操作存儲在哪里。 | 1.安全,因?yàn)?token 一般只有用戶 id,就算被截取了也沒什么用。2.無需消耗服務(wù)器內(nèi)存資源,它相當(dāng)于只存了用戶 id,session 相當(dāng)于存儲了用戶的所有信息。3.跨域處理較為方便,比如多臺服務(wù)器之間可以共用一個 token。 | 1.查詢速度慢,因?yàn)?token 只存了用戶 id,每次需要去查詢數(shù)據(jù)庫。 |
總結(jié)下來就是:session 是空間換時間,token 是時間換空間。
附:cookie/session的聯(lián)系
session雖說存放在服務(wù)器端,但是仔細(xì)看剛才的執(zhí)行流程你會明白,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存放在客戶端總會輕易被不法分子獲取
5.如果是訪問量特別大的網(wǎng)站,盡量不要在session中存儲用戶數(shù)據(jù),因?yàn)槊總€用戶存一個session會給服務(wù)器造成很大的壓力
但需要注意的是,若服務(wù)器做了負(fù)載均衡,用戶的下一次請求可能會被定向到其它服務(wù)器節(jié)點(diǎn),若那臺節(jié)點(diǎn)上沒有用戶的Session信息,就會導(dǎo)致會話驗(yàn)證失敗。所以Session默認(rèn)機(jī)制下是不適合分布式部署的。
到此這篇關(guān)于session、cookie、token區(qū)別的文章就介紹到這了,更多相關(guān)session、cookie、token區(qū)別內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
進(jìn)制轉(zhuǎn)換算法原理(二進(jìn)制 八進(jìn)制 十進(jìn)制 十六進(jìn)制)
進(jìn)制轉(zhuǎn)換算法原理(二進(jìn)制 八進(jìn)制 十進(jìn)制 十六進(jìn)制),以前上學(xué)那會確實(shí)學(xué)過,長時間不用都忘了。2010-05-05git提交報錯pre -commit hook failed (add 
這篇文章主要介紹了git提交報錯pre -commit hook failed (add --no-verify)問題及解決方案,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2023-11-11在VSCode中如何配置Python開發(fā)環(huán)境
VScode是一個相當(dāng)優(yōu)秀的IDE,具備開源、跨平臺、模塊化、插件豐富、啟動時間快、顏值高、可高度定制等等優(yōu)秀的特質(zhì),所以用VScode來編寫Python,也是相當(dāng)?shù)暮糜玫?。所以,今天我們就來講講,怎么在VScode上配置Python開發(fā)環(huán)境。2020-01-01git log根據(jù)特定條件查詢?nèi)罩静⒔y(tǒng)計(jì)修改的代碼行數(shù)
這篇文章主要介紹了git log根據(jù)特定條件查詢?nèi)罩静⒔y(tǒng)計(jì)修改的代碼行數(shù),本文給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下2020-09-09關(guān)于base64編碼的原理及實(shí)現(xiàn)方法分享
我們的圖片大部分都是可以轉(zhuǎn)換成base64編碼的data:image。 這個在將canvas保存為img的時候尤其有用2012-03-03