什么是session？什么是cookie佳头？session和cookie有什么區(qū)別鹰贵？什么場景適用于session？什么場景適用于cookie康嘉？

1.背景介紹

過例子簡單引入

星巴克開始優(yōu)惠活動碉输，每消費10杯咖啡，會免費贈送1杯亭珍》蠹兀考慮到一個人一次性消費10杯咖啡幾乎不可能菌赖，所以需要采取某種方式來記錄顧客的消費數(shù)量铅鲤。

解決方案

1，店員很厲害漩怎，每個顧客的消費記錄都記得一清二楚众羡；

2侨赡，分給顧客一張卡片，每消費一次記錄一次纱控；

3辆毡，發(fā)給顧客一張卡片，上面有卡號甜害，顧客每消費一次，由店員在操作機上記錄一次球昨。

分析：方案一的可執(zhí)行性幾乎為0尔店。方案二和方案三我們都見過。

? 而方案二和三正是對應的客戶端記錄和服務端記錄主慰。與之相對應的正是cookie和session嚣州。

好了，我們進入正題共螺。

由于HTTP是一種無狀態(tài)協(xié)議,服務器沒有辦法單單從網(wǎng)絡連接上面知道訪問者的身份,為了解決這個問題,就誕生了Cookie

Cookie實際上是一小段的文本信息该肴。客戶端請求服務器藐不，如果服務器需要記錄該用戶狀態(tài)匀哄，就使用response向客戶端瀏覽器頒發(fā)一個Cookie

客戶端瀏覽器會把Cookie保存起來秦效。當瀏覽器再請求該網(wǎng)站時，瀏覽器把請求的網(wǎng)址連同該Cookie一同提交給服務器涎嚼。服務器檢查該Cookie阱州，

以此來辨認用戶狀態(tài)。服務器還可以根據(jù)需要修改Cookie的內(nèi)容法梯。

實際就是頒發(fā)一個通行證苔货，每人一個，無論誰訪問都必須攜帶自己通行證立哑。這樣服務器就能從通行證上確認客戶身份了夜惭。這就是Cookie的工作原理

cookie可以讓服務端程序跟蹤每個客戶端的訪問，但是每次客戶端的訪問都必須傳回這些 Cookie铛绰，如果 Cookie很多滥嘴，這無形地增加了客戶端與服務端的數(shù)據(jù)傳輸量，

而 Session的出現(xiàn)正是為了解決這個問題至耻。同一個客戶端每次和服務端交互時若皱，不需要每次都傳回所有的 Cookie值，而是只要傳回一個 ID尘颓，這個 ID是客戶端第一次訪問服務器的時候生成的走触，

而且每個客戶端是唯一的。這樣每個客戶端就有了一個唯一的 ID疤苹，客戶端只要傳回這個 ID就行了互广，這個 ID通常是 NANE為 JSESIONID的一個 Cookie。

cookie機制

?

cookie的內(nèi)容主要包括name(名字)卧土、value(值)惫皱、maxAge(失效時間)、path(路徑),domain(域)和secure

name：cookie的名字尤莺，一旦創(chuàng)建旅敷，名稱不可更改。

value：cookie的值颤霎，如果值為Unicode字符媳谁，需要為字符編碼。如果為二進制數(shù)據(jù)友酱，則需要使用BASE64編碼.

maxAge：cookie失效時間晴音，單位秒。如果為正數(shù)缔杉，則該cookie在maxAge后失效锤躁。如果為負數(shù)，該cookie為臨時cookie或详，關閉瀏覽器即失效系羞，

瀏覽器也不會以任何形式保存該cookie郭计。如果為0，表示刪除該cookie觉啊。默認為-1

path：該cookie的使用路徑拣宏。如果設置為"/sessionWeb/"，則只有ContextPath為“/sessionWeb/”的程序可以訪問該cookie杠人。如果設置為“/”勋乾，則本域名下ContextPath都可以訪問該cookie。

domain:域.可以訪問該Cookie的域名嗡善。第一個字符必須為".",如果設置為".google.com",則所有以"google.com結尾的域名都可以訪問該cookie",如果不設置,則為所有域名

?

