http協議是無狀態協議，cookie、session、token可以幫助服務器區分到底是誰在訪問
目錄
session
服務器使用session把用戶的信息臨時保存在了服務器上，用戶離開網站后session會被銷毀。這種用戶信息存儲方式相對cookie來說更安全，可是session有一個缺陷：如果web服務器做了負載均衡，那么下一個操作請求到了另一台服務器的時候session會丟失。
現在的在線購物網站，需要登錄的網站等等，馬上就面臨一個問題，那就是要管理會話，必須記住哪些人登錄系統， 哪些人往自己的購物車中放商品， 也就是說我必須把每個人區分開，這就是一個不小的挑戰，因為HTTP請求是無狀態的，所以想出的辦法就是給大家發一個會話標識(session id), 說白了就是一個隨機的字串，每個人收到的都不一樣， 每次大家向我發起HTTP請求的時候，把這個字符串給一並捎過來， 這樣我就能區分開誰是誰了，每個人只需要保存自己的session id，而服務器要保存所有人的session id ！如果訪問服務器多了， 就得由成千上萬，甚至幾十萬個。
這對服務器說是一個巨大的開銷 ， 嚴重的限制了服務器擴展能力， 比如說我用兩個機器組成了一個集群， 小F通過機器A登錄了系統， 那session id會保存在機器A上， 假設小F的下一次請求被轉發到機器B怎么辦？機器B可沒有小F的 session id啊。
有時候會采用： session sticky ， 就是讓小F的請求一直粘連在機器A上， 但是這也不管用， 要是機器A掛掉了， 還得轉到機器B去。
那只好做session 的復制了， 把session id 在兩個機器之間搬來搬去。
后來有個叫Memcached的支了招：把session id 集中存儲到一個地方， 所有的機器都來訪問這個地方的數據， 這樣一來，就不用復制了， 但是增加了單點失敗的可能性， 要是那個負責session 的機器掛了， 所有人都得重新登錄一遍。
也嘗試把這個單點的機器也搞出集群，增加可靠性， 但不管如何， 這小小的session 對后台來說是一個沉重的負擔
Token
在Web領域基於Token的身份驗證隨處可見。在大多數使用Web API的互聯網公司中，tokens 是多用戶下處理認證的最佳方式。
1.用戶通過用戶名和密碼向服務端發送請求
2.服務端通過驗證，生成一個token發送給客戶端
3.客戶端保存token，發送請求時帶上token
4.服務器通過驗證，返回數據
token的優勢
1.無狀態、可擴展
2.支持移動設備
3.跨程序調用
4.安全
大部分你見到過的API和Web應用都使用tokens。例如Facebook, Twitter, Google+, GitHub等。
比如說， 小F已經登錄了系統， 我給他發一個令牌(token)， 里邊包含了小F的 user id， 下一次小F 再次通過Http 請求訪問我的時候， 把這個token 通過Http header 帶過來不就可以了。
帶過來之后就可以通過user id 查到他的權限和和他相關各種數據返回了了。
安全性
對數據做一個簽名， 比如說HMAC-SHA256 算法，加上一個只有我才知道的密鑰， 對數據做一個簽名， 把這個簽名和數據一起作為token ， 由於密鑰別人不知道， 就無法偽造token了。
這個token 我不保存， 當用戶把這個token 給我發過來的時候，我再用同樣的HMAC-SHA256 算法和同樣的密鑰，對數據再計算一次簽名， 和token 中的簽名做個比較， 如果相同， 我就知道用戶已經登錄過了，並且可以直接取到該用戶的的user id , 如果不相同， 數據部分肯定被人篡改過，就證明這個人沒有登錄
這樣還是維持了http 無狀態情況，機器集群現在可以輕松地做水平擴展， 用戶訪問量增大， 直接加機器就行。
Cookie
cookie和session的區別就是保存在了前端。而session保存在了后端，兩者都是后端生成。具體來說cookie機制采用的是在客戶端保持狀態的方案，而session機制采用的是在服務器端保持狀態的方案。同時我們也看到，由於采用服務器端保持狀態的方案在客戶端也需要保存一個標識，所以session機制可能需要借助於cookie機制來達到保存標識的目的。cookie不是很安全，別人可以分析存放在本地的cookie並進行cookie欺騙，考慮到安全應當使用session， session會在一定時間內保存在服務器上。當訪問增多，會比較占用你服務器的性能，考慮到減輕服務器性能方面，應當使用cookie
單個cookie保存的數據不能超過4k,很多瀏覽器都限制一個站點最多保存20個cookie。
可以將登陸信息等重要信息存放為session。
使用cookie的缺點
如果瀏覽器使用的是 cookie，那么所有的數據都保存在瀏覽器端，
- cookie可以被用戶禁止
- cookie不安全(對於敏感數據，需要加密)
- cookie只能保存少量的數據(大約是4k)，cookie的數量也有限制(大約是幾百個)，不同瀏覽器設置不一樣，反正都不多
- cookie只能保存字符串
- 對服務器壓力小
使用session的缺點
一般是寄生在Cookie下的，當Cookie被禁止，Session也被禁止
當然可以通過url重寫來擺脫cookie
當用戶訪問量很大時，對服務器壓力大
我們現在知道session是將用戶信息儲存在服務器上面,如果訪問服務器的用戶越來越多,那么服務器上面的session也越來越多, session會對服務器造成壓力，影響服務器的負載.如果Session內容過於復雜，當大量客戶訪問服務器時還可能會導致內存溢出。
用戶信息丟失, 或者說用戶訪問的不是這台服務器的情況下,就會出現數據庫丟失.
基於服務器驗證方式暴露的一些問題
-
Seesion：每次認證用戶發起請求時，服務器需要去創建一個記錄來存儲信息。當越來越多的用戶發請求時，內存的開銷也會不斷增加。
-
可擴展性：在服務端的內存中使用Seesion存儲登錄信息，伴隨而來的是可擴展性問題。
-
CORS(跨域資源共享)：當我們需要讓數據跨多台移動設備上使用時，跨域資源的共享會是一個讓人頭疼的問題。在使用Ajax抓取另一個域的資源，就可以會出現禁止請求的情況。
-
CSRF(跨站請求偽造)：用戶在訪問銀行網站時，他們很容易受到跨站請求偽造的攻擊，並且能夠被利用其訪問其他的網站。
Tokens的優勢
無狀態、可擴展
在客戶端存儲的Tokens是無狀態的，並且能夠被擴展。基於這種無狀態和不存儲Session信息，負載負載均衡器能夠將用戶信息從一個服務傳到其他服務器上。
如果我們將已驗證的用戶的信息保存在Session中，則每次請求都需要用戶向已驗證的服務器發送驗證信息(稱為Session親和性)。用戶量大時，可能會造成一些擁堵。
使用tokens之后這些問題都迎刃而解
安全性
請求中發送token而不再是發送cookie能夠防止CSRF(跨站請求偽造)。即使在客戶端使用cookie存儲token，cookie也僅僅是一個存儲機制而不是用於認證。不將信息存儲在Session中，讓我們少了對session操作。
token是有時效的，一段時間之后用戶需要重新驗證。我們也不一定需要等到token自動失效，token有撤回的操作，通過token revocataion可以使一個特定的token或是一組有相同認證的token無效。
多平台跨域
CORS(跨域資源共享)對應用程序和服務進行擴展的時候，需要介入各種各種的設備和應用程序。
只要用戶有一個通過了驗證的token，數據和資源就能夠在任何域上被請求到。