一、HTTP協(xié)議是無狀態(tài)的

何為無狀態(tài)：服務(wù)器不會(huì)記錄用戶的瀏覽記錄，每次請(qǐng)求都是一個(gè)新的HTTP協(xié)議，就是請(qǐng)求加響應(yīng)。不用記錄誰剛剛發(fā)了HTTP請(qǐng)求， 每次請(qǐng)求都是全新的。

二、管理會(huì)話

隨著網(wǎng)絡(luò)的發(fā)展，交互式網(wǎng)站例如需要登錄的網(wǎng)站的興起，服務(wù)器就面臨一個(gè)問題，如何管理回話，如何記住那些人登錄過系統(tǒng)，哪些人往自己的購(gòu)物車中放商品，簡(jiǎn)單地說就是如何區(qū)分不同的用戶

三、cookie

cookie 是一個(gè)非常具體的東西，指的就是瀏覽器里面能永久存儲(chǔ)的一種數(shù)據(jù)。跟服務(wù)器沒啥關(guān)系，僅僅是瀏覽器實(shí)現(xiàn)的一種數(shù)據(jù)存儲(chǔ)功能。
cookie由服務(wù)器生成，發(fā)送給瀏覽器，瀏覽器把cookie以KV形式存儲(chǔ)到某個(gè)目錄下的文本文件中，下一次請(qǐng)求同一網(wǎng)站時(shí)會(huì)把該cookie發(fā)送給服務(wù)器。由于cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保cookie不會(huì)被惡意使用，同時(shí)不會(huì)占據(jù)太多磁盤空間。所以每個(gè)域的cookie數(shù)量是有限制的。

• 客戶端設(shè)置
  客戶端可以設(shè)置cookie的一下選項(xiàng): expires, domain, path, secure(只有在https協(xié)議的網(wǎng)頁中, 客戶端設(shè)置secure類型cookie才能生效), 但無法設(shè)置httpOnly選項(xiàng)
• 服務(wù)端設(shè)置
  不管你是請(qǐng)求一個(gè)資源文件(如html/js/css/圖片), 還是發(fā)送一個(gè)ajax請(qǐng)求, 服務(wù)端都會(huì)返回response.而response header中有一項(xiàng)叫set-cookie, 是服務(wù)端專門用來設(shè)置cookie的;

1.一個(gè)set-cookie只能設(shè)置一個(gè)cookie, 當(dāng)你想設(shè)置多個(gè), 需要添加同樣多的set-cookie 2.服務(wù)端可以設(shè)置cookie的所有選項(xiàng): expires, domain, path, secure, HttpOnly

• Cookie，SessionStorage，LocalStorage
  

四、session

session從字面上講，就是會(huì)話。這個(gè)就類似你和一個(gè)人交談，你怎么知道當(dāng)時(shí)和你交談的是張三而不是李四呢？對(duì)方肯定有某種特征（長(zhǎng)相等）表明他是張三；
session也是類似的道理，服務(wù)器要知道當(dāng)前請(qǐng)求發(fā)給自己的是誰。為了做這種區(qū)分，服務(wù)器就是要給每個(gè)客戶端分配不同的"身份標(biāo)識(shí)"，然后客戶端每次向服務(wù)器發(fā)請(qǐng)求的時(shí)候，都帶上這個(gè)”身份標(biāo)識(shí)“，服務(wù)器就知道這個(gè)請(qǐng)求來自與誰了。
至于客戶端怎么保存這個(gè)”身份標(biāo)識(shí)“，可以有很多方式，對(duì)于瀏覽器客戶端，大家都采用cookie的方式。

流程：

1.用戶向服務(wù)器發(fā)送用戶名和密碼 2.服務(wù)器驗(yàn)證通過后,在當(dāng)前對(duì)話(session)里面保存相關(guān)數(shù)據(jù),比如用戶角色, 登陸時(shí)間等; 3.服務(wù)器向用戶返回一個(gè)session_id, 寫入用戶的cookie 4.用戶隨后的每一次請(qǐng)求, 都會(huì)通過cookie, 將session_id傳回服務(wù)器 5.服務(wù)端收到 session_id, 找到前期保存的數(shù)據(jù), 由此得知用戶的身份

session和cookies的區(qū)別：

Cookie是客戶端技術(shù)，程序把每個(gè)用戶的數(shù)據(jù)以cookie的形式寫給用戶各自的瀏覽器。當(dāng)用戶使用瀏覽器再去訪問服務(wù)器中的web資源時(shí)，就會(huì)帶著各自的數(shù)據(jù)去。這樣，web資源處理的就是用戶各自的數(shù)據(jù)了。