secure：該cookie是否僅被使用安全協(xié)議傳輸辑莫。

Session機制

Session機制是一種服務端的機制，服務器使用一種類似散列表的結構來保存信息罩引。

當程序需要為某個客戶端的請求創(chuàng)建一個session的時候各吨，服務器首先檢查這個客戶端里的請求里是否已包含了一個session標識--sessionID，

如果已經(jīng)包含一個sessionID袁铐，則說明以前已經(jīng)為此客戶端創(chuàng)建過session揭蜒，服務器就按照sessionID把這個session檢索出來使用

如果客戶端請求不包含sessionID，則為此客戶端創(chuàng)建一個session并且聲稱一個與此session相關聯(lián)的sessionID剔桨，

sessionID的值應該是一個既不會重復屉更，又不容易被找到規(guī)律以仿造的字符串(服務器會自動創(chuàng)建),這個sessionID將被在本次響應中返回給客戶端保存。

3.常見問題

使用session的弊端

cookie和session的區(qū)別

4.解決方案

使用cookie的缺點

如果瀏覽器使用的是 cookie洒缀，那么所有的數(shù)據(jù)都保存在瀏覽器端瑰谜，

cookie可以被用戶禁止

cookie不安全(對于敏感數(shù)據(jù)，需要加密)

cookie只能保存少量的數(shù)據(jù)(大約是4k)树绩，cookie的數(shù)量也有限制(大約是幾百個)萨脑，不同瀏覽器設置不一樣，反正都不多

cookie只能保存字符串

對服務器壓力小

使用session的缺點

一般是寄生在Cookie下的饺饭，當Cookie被禁止渤早，Session也被禁止

當然可以通過url重寫來擺脫cookie

當用戶訪問量很大時，對服務器壓力大

我們現(xiàn)在知道session是將用戶信息儲存在服務器上面,如果訪問服務器的用戶越來越多,那么服務器上面的session也越來越多, session會對服務器造成壓力砰奕，影響服務器的負載.如果Session內(nèi)容過于復雜蛛芥，當大量客戶訪問服務器時還可能會導致內(nèi)存溢出。

用戶信息丟失,或者說用戶訪問的不是這臺服務器的情況下,就會出現(xiàn)數(shù)據(jù)庫丟失.

cookie和session的區(qū)別

具體來說cookie機制采用的是在客戶端保持狀態(tài)的方案军援，而session機制采用的是在服務器端保持狀態(tài)的方案。同時我們也看到称勋，

由于采用服務器端保持狀態(tài)的方案在客戶端也需要保存一個標識胸哥，所以session機制可能需要借助于cookie機制來達到保存標識的目的

cookie不是很安全，別人可以分析存放在本地的cookie并進行cookie欺騙赡鲜，考慮到安全應當使用session

? ? session會在一定時間內(nèi)保存在服務器上空厌。當訪問增多庐船，會比較占用你服務器的性能，考慮到減輕服務器性能方面嘲更，應當使用cookie

? ? 單個cookie保存的數(shù)據(jù)不能超過4k,很多瀏覽器都限制一個站點最多保存20個cookie筐钟。

? ? 可以將登陸信息等重要信息存放為session。

5.擴展思考

?

一般的驗證方式

?

1.生成3個cookie,分別使用用戶名赋朦，登錄時間篓冲，用戶名+登錄時間DES加密后的密文

?

2.使用cookie與session進行比對驗證

?

3.使用JWT生成token,解密出被加密的部分進行驗證。

?

?

JSON Web Token（JWT）是一個開放的標準（RFC 7519）宠哄，它定義了一個緊湊且自包含的方式壹将，用于在各方之間以JSON對象安全地傳輸信息。

?

一個JWT實際上就是一個字符串毛嫉，它由三部分組成诽俯，頭部、載荷與簽名承粤。

?

JWT的頭部用于描述關于該JWT的最基本的信息暴区，例如其類型以及簽名所用的算法等。這也可以被表示成一個JSON對象辛臊。

?

"typ": "JWT",

?

"alg": "HS256"

?

當然頭部要進行BASE64編碼

?

?

簽名（Signature）

?

