這里是修真院前端小課堂，本篇分析的主題是

【什么是session？什么是cookie？session和cookie有什么區(qū)別？】

每篇分享文從

【背景介紹】【知識(shí)剖析】【常見(jiàn)問(wèn)題】【解決方案】【編碼實(shí)戰(zhàn)】【擴(kuò)展思考】【更多討論】【參考文獻(xiàn)】

八個(gè)方面深度解析前端知識(shí)/技能，本篇分享的是：

【什么是session？什么是cookie？session和cookie有什么區(qū)別？】

什么是SESSION？什么是COOKIE？SESSION和COOKIE有什么區(qū)別？ 什么場(chǎng)景適用于SESSION？什么場(chǎng)景適用于COOKIE？

1.背景介紹

通過(guò)例子簡(jiǎn)單引入

星巴克開(kāi)始優(yōu)惠活動(dòng)，每消費(fèi)10杯咖啡，會(huì)免費(fèi)贈(zèng)送1杯?？紤]到一個(gè)人一次性消費(fèi)10杯咖啡幾乎不可能，所以需要采取某種方式來(lái)記錄顧客的消費(fèi)數(shù)量。

解決方案

1)店員很厲害，每個(gè)顧客的消費(fèi)記錄都記得一清二楚；

2)分給顧客一張卡片，每消費(fèi)一次記錄一次；

3)發(fā)給顧客一張卡片，上面有卡號(hào)，顧客每消費(fèi)一次，由店員在操作機(jī)上記錄一次。

分析：方案一的可執(zhí)行性幾乎為0。方案二和方案三我們都見(jiàn)過(guò)。 而方案二和三正是對(duì)應(yīng)的客戶(hù)端記錄和服務(wù)端記錄。與之相對(duì)應(yīng)的正是cookie和session。 好了，我們進(jìn)入正題。

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

Cookie實(shí)際上是一小段的文本信息?？蛻?hù)端請(qǐng)求服務(wù)器，如果服務(wù)器需要記錄該用戶(hù)狀態(tài)，就使用response向客戶(hù)端瀏覽器頒發(fā)一個(gè)Cookie

客戶(hù)端瀏覽器會(huì)把Cookie保存起來(lái)。當(dāng)瀏覽器再請(qǐng)求該網(wǎng)站時(shí)，瀏覽器把請(qǐng)求的網(wǎng)址連同該Cookie一同提交給服務(wù)器。服務(wù)器檢查該Cookie，

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

實(shí)際就是頒發(fā)一個(gè)通行證，每人一個(gè)，無(wú)論誰(shuí)訪(fǎng)問(wèn)都必須攜帶自己通行證。這樣服務(wù)器就能從通行證上確認(rèn)客戶(hù)身份了。這就是Cookie的工作原理

cookie 可以讓服務(wù)端程序跟蹤每個(gè)客戶(hù)端的訪(fǎng)問(wèn)，但是每次客戶(hù)端的訪(fǎng)問(wèn)都必須傳回這些Cookie，如果 Cookie 很多，這無(wú)形地增加了客戶(hù)端與服務(wù)端的數(shù)據(jù)傳輸量，

而 Session 的出現(xiàn)正是為了解決這個(gè)問(wèn)題。同一個(gè)客戶(hù)端每次和服務(wù)端交互時(shí)，不需要每次都傳回所有的 Cookie 值，而是只要傳回一個(gè) ID，這個(gè) ID 是客戶(hù)端第一次訪(fǎng)問(wèn)服務(wù)器的時(shí)候生成的， 而且每個(gè)客戶(hù)端是唯一的。這樣每個(gè)客戶(hù)端就有了一個(gè)唯一的 ID，客戶(hù)端只要傳回這個(gè) ID 就行了，這個(gè) ID 通常是 NANE 為JSESIONID 的一個(gè) Cookie。

2.知識(shí)剖析

cookie機(jī)制

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