Session是服務(wù)器端技術(shù)，利用這個(gè)技術(shù)，服務(wù)器在運(yùn)行時(shí)可以為每一個(gè)用戶的瀏覽器創(chuàng)建一個(gè)其獨(dú)享的session對(duì)象，由于session為用戶瀏覽器獨(dú)享，所以用戶在訪問服務(wù)器的web資源時(shí)，可以把各自的數(shù)據(jù)放在各自的session中，當(dāng)用戶再去訪問服務(wù)器中的其它web資源時(shí)，其它web資源再?gòu)挠脩舾髯缘膕ession中取出數(shù)據(jù)為用戶服務(wù)。而由于不知道哪個(gè)用戶對(duì)應(yīng)哪個(gè)session，所以又引入了cookies來記錄客戶端和session的映射關(guān)系(jsessionId)

session存在的問題（擴(kuò)展性不好）
單機(jī)當(dāng)然沒問題， 如果是服務(wù)器集群， 或者是跨域的服務(wù)導(dǎo)向架構(gòu)， 這就要求session數(shù)據(jù)共享，每臺(tái)服務(wù)器都能夠讀取session。
舉例來說， A網(wǎng)站和B網(wǎng)站是同一家公司的關(guān)聯(lián)服務(wù)。現(xiàn)在要求，用戶只要在其中一個(gè)網(wǎng)站登錄，再訪問另一個(gè)網(wǎng)站就會(huì)自動(dòng)登錄，請(qǐng)問怎么實(shí)現(xiàn)？這個(gè)問題就是如何實(shí)現(xiàn)單點(diǎn)登錄的問題

Nginx ip_hash 策略，服務(wù)端使用 Nginx 代理，每個(gè)請(qǐng)求按訪問 IP 的 hash 分配，這樣來自同一 IP 固定訪問一個(gè)后臺(tái)服務(wù)器，避免了在服務(wù)器 A 創(chuàng)建 Session，第二次分發(fā)到服務(wù)器 B 的現(xiàn)象。

Session復(fù)制：任何一個(gè)服務(wù)器上的 Session 發(fā)生改變（增刪改），該節(jié)點(diǎn)會(huì)把這個(gè) Session的所有內(nèi)容序列化，然后廣播給所有其它節(jié)點(diǎn)。

共享Session：將Session Id
集中存儲(chǔ)到一個(gè)地方，所有的機(jī)器都來訪問這個(gè)地方的數(shù)據(jù)。這種方案的優(yōu)點(diǎn)是架構(gòu)清晰，缺點(diǎn)是工程量比較大。另外，持久層萬一掛了，就會(huì)單點(diǎn)失敗；

對(duì)比

Servlet容器提供了Session機(jī)制以跟蹤用戶；

默認(rèn)的Session機(jī)制是以Cookie形式實(shí)現(xiàn)的，Cookie名稱為JSESSIONID；

通過讀寫Cookie可以在客戶端設(shè)置用戶偏好等。例如生效的路徑范圍，有效期等

另一種方案是服務(wù)器索性不保存session數(shù)據(jù)了，所有數(shù)據(jù)就保存在客戶端，每次請(qǐng)求都發(fā)回服務(wù)器。這種方案就是接下來要介紹的基于Token的驗(yàn)證;

五、Token

流程：

1.用戶通過用戶名和密碼發(fā)送請(qǐng)求 2.程序驗(yàn)證 3.程序返回一個(gè)簽名的token給客戶端 4.客戶端儲(chǔ)存token, 并且每次用每次發(fā)送請(qǐng)求 5.服務(wù)端驗(yàn)證Token并返回?cái)?shù)據(jù)

這個(gè)方式的技術(shù)其實(shí)很早就已經(jīng)有很多實(shí)現(xiàn)了，而且還有現(xiàn)成的標(biāo)準(zhǔn)可用，其中的一個(gè)標(biāo)準(zhǔn)就是JWT

六、JWT(JSON Web Token)

數(shù)據(jù)結(jié)構(gòu)
實(shí)際的JWT大概就像下面這樣：

JSON Web Tokens由dot（.）分隔的三個(gè)部分組成，它們是：

1.Header（頭部） 2.Payload（負(fù)載） 3.signature（簽名）

因此，JWT通常如下(xxxxx.yyyyy.zzzz)展示：

Header（頭部）

//Header 是一個(gè) JSON 對(duì)象 {"alg": "HS256", // 表示簽名的算法，默認(rèn)是 HMAC SHA256（寫成 HS256）"typ": "JWT" // 表示Token的類型，JWT 令牌統(tǒng)一寫為JWT }

Payload（負(fù)載）

