在Web應(yīng)用中，HTTP請求是無狀態(tài)的。即：用戶第一次發(fā)起請求，與服務(wù)器建立連接并登錄成功后，為了避免每次打開一個(gè)頁面都需要登錄一下，就出現(xiàn)了cookie，Session。
Cookie
Cookie是客戶端保存用戶信息的一種機(jī)制，用來記錄用戶的一些信息，也是實(shí)現(xiàn)Session的一種方式。Cookie存儲(chǔ)的數(shù)據(jù)量有限，且都是保存在客戶端瀏覽器中。不同的瀏覽器有不同的存儲(chǔ)大小，但一般不超過4KB。因此使用Cookie實(shí)際上只能存儲(chǔ)一小段的文本信息。
例如：登錄網(wǎng)站，今輸入用戶名密碼登錄了，第二天再打開很多情況下就直接打開了。這個(gè)時(shí)候用到的一個(gè)機(jī)制就是Cookie。
Session
Session是另一種記錄客戶狀態(tài)的機(jī)制，它是在服務(wù)端保存的一個(gè)數(shù)據(jù)結(jié)構(gòu)（主要存儲(chǔ)的的SessionID和Session內(nèi)容，同時(shí)也包含了很多自定義的內(nèi)容如：用戶基礎(chǔ)信息、權(quán)限信息、用戶機(jī)構(gòu)信息、固定變量等），這個(gè)數(shù)據(jù)可以保存在集群、數(shù)據(jù)庫、文件中，用于跟蹤用戶的狀態(tài)。客戶端瀏覽器訪問服務(wù)器的時(shí)候，服務(wù)器把客戶端信息以某種形式記錄在服務(wù)器上。這就是Session。客戶端瀏覽器再次訪問時(shí)只需要從該Session中查找該客戶的狀態(tài)就可以了。
用戶第一次登錄后，瀏覽器會(huì)將用戶信息發(fā)送給服務(wù)器，服務(wù)器會(huì)為該用戶創(chuàng)建一個(gè)SessionId，并在響應(yīng)內(nèi)容（Cookie）中將該SessionId一并返回給瀏覽器，瀏覽器將這些數(shù)據(jù)保存在本地. 當(dāng)用戶再次發(fā)送請求時(shí)，瀏覽器會(huì)自動(dòng)的把上次請求存儲(chǔ)的Cookie數(shù)據(jù)自動(dòng)的攜帶給服務(wù)器。服務(wù)器接收到請求信息后，會(huì)通過瀏覽器請求的數(shù)據(jù)中的SessionId判斷當(dāng)前是哪個(gè)用戶，然后根據(jù)SessionId在Session庫中獲取用戶的Session數(shù)據(jù)返回給瀏覽器。
例如：購物車，添加了商品之后客戶端處可以知道添加了哪些商品，而服務(wù)器端如何判別呢，所以也需要存儲(chǔ)一些信息就用到了Session。
如果說Cookie機(jī)制是通過檢查客戶身上的“通行證”來確定客戶身份的話，那么Session機(jī)制就是通過檢查服務(wù)器上的“客戶明細(xì)表”來確認(rèn)客戶身份。Session相當(dāng)于程序在服務(wù)器上建立的一份客戶檔案，客戶來訪的時(shí)候只需要查詢客戶檔案表就可以了。Session生成后，只要用戶繼續(xù)訪問，服務(wù)器就會(huì)更新Session的最后訪問時(shí)間，并維護(hù)該Session。為防止內(nèi)存溢出，服務(wù)器會(huì)把長時(shí)間內(nèi)沒有活躍的Session從內(nèi)存刪除。這個(gè)時(shí)間就是Session的超時(shí)時(shí)間。如果超過了超時(shí)時(shí)間沒訪問過服務(wù)器，Session就自動(dòng)失效了。
Token
HTTP請求都是以無狀態(tài)的形式對接。即HTTP服務(wù)器不知道本次請求和上一次請求是否有關(guān)聯(lián)。所以就有了Session的引入，即服務(wù)端和客戶端都保存一段文本，客戶端每次發(fā)起請求都帶著，這樣服務(wù)器就知道客戶端是否發(fā)起過請求。
這樣，就導(dǎo)致客戶端頻繁向服務(wù)端發(fā)出請求數(shù)據(jù)，服務(wù)端頻繁的去數(shù)據(jù)庫查詢用戶名和密碼并進(jìn)行對比，判斷用戶名和密碼正確與否。而Session的存儲(chǔ)是需要空間的，頻繁的查詢數(shù)據(jù)庫給服務(wù)器造成很大的壓力。
在這種情況下，Token應(yīng)用而生。
Token是服務(wù)端生成的一串字符串，以作客戶端進(jìn)行請求的一個(gè)令牌。當(dāng)客戶端第一次訪問服務(wù)端，服務(wù)端會(huì)根據(jù)傳過來的唯一標(biāo)識userId，運(yùn)用一些算法，并加上密鑰，生成一個(gè)Token，然后通過BASE64編碼一下之后將這個(gè)Token返回給客戶端，客戶端將Token保存起來（可以通過數(shù)據(jù)庫或文件形式保存本地）。下次請求時(shí)，客戶端只需要帶上Token，服務(wù)器收到請求后，會(huì)用相同的算法和密鑰去驗(yàn)證Token。
最簡單的Token組成:uid(用戶唯一的身份標(biāo)識)、time(當(dāng)前時(shí)間的時(shí)間戳)、sign(簽名，由Token的前幾位+鹽以哈希算法壓縮成一定長的十六進(jìn)制字符串，可以防止惡意第三方拼接Token請求服務(wù)器)。
使用基于 Token 的身份驗(yàn)證方法，在服務(wù)端不需要存儲(chǔ)用戶的登錄記錄。大概的流程是這樣的：
客戶端使用用戶名跟密碼請求登錄
服務(wù)端收到請求，去驗(yàn)證用戶名與密碼
驗(yàn)證成功后，服務(wù)端會(huì)簽發(fā)一個(gè) Token，再把這個(gè) Token 發(fā)送給客戶端
客戶端收到 Token 以后可以把它存儲(chǔ)起來，比如放在 Cookie 里或者數(shù)據(jù)庫里
客戶端每次向服務(wù)端請求資源的時(shí)候需要帶著服務(wù)端簽發(fā)的 Token
服務(wù)端收到請求，然后去驗(yàn)證客戶端請求里面帶著的 Token，如果驗(yàn)證成功，就向客戶端返回請求的數(shù)據(jù)
APP登錄的時(shí)候發(fā)送加密的用戶名和密碼到服務(wù)器，服務(wù)器驗(yàn)證用戶名和密碼，如果成功，以某種方式比如隨機(jī)生成32位的字符串作為Token，存儲(chǔ)到服務(wù)器中，并返回Token到APP，以后APP請求時(shí)，凡是需要驗(yàn)證的地方都要帶上該Token，然后服務(wù)器端驗(yàn)證Token，成功返回所需要的結(jié)果，失敗返回錯(cuò)誤信息，讓他重新登錄。對于同一個(gè)APP同一個(gè)手機(jī)當(dāng)前只有一個(gè)Token；手機(jī)APP會(huì)存儲(chǔ)一個(gè)當(dāng)前有效的Token。其中服務(wù)器上Token設(shè)置一個(gè)有效期，每次APP請求的時(shí)候都驗(yàn)證Token和有效期。
下面這個(gè)例子，可以很好的理解：
『給我來份煎餅（token我是你對面攤賣烤冷面的，scope賒賬）』『好』
『雞蛋（token我是你對面攤賣烤冷面的，scope賒賬）』『好』
『再加個(gè)雞蛋（token我是你對面攤賣烤冷面的，scope賒賬）』『好』
最終得到一份普通煎餅，外加兩個(gè)雞蛋……
如果服務(wù)器重啟或者因?yàn)槠渌碛桑?wù)器端已保存token丟失。那么用戶需 要重新登錄和認(rèn)證。
『給我來份煎餅（token我是你對面攤賣烤冷面的）』『那個(gè)……我沒見過你』
END
如果你喜歡我的分享，那就在右下角點(diǎn)個(gè)喜歡吧
你的鼓勵(lì)是我最大的動(dòng)力來源，在此深表感恩
軟件測試的路上，我們可以互相關(guān)注，相互學(xué)習(xí)，共同進(jìn)步，微信ID:929194573