name：cookie的名字，一旦創(chuàng)建，名稱(chēng)不可更改。

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

maxAge：cookie失效時(shí)間，單位秒。如果為正數(shù)，則該cookie在maxAge后失效。如果為負(fù)數(shù)，該cookie為臨時(shí)cookie，關(guān)閉瀏覽器即失效， 瀏覽器也不會(huì)以任何形式保存該cookie。如果為0，表示刪除該cookie。默認(rèn)為-1

path：該cookie的使用路徑。如果設(shè)置為'/sessionWeb/'，則只有ContextPath為“/sessionWeb/”的程序可以訪(fǎng)問(wèn)該cookie。如果設(shè)置為“/”，則本域名下ContextPath都可以訪(fǎng)問(wèn)該cookie。

domain:域.可以訪(fǎng)問(wèn)該Cookie的域名。第一個(gè)字符必須為'.',如果設(shè)置為'.google.com',則所有以'google.com結(jié)尾的域名都可以訪(fǎng)問(wèn)該cookie',如果不設(shè)置,則為所有域名

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

Session機(jī)制

Session機(jī)制是一種服務(wù)端的機(jī)制，服務(wù)器使用一種類(lèi)似散列表的結(jié)構(gòu)來(lái)保存信息。

當(dāng)程序需要為某個(gè)客戶(hù)端的請(qǐng)求創(chuàng)建一個(gè)session的時(shí)候，服務(wù)器首先檢查這個(gè)客戶(hù)端里的請(qǐng)求里是否已包含了一個(gè)session標(biāo)識(shí)--sessionID，

如果已經(jīng)包含一個(gè)sessionID，則說(shuō)明以前已經(jīng)為此客戶(hù)端創(chuàng)建過(guò)session，服務(wù)器就按照sessionID把這個(gè)session檢索出來(lái)使用

如果客戶(hù)端請(qǐng)求不包含sessionID，則為此客戶(hù)端創(chuàng)建一個(gè)session并且聲稱(chēng)一個(gè)與此session相關(guān)聯(lián)的sessionID，

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

3.常見(jiàn)問(wèn)題

使用cookie的弊端

使用session的弊端

cookie和session的區(qū)別

4.解決方案

使用cookie的缺點(diǎn)

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

cookie可以被用戶(hù)禁止

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

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

cookie只能保存字符串

對(duì)服務(wù)器壓力小

使用session的缺點(diǎn)

一般是寄生在Cookie下的，當(dāng)Cookie被禁止，Session也被禁止

當(dāng)然可以通過(guò)url重寫(xiě)來(lái)擺脫cookie

當(dāng)用戶(hù)訪(fǎng)問(wèn)量很大時(shí)，對(duì)服務(wù)器壓力大

我們現(xiàn)在知道session是將用戶(hù)信息儲(chǔ)存在服務(wù)器上面,如果訪(fǎng)問(wèn)服務(wù)器的用戶(hù)越來(lái)越多,那么服務(wù)器上面的session也越來(lái)越多, session會(huì)對(duì)服務(wù)器造成壓力，影響服務(wù)器的負(fù)載.如果Session內(nèi)容過(guò)于復(fù)雜，當(dāng)大量客戶(hù)訪(fǎng)問(wèn)服務(wù)器時(shí)還可能會(huì)導(dǎo)致內(nèi)存溢出。

用戶(hù)信息丟失, 或者說(shuō)用戶(hù)訪(fǎng)問(wèn)的不是這臺(tái)服務(wù)器的情況下,就會(huì)出現(xiàn)數(shù)據(jù)庫(kù)丟失.

cookie和session的區(qū)別

具體來(lái)說(shuō)cookie機(jī)制采用的是在客戶(hù)端保持狀態(tài)的方案，而session機(jī)制采用的是在服務(wù)器端保持狀態(tài)的方案。同時(shí)我們也看到， 由于采用服務(wù)器端保持狀態(tài)的方案在客戶(hù)端也需要保存一個(gè)標(biāo)識(shí)，所以session機(jī)制可能需要借助于cookie機(jī)制來(lái)達(dá)到保存標(biāo)識(shí)的目的

