由于 HTTP 協(xié)議是無(wú)狀態(tài)的，完成操作關(guān)閉瀏覽器后，客戶(hù)端和服務(wù)端的連接就斷開(kāi)了，所以我們必須要有一種機(jī)制來(lái)保證客戶(hù)端和服務(wù)端之間會(huì)話的連續(xù)性，也稱(chēng)為認(rèn)證，最常見(jiàn)的應(yīng)用場(chǎng)景就是保持用戶(hù)的登錄態(tài)。

最基本的認(rèn)證方式，就是使用 Sesson-Cookie。

30s 圖解 Sesson-Cookie 認(rèn)證

以保持用戶(hù)登錄態(tài)為例，Sesson-Cookie 認(rèn)證的具體步驟如下：

1）客戶(hù)端（瀏覽器）：?向服務(wù)器發(fā)送登錄信息（用戶(hù)名和密碼）來(lái)請(qǐng)求登錄校驗(yàn)；

2）服務(wù)端：?驗(yàn)證登錄信息，驗(yàn)證通過(guò)后服務(wù)器（比如 Tomcat）會(huì)自動(dòng)為此次請(qǐng)求開(kāi)辟一塊內(nèi)存空間（一個(gè) Session 對(duì)象），可以手動(dòng)將用戶(hù)信息（比如登錄保持時(shí)間是否過(guò)期）存在 Session 對(duì)象中。然后，服務(wù)器會(huì)自動(dòng)為這個(gè) Sesson 對(duì)象生成一個(gè)唯一的標(biāo)識(shí) sessionID ，并在 HTTP 響應(yīng)頭（Header）的?Set-Cookie：JSESSIONID=XXXXXXX?中設(shè)置這個(gè) seesionID。

所以說(shuō)，Session 的實(shí)現(xiàn)是依賴(lài)于 Cookie 的

3）客戶(hù)端：?收到服務(wù)端的響應(yīng)后會(huì)解析響應(yīng)頭，從而根據(jù)?set-Cookie?將?sessonId?保存在本地 Cookie 中，這樣，客戶(hù)端（瀏覽器）在下次 HTTP 請(qǐng)求時(shí)請(qǐng)求頭會(huì)自動(dòng)附上該域名下的 Cookie 信息；

4）服務(wù)端：?接收客戶(hù)端請(qǐng)求時(shí)會(huì)去解析請(qǐng)求頭 Cookie 中的?sessonId，然后根據(jù)這個(gè)?sessonId?去找 Sesson 對(duì)象，從而獲取到用戶(hù)信息；

可以通過(guò)攔截器在每次請(qǐng)求前嘗試獲取 Sesson 對(duì)象：Session 存活期間，我們認(rèn)為客戶(hù)端一直處于活躍狀態(tài)（用戶(hù)處于登錄態(tài)），一旦 Session 超期過(guò)時(shí)，那么就可以認(rèn)為客戶(hù)端已經(jīng)停止和服務(wù)器進(jìn)行交互了（用戶(hù)退出登錄）。

如果遇到禁用 Cookie 的情況，一般的做法就是把這個(gè) sessionID 放到 URL 參數(shù)中。這也是經(jīng)常在面試中會(huì)被問(wèn)到的問(wèn)題。

可能會(huì)有同學(xué)問(wèn)為啥不直接把數(shù)據(jù)全部存在 Cookie 中，還整個(gè) Session 出來(lái)然后把 sessionID 存在 Cookie 中的？

1. Cookie 長(zhǎng)度的限制：首先，最基本的，Cookie 是有長(zhǎng)度限制的，這限制了它能存儲(chǔ)的數(shù)據(jù)的長(zhǎng)度

2. 性能影響：Cookie 確實(shí)和 Session 一樣可以讓服務(wù)端程序跟蹤每個(gè)客戶(hù)端的訪問(wèn)，但是每次客戶(hù)端的訪問(wèn)都必須傳回這些 Cookie，那如果 Cookie 中存儲(chǔ)的數(shù)據(jù)比較多的話，這無(wú)疑增加了客戶(hù)端與服務(wù)端之間的數(shù)據(jù)傳輸量，增加了服務(wù)器的壓力。

3. 安全性：Session 數(shù)據(jù)其實(shí)是屬于服務(wù)端的數(shù)據(jù)，而 Cookie 屬于客戶(hù)端，把本應(yīng)在 Session 中存儲(chǔ)的數(shù)據(jù)放到客戶(hù)端 Cookie，使得服務(wù)端數(shù)據(jù)延伸到了外部網(wǎng)絡(luò)及客戶(hù)端，顯然是存在安全性上的問(wèn)題的。當(dāng)然我們可以對(duì)這些數(shù)據(jù)做加密，不過(guò)從技術(shù)來(lái)講物理上不接觸才是最安全的。

附加閱讀

Sesson-Cookie 認(rèn)證偽代碼

登錄：

攔截器：每次請(qǐng)求前去找 Sesson 對(duì)象，從而獲取到用戶(hù)信息

可以看出來(lái)，在一次會(huì)話當(dāng)中，兩個(gè)請(qǐng)求獲取到的 Session 對(duì)象實(shí)際上是同一個(gè)對(duì)象。

上面已經(jīng)提到，服務(wù)器是根據(jù) cookie 中的 sessionID 來(lái)找到 Session 對(duì)象的，但以上代碼中我們只是手動(dòng)將用戶(hù)數(shù)據(jù)設(shè)置到了 Session 中，并沒(méi)有出現(xiàn)任何關(guān)于 Cookie 的代碼（將 SessionId 設(shè)置到 Cookie 中）