//Payload 部分也是一個(gè) JSON 對(duì)象，用來存放實(shí)際需要傳遞的數(shù)據(jù) {// 7個(gè)官方字段"iss": "a.com", // issuer：簽發(fā)人"exp": "1d", // expiration time： 過期時(shí)間"sub": "test", // subject: 主題"aud": "xxx", // audience： 受眾"nbf": "xxx", // Not Before：生效時(shí)間"iat": "xxx", // Issued At： 簽發(fā)時(shí)間"jti": "1111", // JWT ID：編號(hào)// 可以定義私有字段"name": "John Doe","admin": true }

JWT 默認(rèn)是不加密的，任何人都可以讀到，所以不要把秘密信息放在這個(gè)部分。

Signature（簽名）

Signature 是對(duì)前兩部分的簽名，防止數(shù)據(jù)被篡改。
首先，需要指定一個(gè)密鑰(secret)。這個(gè)密鑰只有服務(wù)器才知道，不能泄露給用戶。然后，使用Header里面指定的簽名算法（默認(rèn)是 HMAC SHA256），按照下面的公式產(chǎn)生簽名。

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

復(fù)制代碼算出簽名后，把 Header、Payload、Signature 三個(gè)部分拼成一個(gè)字符串，每個(gè)部分之間用"點(diǎn)"（.）分隔，就可以返回給用戶。

JWT = Base64(Header) + "." + Base64(Payload) + "." + $Signature

如何保證安全？
發(fā)送JWT要使用HTTPS；不使用HTTPS發(fā)送的時(shí)候，JWT里不要寫入秘密數(shù)據(jù)JWT的payload中要設(shè)置expire時(shí)間

使用方式
客戶端收到服務(wù)器返回的 JWT，可以儲(chǔ)存在 Cookie 里面，也可以儲(chǔ)存在 localStorage。此后，客戶端每次與服務(wù)端通信，都要帶上這個(gè)JWT。你可以把它放在Cookie里面自動(dòng)發(fā)送，但是這樣不能跨域，所以更好的做法是放在HTTP請(qǐng)求的頭信息 Authorization 字段里面。

Authorization: Bearer <token>

復(fù)制代碼另一種做法是:

跨域的時(shí)候， JWT就放在POST請(qǐng)求的數(shù)據(jù)體里。

JWT 的作用
JWT最開始的初衷是為了實(shí)現(xiàn)授權(quán)和身份認(rèn)證作用的，可以實(shí)現(xiàn)無狀態(tài)，分布式的Web應(yīng)用授權(quán)。大致實(shí)現(xiàn)的流程如下:

客戶端需要攜帶用戶名/密碼等可證明身份的的內(nèi)容去授權(quán)服務(wù)器獲取JWT信息；

每次服務(wù)都攜帶該Token內(nèi)容與Web服務(wù)器進(jìn)行交互，由業(yè)務(wù)服務(wù)器來驗(yàn)證Token是否是授權(quán)發(fā)放的有效Token，來驗(yàn)證當(dāng)前業(yè)務(wù)是否請(qǐng)求合法。

這里需要注意：不是每次請(qǐng)求都要申請(qǐng)一次Token，這是需要注意，如果不是對(duì)于安全性要求的情況，不建議每次都申請(qǐng)，因?yàn)闀?huì)增加業(yè)務(wù)耗時(shí)；比如只在登陸時(shí)申請(qǐng)，然后使用JWT的過期時(shí)間或其他手段來保證JWT的有效性。

七、Acesss Token，Refresh Token

JWT最大的優(yōu)勢(shì)是服務(wù)器不再需要存儲(chǔ)Session，使得服務(wù)器認(rèn)證鑒權(quán)業(yè)務(wù)可以方便擴(kuò)展。這也是JWT最大的缺點(diǎn)，由于服務(wù)器不需要存儲(chǔ)Session狀態(tài)，因此使用過程中無法廢棄某個(gè)Token，或者更改Token的權(quán)限。也就是說一旦JWT簽發(fā)了，到期之前就會(huì)始終有效。
我們可以基于上面提到的問題做一些改進(jìn)。
前面講的Token，都是Acesss Token，也就是訪問資源接口時(shí)所需要的Token，還有另外一種Token，Refresh Token。一般情況下，Refresh Token的有效期會(huì)比較長(zhǎng)。而Access Token的有效期比較短，當(dāng)Acesss Token由于過期而失效時(shí)，使用Refresh Token就可以獲取到新的Token，如果Refresh Token也失效了，用戶就只能重新登錄了。Refresh Token及過期時(shí)間是存儲(chǔ)在服務(wù)器的數(shù)據(jù)庫中，只有在申請(qǐng)新的Acesss Token時(shí)才會(huì)驗(yàn)證，不會(huì)對(duì)業(yè)務(wù)接口響應(yīng)時(shí)間造成影響，也不需要向Session一樣一直保持在內(nèi)存中以應(yīng)對(duì)大量的請(qǐng)求。

總結(jié)

以上是生活随笔為你收集整理的Cookie，Session，Token的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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