cookie不是很安全，別人可以分析存放在本地的cookie并進(jìn)行cookie欺騙，考慮到安全應(yīng)當(dāng)使用session

session會(huì)在一定時(shí)間內(nèi)保存在服務(wù)器上。當(dāng)訪(fǎng)問(wèn)增多，會(huì)比較占用你服務(wù)器的性能，考慮到減輕服務(wù)器性能方面，應(yīng)當(dāng)使用cookie

單個(gè)cookie保存的數(shù)據(jù)不能超過(guò)4k,很多瀏覽器都限制一個(gè)站點(diǎn)最多保存20個(gè)cookie。

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

5.擴(kuò)展思考

一般的驗(yàn)證方式

1.生成3個(gè)COOKIE,分別使用用戶(hù)名，登錄時(shí)間，用戶(hù)名+登錄時(shí)間DES加密后的密文

2.使用COOKIE與SESSION進(jìn)行比對(duì)驗(yàn)證

3.使用JWT生成TOKEN,解密出被加密的部分進(jìn)行驗(yàn)證。

JSON Web Token（JWT）是一個(gè)開(kāi)放的標(biāo)準(zhǔn)（RFC7519），它定義了一個(gè)緊湊且自包含的方式，用于在各方之間以JSON對(duì)象安全地傳輸信息。

一個(gè)JWT實(shí)際上就是一個(gè)字符串，它由三部分組成，頭部、載荷與簽名。

JWT的頭部用于描述關(guān)于該JWT的最基本的信息，例如其類(lèi)型以及簽名所用的算法等。這也可以被表示成一個(gè)JSON對(duì)象。

'typ':'JWT',

'alg':'HS256'

當(dāng)然頭部要進(jìn)行BASE64編碼

簽名（Signature）

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

我們將上面拼接完的字符串用HS256算法進(jìn)行加密。在加密的時(shí)候，還需要我們自己提供一個(gè)密鑰（secret)。 得到789.

將他們完全拼在一起,我們就得到了完整的JWT'123.456.789' 在我們的請(qǐng)求URL中會(huì)帶上這串JWT字符串

載荷

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

sub: 該JWT所面向的用戶(hù)，是否使用是可選的；

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

exp(expires): 什么時(shí)候過(guò)期，這里是一個(gè)Unix時(shí)間戳，是否使用是可選的；

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

nbf (Not Before)：如果當(dāng)前時(shí)間在nbf里的時(shí)間之前，則Token不被接受；一般都會(huì)留一些余地，比如幾分鐘；，是否使用是可選的；

JWT的Token認(rèn)證

對(duì)Token認(rèn)證的五點(diǎn)認(rèn)識(shí)

對(duì)Token認(rèn)證機(jī)制有5點(diǎn)直接注意的地方：

一個(gè)Token就是一些信息的集合；

在Token中包含足夠多的信息，以便在后續(xù)請(qǐng)求中減少查詢(xún)數(shù)據(jù)庫(kù)的幾率；

服務(wù)端需要對(duì)cookie和HTTP Authrorization Header進(jìn)行Token信息的檢查；

基于上一點(diǎn)，你可以用一套token認(rèn)證代碼來(lái)面對(duì)瀏覽器類(lèi)客戶(hù)端和非瀏覽器類(lèi)客戶(hù)端；

因?yàn)閠oken是被簽名的，所以我們可以認(rèn)為一個(gè)可以解碼認(rèn)證通過(guò)的token是由我們系統(tǒng)發(fā)放的，其中帶的信息是合法有效的；

Token機(jī)制相對(duì)于Cookie機(jī)制又有什么好處呢？