將上面的兩個編碼后的字符串都用句號.連接在一起（頭部在前）例如頭部使用base64編碼后為123.456

?

我們將上面拼接完的字符串用HS256算法進行加密仙粱。在加密的時候，還需要我們自己提供一個密鑰（secret)浪讳。 得到789.

?

將他們完全拼在一起,我們就得到了完整的JWT"123.456.789"在我們的請求URL中會帶上這串JWT字符串

?

?

載荷

iss:該JWT的簽發(fā)者缰盏，? 是否使用是可選的；

sub:該JWT所面向的用戶淹遵，是否使用是可選的口猜；

aud:接收該JWT的一方， 是否使用是可選的透揣；

exp(expires):什么時候過期济炎，這里是一個Unix時間戳，是否使用是可選的辐真；

iat(issued at):在什么時候簽發(fā)的(UNIX時間)须尚，是否使用是可選的；

nbf (Not Before)：如果當前時間在nbf里的時間之前侍咱，則Token不被接受耐床；一般都會留一些余地，比如幾分鐘楔脯；撩轰，是否使用是可選的；

?

JWT的Token認證

?

?

JWT的Token認證

?

?

JWT的Token認證

?

?

JWT的Token認證

?

?

JWT的Token認證

?

?

JWT的Token認證

?

?

JWT的Token認證

?

?

JWT的Token認證

?

? ?

? ?

對Token認證的五點認識

? ?

對Token認證機制有5點直接注意的地方：

? ?

一個Token就是一些信息的集合；

? ?

在Token中包含足夠多的信息堪嫂，以便在后續(xù)請求中減少查詢數(shù)據(jù)庫的幾率偎箫；

? ?

服務端需要對cookie和HTTP Authrorization Header進行Token信息的檢查；

? ?

基于上一點皆串，你可以用一套token認證代碼來面對瀏覽器類客戶端和非瀏覽器類客戶端淹办；

? ?

因為token是被簽名的，所以我們可以認為一個可以解碼認證通過的token是由我們系統(tǒng)發(fā)放的恶复，其中帶的信息是合法有效的怜森；

? ?

?

Token機制相對于Cookie機制又有什么好處呢？

?

支持跨域訪問:Cookie是不允許垮域訪問,這一點對Token機制是不存在的,前提是傳輸?shù)挠脩粽J證信息通過HTTP頭傳輸.

?

無狀態(tài)(也稱：服務端可擴展行):Token機制在服務端不需要存儲session信息寂玲，因為Token自身包含了所有登錄用戶的信息塔插，只需要在客戶端的cookie或本地介質(zhì)存儲狀態(tài)信息.

?

更適用CDN:可以通過內(nèi)容分發(fā)網(wǎng)絡請求你服務端的所有資料（如：javascript，HTML,圖片等）拓哟，而你的服務端只要提供API即可.

?

?

去耦:不需要綁定到一個特定的身份驗證方案想许。Token可以在任何地方生成，只要在你的API被調(diào)用的時候断序，你可以進行Token生成調(diào)用即可.

?

更適用于移動應用:當你的客戶端是一個原生平臺（iOS, Android流纹，Windows 8等）時，Cookie是不被支持的（你需要通過Cookie容器進行處理）违诗，這時采用Token認證機制就會簡單得多漱凝。

?

CSRF:因為不再依賴于Cookie，所以你就不需要考慮對CSRF（跨站請求偽造）的防范诸迟。

?

性能:一次網(wǎng)絡往返時間（通過數(shù)據(jù)庫查詢session信息）總比做一次HMACSHA256計算 的Token驗證和解析要費時得多.

?

?

不需要為登錄頁面做特殊處理:如果你使用Protractor做功能測試的時候茸炒，不再需要為登錄頁面做特殊處理.

?

基于標準化:你的API可以采用標準化的 JSON Web Token (JWT).這個標準已經(jīng)存在多個后端庫（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如：Firebase,Google, Microsoft）.

? ? ?

? ? ? ? ?

7.參考文獻

? ? ? ? ?

百度

?

http://blog.csdn.net/fangaoxin/article/details/6952954/

?

http://www.cnblogs.com/xiekeli/p/5607107.html