Cookie 、Session 和Token
Cookie、Session和Token是當下互聯網的兩個非常重要的東西
起源
衆所周知，http協議是無狀態的，每個http請求(http 1.0)從瀏覽器發起請求到服務器處理完請求後，就結束了，客戶端和服務器的TCP鏈接就斷開了。一個網站服務器程序是要服務很多用戶的，每天要處理非常多的這種http請求，其中每個人又會發很多這種請求，那麼服務器程序如何識別哪些請求是來自與同一個用戶呢，是否可以每個請求帶上一些玩家的特徵信息呢？答案是，對的，這就是今天要講的主題了，Cookie、Seesion和Token。
Cookie
cookie是http協議的一部分，服務器程序迴應客戶端的http請求時，依據http協議規範可以向客戶端的cookie寫入內容。相應的客戶端瀏覽器每次給服務器程序發請求時候，請求內容都會攜帶cookie內容
Session
用戶登錄成功後，瀏覽器和服務器就建立了一條會話，再接下來的交互中就不用再去驗證用戶的帳號密碼了。具體實現就是，服務器程序對密碼檢驗成功後就給瀏覽器的cookie中設置了Session-key和Session-info（可以包含一些用戶信息，比如用戶id之類的），同時設置cookie的Max-Age，即過期時間。這樣子的話，服務器程序處理http請求的時候，先去http中帶上來的cookie中找Session信息，如果沒有則該用戶沒有登錄，則返回未登錄的內容給他，如果有信息，則取出用戶信息，根據用戶信息返回相應的內容給他。
當然實際情況並沒有這麼簡單，因爲存在cookie中的內容是很容易獲取的，所以爲了安全性，會把Session-info放在服務器上，而不是放到客戶端瀏覽器的cookie中，這樣子的話，cookie中只有一個Session-key，每次服務器程序收到http請求後會拿出cookie中的Session-key去索引對應的Session-info。常見的做法是把Session-info存到redis中，這樣存取效率高。
爲了提高安全性，防止Session-key被破解出來，可以再在cookie中設置一個Session-key的簽名Session-key.sig字段，當服務器程序收到http請求後，就去用相應的算法計算Session-key的簽名，然後比較是否和Session-key.sig一致，不一致則說明Session-key被篡改過，則本次請求無效。
由上可知，如果被不法分子盜取（不管是劫網絡包還是xss等行爲）了cookie中的這些值，那麼還是會不安全。可以使用https來防止劫持行爲。
Token
Token有點類似Session的機制。玩家登錄成功後，服務器程序會根據某種算法生存一個Token值（字符串）和一些Token信息（用戶id，過期時間，是否有效）等等，以Token爲主鍵存到數據庫中或Redis中，然後設置Token到cookie中。當有http請求時，服務器程序則把Token從cookie中取出，然後用Token去索引Token信息、檢驗是否過期，校驗通過後，拿着用戶id去處理後面的流程。
Session和Cookie區別
- 安全性：使用Cookie來保存狀態信息的話，容易被篡改，而Session機制，狀態信息可以存放在服務器，更安全
- 儲存容量性質：Cookie有最大容量上限，所以儲存不了太多狀態信息，而Session機制則可無限存儲
雖然Session優點更多，但是實際使用時候，不要把所有信息都存Session，因爲這樣子會增加服務器壓力，建議把登錄相關的重要信息放在Session，其他信息放在Cookie中
Session 和 Token
其實Session和Token總體上還是很相似的，但是也有以下區別：
1. 過期時間：Session的過期時間存在cookie的Max-age字段，Token的過期時間存在服務器
2. 使用範圍：Session-key的儲存依賴cookie機制，不能脫離瀏覽器；而Token可以不依賴cookie，哪怕是在get/post請求的參數中帶上來都可以，所以很多第三方的登錄\支付等API接口都是用Token這種機制