支持跨域訪(fǎng)問(wèn):Cookie是不允許垮域訪(fǎng)問(wèn),這一點(diǎn)對(duì)Token機(jī)制是不存在的,前提是傳輸?shù)挠脩?hù)認(rèn)證信息通過(guò)HTTP頭傳輸.

無(wú)狀態(tài)(也稱(chēng)：服務(wù)端可擴(kuò)展行):Token機(jī)制在服務(wù)端不需要存儲(chǔ)session信息，因?yàn)門(mén)oken 自身包含了所有登錄用戶(hù)的信息，只需要在客戶(hù)端的cookie或本地介質(zhì)存儲(chǔ)狀態(tài)信息.

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

去耦: 不需要綁定到一個(gè)特定的身份驗(yàn)證方案。Token可以在任何地方生成，只要在你的API被調(diào)用的時(shí)候，你可以進(jìn)行Token生成調(diào)用即可.

更適用于移動(dòng)應(yīng)用: 當(dāng)你的客戶(hù)端是一個(gè)原生平臺(tái)（iOS, Android，Windows 8等）時(shí)，Cookie是不被支持的（你需要通過(guò)Cookie容器進(jìn)行處理），這時(shí)采用Token認(rèn)證機(jī)制就會(huì)簡(jiǎn)單得多。

CSRF:因?yàn)椴辉僖蕾?lài)于Cookie，所以你就不需要考慮對(duì)CSRF（跨站請(qǐng)求偽造）的防范。

性能: 一次網(wǎng)絡(luò)往返時(shí)間（通過(guò)數(shù)據(jù)庫(kù)查詢(xún)session信息）總比做一次HMACSHA256計(jì)算 的Token驗(yàn)證和解析要費(fèi)時(shí)得多.

不需要為登錄頁(yè)面做特殊處理:如果你使用Protractor 做功能測(cè)試的時(shí)候，不再需要為登錄頁(yè)面做特殊處理.

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

6.參考文獻(xiàn)

百度

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

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

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

Cookie實(shí)際上是一小段的文本信息?？蛻?hù)端請(qǐng)求服務(wù)器，如果服務(wù)器需要記錄該用戶(hù)狀態(tài)，就使用response向客戶(hù)端瀏覽器頒發(fā)一個(gè)Cookie

客戶(hù)端瀏覽器會(huì)把Cookie保存起來(lái)。當(dāng)瀏覽器再請(qǐng)求該網(wǎng)站時(shí)，瀏覽器把請(qǐng)求的網(wǎng)址連同該Cookie一同提交給服務(wù)器。服務(wù)器檢查該Cookie，

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

實(shí)際就是頒發(fā)一個(gè)通行證，每人一個(gè)，無(wú)論誰(shuí)訪(fǎng)問(wèn)都必須攜帶自己通行證。這樣服務(wù)器就能從通行證上確認(rèn)客戶(hù)身份了。這就是Cookie的工作原理

cookie可以讓服務(wù)端程序跟蹤每個(gè)客戶(hù)端的訪(fǎng)問(wèn)，但是每次客戶(hù)端的訪(fǎng)問(wèn)都必須傳回這些 Cookie，如果 Cookie 很多，這無(wú)形地增加了客戶(hù)端與服務(wù)端的數(shù)據(jù)傳輸量，

而 Session 的出現(xiàn)正是為了解決這個(gè)問(wèn)題。同一個(gè)客戶(hù)端每次和服務(wù)端交互時(shí)，不需要每次都傳回所有的 Cookie 值，而是只要傳回一個(gè) ID，這個(gè) ID 是客戶(hù)端第一次訪(fǎng)問(wèn)服務(wù)器的時(shí)候生成的， 而且每個(gè)客戶(hù)端是唯一的。這樣每個(gè)客戶(hù)端就有了一個(gè)唯一的 ID，客戶(hù)端只要傳回這個(gè) ID 就行了，這個(gè) ID 通常是 NANE 為JSESIONID 的一個(gè) Cookie。