我們在平時的編程學習中，經常會接觸到“ Session,Token”這兩個概念；
但是很多小白傻傻分不清楚“他們之間的區別、聯系、適用場景 ，甚至是在查閱了很多資料之后仍然是云山霧罩。
通過本文知識，讓我們花5分鐘時間徹底搞懂它，相信聰明的你，看完一定會有收獲！

# 為什么要引入會話管理？

首先，HTTP協議是一個“無狀態”的協議，所以服務器并不能自動區分出前后兩次請求是否來自同一個客戶端（或用戶）。
但是，很多業務場景，必須要區分出來訪者的身份。
因此，服務器端必須要建立一套會話管理機制，來解決“http協議無狀態的問題”。

# Session

定義：

是指在服務器端存儲（并區分）當前訪問客戶端（非用戶哦）會話的一種機制。
流程：
1）當客戶端第一次請求服務器時，服務器端會生成一個sessionid（一般是文件形式存儲）作為該客戶端的唯一標識，并通過在響應頭中（ResponseHeaders）下發Set-Cookie，通知瀏覽器需要保存該標識。
2）當客戶端第N次（N>=2）請求服務器時，會在請求頭中（RequestHeaders）自動攜帶這個Cookie:sessionid=xx
3）當服務器再次接收客戶端請求時，會先去請求頭中檢查是否存在Cookie:sessionid=xx，如果沒有Cookie或者 Cookie過期，就提示用戶”必須登錄后才能訪問“，從而實現（并區分）有狀態的會話管理。

通過以上知識，我們能夠清楚的知道以下4個經典面試題的答案：

1）如果瀏覽器cookie被禁用，那么session機制也會同時失效；
2）如果相同的用戶賬號，利用不同瀏覽器登錄系統，那么Session并不相同
3）如果關閉瀏覽器，Session會話并不會立即關閉（因為只有當session在服務器端過期時，服務器才會去刪除session文件本身）
4）如果web服務器做了多臺負載均衡機制，那么當某個請求被路由到另一臺業務均衡服務器時，Session也會丟失。

# 集群會話管理

眾所周知，單個服務器的負載上限是一個固定值。

傳統Session機制只適合單機版應用，一旦項目用戶數量達到一定規模，服務器集群改造方案就會變得刻不容緩。

集群環境下的會話管理，目前業界有兩種主流解決方案：

方案1：提供session共享機制
原理：不再用文件存儲session，而是用第三方中間件（比如redis）來管理session
優點：項目改造成本較?。ㄒ驗榇a風格跟傳統是一脈相承）
缺點：依賴于集中式中間件，一旦中間件本身性能出問題，就會立刻導致系統瓶頸。

方案2：token令牌方案
原理：
1）token 由服務器本身根據算法生成后下發給客戶端，服務器端無需額外存儲。

2）客戶端請求服務器時，在請求頭中追加攜帶該token

3）服務器端對token進行驗簽，從而決定本次訪問是拒絕還是放行。

優點：不依賴任何集中式中間件（完全依賴服務器算力解決）
缺點：token一旦下發，有效期就已經確定，不能像Session一樣可以在服務器端隨時中止會話。

# cookie

1、Cookie 的兩個作用（ 適用場景）：
1）記錄用戶身份
用戶A第一次訪問a網站,a網站會返回給用戶A一個sessionid，這樣A每次訪問a網站就會帶上這個會話
2）記錄用戶歷史
假設a是一個購物網站，用戶B把B1,B2商品加入購物車，過了幾天后，B再次打開網站，發現商品仍然會在購物車中（因為瀏覽器不會輕易刪除cookie）

2、cookie 的屬性
Cookie 有很多配置屬性，比較關鍵的有3個：
1）Path：
是指服務器資源路徑（而不是指客戶端存放的路徑?。。。?br />2）HttpOnly
在cookie上設置HttpOnly標識，瀏覽器就會知道該cookie只能由服務器獲取，而客戶端本身js腳本的訪問都會被禁止，從而提升系統安全性。
3）Secure
在cookie上設置Secure標識，那么就只有在使用 https 協議的時候自動攜帶 Cookie。從而提升系統安全性。

3、cookie 的限制
cookie是由瀏覽器管理的，很多瀏覽器為了自身性能會添加一些限制：
1）一般情況下，單個站點，最多允許保存20個cookie；
2）一般情況下，單個cookie，最多允許保存4K數據；

【全文完】