很明顯，這些肯定都是服務(wù)器（比如 Tomcat）自動(dòng)完成的了。在第一次獲取 Session 即調(diào)用?request.getSession()?的時(shí)候，服務(wù)器會(huì)自動(dòng)創(chuàng)建一個(gè) Session 對(duì)象（Session 是一個(gè)集合，并且是一個(gè) Map 集合），并且存入服務(wù)器的 Session 集合中以 SessionId 為標(biāo)識(shí)鍵，也就是說(shuō)根據(jù) SessionId 即可取到對(duì)應(yīng) Session 的引用。同時(shí)也會(huì)創(chuàng)建一個(gè)鍵名為 JSESSIONID 的 Cookie 并且返回給瀏覽器，該 Cookie 的值即為 SessionId。

這個(gè)存儲(chǔ)著 SessionId 的 Cookie 會(huì)跟著請(qǐng)求上傳到服務(wù)器，所以說(shuō)，在同一會(huì)話當(dāng)中，不管哪個(gè)請(qǐng)求拿到的都是同一個(gè) Session 對(duì)象。

Sesson-Cookie 認(rèn)證的缺點(diǎn)與解決方案

這種機(jī)制在單體應(yīng)用時(shí)代應(yīng)用非常廣泛，但是，隨著分布式時(shí)代的到來(lái)，Session 的缺點(diǎn)也逐漸暴露出來(lái)。

舉個(gè)例子，比如我們有多個(gè)服務(wù)器，客戶(hù)端 1 向服務(wù)器發(fā)送了一個(gè)請(qǐng)求，由于負(fù)載均衡的存在，該請(qǐng)求被轉(zhuǎn)發(fā)給了服務(wù)器 A，于是服務(wù)器 A 創(chuàng)建并存儲(chǔ)了這個(gè) Session

緊接著，客戶(hù)端 1 又向服務(wù)器發(fā)送了一個(gè)請(qǐng)求，但是這一次請(qǐng)求被負(fù)載均衡給了服務(wù)器 B，而服務(wù)器 B 這時(shí)候是沒(méi)有存儲(chǔ)服務(wù)器 A 的 Session 的，這就導(dǎo)致 Session 的失效。

明明用戶(hù)在上一個(gè)界面還是登錄的，跳到下一個(gè)界面就退出登錄了，這顯然不合理。

當(dāng)然了，對(duì)此的解決方法其實(shí)也有很多種，其實(shí)就是如何解決 Session 在多個(gè)服務(wù)器之間的共享問(wèn)題：

1. Sesson Replication

2. Sesson Sticky

3. Sesson 數(shù)據(jù)集中存儲(chǔ)

Session Replication

這個(gè)是最容易想到的，既然服務(wù)器 B 沒(méi)有服務(wù)器 A 存儲(chǔ)的 Session，那各個(gè)服務(wù)器之間同步一下 Session 數(shù)據(jù)不就完了。

這種方案存在的問(wèn)題也是顯而易見(jiàn)的：

1. 同步 Session 數(shù)據(jù)帶來(lái)了額外的網(wǎng)絡(luò)帶寬開(kāi)銷(xiāo)。只要 Session 數(shù)據(jù)有變化，就需要將數(shù)據(jù)同步到所有其他機(jī)器上，機(jī)器越多，同步帶來(lái)的網(wǎng)絡(luò)帶寬開(kāi)銷(xiāo)就越大。

2. 每臺(tái)Web服務(wù)器都要保存所有 Session 數(shù)據(jù)，如果整個(gè)集群的 Session 數(shù)據(jù)很多（比如很多人同時(shí)訪問(wèn)網(wǎng)站的情況），每臺(tái)服務(wù)器用于保存 Session 數(shù)據(jù)的內(nèi)存占用會(huì)非常嚴(yán)重。

Session Sticky

從名稱(chēng)也能看出來(lái)，Sticky，即讓負(fù)載均衡器能夠根據(jù)每次的請(qǐng)求的會(huì)話標(biāo)識(shí)來(lái)進(jìn)行請(qǐng)求的轉(zhuǎn)發(fā)，保證一個(gè)會(huì)話中的每次請(qǐng)求都能落到同一臺(tái)服務(wù)器上面。

存在問(wèn)題的：

1. 如果某臺(tái)服務(wù)器宕機(jī)或者重啟了，那么它上面存儲(chǔ)的 Session 數(shù)據(jù)就丟失了，用戶(hù)就需要重新進(jìn)行登陸。

2. 負(fù)載均衡器變?yōu)橐粋€(gè)有狀態(tài)的節(jié)點(diǎn)，因?yàn)樗枰４?Session 到具體服務(wù)器的映射，和之前無(wú)狀態(tài)的節(jié)點(diǎn)相比，內(nèi)存消耗會(huì)更大，容災(zāi)方面會(huì)更麻煩。

Session 數(shù)據(jù)集中存儲(chǔ)

將每個(gè)服務(wù)器的 Session 數(shù)據(jù)都集中存到外部介質(zhì)比如 Redis 或者 MySQL 中去，然后所有的服務(wù)器都從這個(gè)外部介質(zhì)中拿 Session 就行了

存在的問(wèn)題也很顯然：

• 過(guò)度依賴(lài)外部存儲(chǔ)，如果集中存儲(chǔ) Session 的外部存儲(chǔ)機(jī)器出問(wèn)題了，就會(huì)直接影響到我們的應(yīng)用