建站
咨詢
售后
建站咨詢
新聞中心
?引言
由于 HTTP 協(xié)議是無(wú)狀態(tài)的，完成操作關(guān)閉瀏覽器后，客戶端和服務(wù)端的連接就斷開了，所以我們必須要有一種機(jī)制來(lái)保證客戶端和服務(wù)端之間會(huì)話的連續(xù)性，也稱為認(rèn)證，最常見的應(yīng)用場(chǎng)景就是保持用戶的登錄態(tài)。
創(chuàng)新互聯(lián)是一家專業(yè)提供三沙企業(yè)網(wǎng)站建設(shè),專注與網(wǎng)站制作、做網(wǎng)站、H5開發(fā)、小程序制作等業(yè)務(wù)。10年已為三沙眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站建設(shè)公司優(yōu)惠進(jìn)行中。
最基本的認(rèn)證方式，就是使用 Sesson-Cookie。
30s 圖解 Sesson-Cookie 認(rèn)證
以保持用戶登錄態(tài)為例，Sesson-Cookie 認(rèn)證的具體步驟如下：
1）客戶端（瀏覽器）： 向服務(wù)器發(fā)送登錄信息（用戶名和密碼）來(lái)請(qǐng)求登錄校驗(yàn)；
2）服務(wù)端： 驗(yàn)證登錄信息，驗(yàn)證通過(guò)后服務(wù)器（比如 Tomcat）會(huì)自動(dòng)為此次請(qǐng)求開辟一塊內(nèi)存空間（一個(gè) Session 對(duì)象），可以手動(dòng)將用戶信息（比如登錄保持時(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)是依賴于 Cookie 的
3）客戶端： 收到服務(wù)端的響應(yīng)后會(huì)解析響應(yīng)頭，從而根據(jù) set-Cookie? 將 sessonId 保存在本地 Cookie 中，這樣，客戶端（瀏覽器）在下次 HTTP 請(qǐng)求時(shí)請(qǐng)求頭會(huì)自動(dòng)附上該域名下的 Cookie 信息；
4）服務(wù)端： 接收客戶端請(qǐng)求時(shí)會(huì)去解析請(qǐng)求頭 Cookie 中的 sessonId?，然后根據(jù)這個(gè) sessonId 去找 Sesson 對(duì)象，從而獲取到用戶信息；
可以通過(guò)攔截器在每次請(qǐng)求前嘗試獲取 Sesson 對(duì)象：Session 存活期間，我們認(rèn)為客戶端一直處于活躍狀態(tài)（用戶處于登錄態(tài)），一旦 Session 超期過(guò)時(shí)，那么就可以認(rèn)為客戶端已經(jīng)停止和服務(wù)器進(jìn)行交互了（用戶退出登錄）。
如果遇到禁用 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 中的？
Cookie 長(zhǎng)度的限制：首先，最基本的，Cookie 是有長(zhǎng)度限制的，這限制了它能存儲(chǔ)的數(shù)據(jù)的長(zhǎng)度
性能影響：Cookie 確實(shí)和 Session 一樣可以讓服務(wù)端程序跟蹤每個(gè)客戶端的訪問(wèn)，但是每次客戶端的訪問(wèn)都必須傳回這些 Cookie，那如果 Cookie 中存儲(chǔ)的數(shù)據(jù)比較多的話，這無(wú)疑增加了客戶端與服務(wù)端之間的數(shù)據(jù)傳輸量，增加了服務(wù)器的壓力。
安全性：Session 數(shù)據(jù)其實(shí)是屬于服務(wù)端的數(shù)據(jù)，而 Cookie 屬于客戶端，把本應(yīng)在 Session 中存儲(chǔ)的數(shù)據(jù)放到客戶端 Cookie，使得服務(wù)端數(shù)據(jù)延伸到了外部網(wǎng)絡(luò)及客戶端，顯然是存在安全性上的問(wèn)題的。當(dāng)然我們可以對(duì)這些數(shù)據(jù)做加密，不過(guò)從技術(shù)來(lái)講物理上不接觸才是最安全的。
附加閱讀
Sesson-Cookie 認(rèn)證偽代碼
登錄：
攔截器：每次請(qǐng)求前去找 Sesson 對(duì)象，從而獲取到用戶信息
可以看出來(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)將用戶數(shù)據(jù)設(shè)置到了 Session 中，并沒有出現(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ù)器，客戶端 1 向服務(wù)器發(fā)送了一個(gè)請(qǐng)求，由于負(fù)載均衡的存在，該請(qǐng)求被轉(zhuǎn)發(fā)給了服務(wù)器 A，于是服務(wù)器 A 創(chuàng)建并存儲(chǔ)了這個(gè) Session
緊接著，客戶端 1 又向服務(wù)器發(fā)送了一個(gè)請(qǐng)求，但是這一次請(qǐng)求被負(fù)載均衡給了服務(wù)器 B，而服務(wù)器 B 這時(shí)候是沒有存儲(chǔ)服務(wù)器 A 的 Session 的，這就導(dǎo)致 Session 的失效。
明明用戶在上一個(gè)界面還是登錄的，跳到下一個(gè)界面就退出登錄了，這顯然不合理。
當(dāng)然了，對(duì)此的解決方法其實(shí)也有很多種，其實(shí)就是如何解決 Session 在多個(gè)服務(wù)器之間的共享問(wèn)題：
Sesson Replication
Sesson Sticky
Sesson 數(shù)據(jù)集中存儲(chǔ)
Session Replication
這個(gè)是最容易想到的，既然服務(wù)器 B 沒有服務(wù)器 A 存儲(chǔ)的 Session，那各個(gè)服務(wù)器之間同步一下 Session 數(shù)據(jù)不就完了。
這種方案存在的問(wèn)題也是顯而易見的：
同步 Session 數(shù)據(jù)帶來(lái)了額外的網(wǎng)絡(luò)帶寬開銷。只要 Session 數(shù)據(jù)有變化，就需要將數(shù)據(jù)同步到所有其他機(jī)器上，機(jī)器越多，同步帶來(lái)的網(wǎng)絡(luò)帶寬開銷就越大。
每臺(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
從名稱也能看出來(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)題的：
如果某臺(tái)服務(wù)器宕機(jī)或者重啟了，那么它上面存儲(chǔ)的 Session 數(shù)據(jù)就丟失了，用戶就需要重新進(jìn)行登陸。
負(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ò)度依賴外部存儲(chǔ)，如果集中存儲(chǔ) Session 的外部存儲(chǔ)機(jī)器出問(wèn)題了，就會(huì)直接影響到我們的應(yīng)用
文章題目：30s看懂基礎(chǔ)的認(rèn)證方式:Session-Cookie認(rèn)證
當(dāng)前地址：http://m.5511xx.com/article/dhiphid.html
