1.背景介紹

由於HTTP是一種無狀態協議,伺服器沒有辦法單單從網路連線上面知道訪問者的身份,為了解決這個問題,就誕生了Cookie

Cookie實際上是一小段的文字資訊。客戶端請求伺服器，如果伺服器需要記錄該使用者狀態，就使用response向客戶端瀏覽器頒發一個Cookie

客戶端瀏覽器會把Cookie儲存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給伺服器。伺服器檢查該Cookie，

以此來辨認使用者狀態。伺服器還可以根據需要修改Cookie的內容。

實際就是頒發一個通行證，每人一個，無論誰訪問都必須攜帶自己通行證。這樣伺服器就能從通行證上確認客戶身份了。這就是Cookie的工作原理

cookie 可以讓服務端程式跟蹤每個客戶端的訪問，但是每次客戶端的訪問都必須傳回這些 Cookie，如果 Cookie 很多，這無形地增加了客戶端與服務端的資料傳輸量，

而 Session 的出現正是為了解決這個問題。同一個客戶端每次和服務端互動時，不需要每次都傳回所有的 Cookie 值，而是隻要傳回一個 ID，這個 ID 是客戶端第一次訪問伺服器的時候生成的，

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

Session翻譯過來為會話的意思,,這裡的session指的是客戶端與伺服器之間儲存狀態的解決方案.

2.知識剖析

cookie機制

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

name：cookie的名字，一旦建立，名稱不可更改。

value：cookie的值，如果值為Unicode字元，需要為字元編碼。如果為二進位制資料，則需要使用BASE64編碼.

maxAge：cookie失效時間，單位秒。如果為正數，則該cookie在maxAge後失效。如果為負數，該cookie為臨時cookie，關閉瀏覽器即失效，

瀏覽器也不會以任何形式儲存該cookie。如果為0，表示刪除該cookie。預設為-1

path：該cookie的使用路徑。如果設定為"/sessionWeb/"，則只有ContextPath為“/sessionWeb/”的程式可以訪問該cookie。如果設定為“/”，則本域名下ContextPath都可以訪問該cookie。

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

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

Session機制

Session機制是一種服務端的機制，伺服器使用一種類似散列表的結構來儲存資訊。

當程式需要為某個客戶端的請求建立一個session的時候，伺服器首先檢查這個客戶端裡的請求裡是否已包含了一個session標識--sessionID，

如果已經包含一個sessionID，則說明以前已經為此客戶端建立過session，伺服器就按照sessionID把這個session檢索出來使用

如果客戶端請求不包含sessionID，則為此客戶端建立一個session並且聲稱一個與此session相關聯的sessionID，

sessionID的值應該是一個既不會重複，又不容易被找到規律以仿造的字串(伺服器會自動建立),這個sessionID將被在本次響應中返回給客戶端儲存。

3.常見問題

使用cookie的弊端

使用session的弊端

cookie和session的區別

4.解決方案

使用cookie的缺點

如果瀏覽器使用的是 cookie，那麼所有的資料都儲存在瀏覽器端，

cookie可以被使用者禁止

cookie不安全(對於敏感資料，需要加密)

cookie只能儲存少量的資料(大約是4k)，cookie的數量也有限制(大約是幾百個)，不同瀏覽器設定不一樣，反正都不多

cookie只能儲存字串

對伺服器壓力小

使用session的缺點

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

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

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

我們現在知道session是將使用者資訊儲存在伺服器上面,如果訪問伺服器的使用者越來越多,那麼伺服器上面的session也越來越多, session會對伺服器造成壓力，影響伺服器的負載.如果Session內容過於複雜，當大量客戶訪問伺服器時還可能會導致記憶體溢位。

使用者資訊丟失,  或者說使用者訪問的不是這臺伺服器的情況下,就會出現資料庫丟失.

cookie和session的區別

具體來說cookie機制採用的是在客戶端保持狀態的方案，而session機制採用的是在伺服器端保持狀態的方案。同時我們也看到，

由於採用伺服器端保持狀態的方案在客戶端也需要儲存一個標識，所以session機制可能需要藉助於cookie機制來達到儲存標識的目的

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

session會在一定時間內儲存在伺服器上。當訪問增多，會比較佔用你伺服器的效能，考慮到減輕伺服器效能方面，應當使用cookie

單個cookie儲存的資料不能超過4k,很多瀏覽器都限制一個站點最多儲存20個cookie。

可以將登陸資訊等重要資訊存放為session。

5.編碼實戰

6.擴充套件思考

其他幾種認證登入方式

HTTP Basic Auth

HTTP Basic Auth簡單點說明就是每次請求API時都提供使用者的username和password，簡言之，Basic Auth是配合RESTful API 使用的最簡單的認證方式，只需提供使用者名稱密碼即可，但由於有把使用者名稱密碼暴露給第三方客戶端的風險，在生產環境下被使用的越來越少。因此，在開發對外開放的RESTful API時，儘量避免採用HTTP Basic Auth

OAuth

OAuth（開放授權）是一個開放的授權標準，允許使用者讓第三方應用訪問該使用者在某一web服務上儲存的私密的資源（如照片，視訊，聯絡人列表），而無需將使用者名稱和密碼提供給第三方應用。

OAuth允許使用者提供一個令牌，而不是使用者名稱和密碼來訪問他們存放在特定服務提供者的資料。每一個令牌授權一個特定的第三方系統（例如，視訊編輯網站)在特定的時段（例如，接下來的2小時內）內訪問特定的資源（例如僅僅是某一相簿中的視訊）。

這樣，OAuth讓使用者可以授權第三方網站訪問他們儲存在另外服務提供者的某些特定資訊，而非所有內容

OAuth的認證機制適用於個人消費者類的網際網路產品，如社交類APP等應用，但是不太適合擁有自有認證許可權管理的企業應用；

JWT的Token認證

一個JWT實際上就是一個字串，它由三部分組成，頭部、載荷與簽名。

JWT的頭部用於描述關於該JWT的最基本的資訊，例如其型別以及簽名所用的演算法等。這也可以被表示成一個JSON物件。

"typ": "JWT",

"alg": "HS256"

當然頭部要進行BASE64編碼

簽名（Signature）

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

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

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

載荷

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

sub: 該JWT所面向的使用者，是否使用是可選的；

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

exp(expires): 什麼時候過期，這裡是一個Unix時間戳，是否使用是可選的；

iat(issued at): 在什麼時候簽發的(UNIX時間)，是否使用是可選的；

nbf (Not Before)：如果當前時間在nbf裡的時間之前，則Token不被接受；一般都會留一些餘地，比如幾分鐘；，是否使用是可選的；

JWT機制實現認證

ection>

對Token認證的五點認識

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

一個Token就是一些資訊的集合；

在Token中包含足夠多的資訊，以便在後續請求中減少查詢資料庫的機率；

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

基於上一點，你可以用一套token認證程式碼來面對瀏覽器類客戶端和非瀏覽器類客戶端；

因為token是被簽名的，所以我們可以認為一個可以解碼認證通過的token是由我們系統發放的，其中帶的資訊是合法有效的；

Token機制相對於Cookie機制又有什麼好處呢？

支援跨域訪問:Cookie是不允許垮域訪問,這一點對Token機制是不存在的,前提是傳輸的使用者認證資訊通過HTTP頭傳輸.

無狀態(也稱：服務端可擴充套件行):Token機制在服務端不需要儲存session資訊，因為Token 自身包含了所有登入使用者的資訊，只需要在客戶端的cookie或本地介質儲存狀態資訊.

更適用CDN: 可以通過內容分發網路請求你服務端的所有資料（如：javascript，HTML,圖片等），而你的服務端只要提供API即可.

去耦: 不需要繫結到一個特定的身份驗證方案。Token可以在任何地方生成，只要在你的API被呼叫的時候，你可以進行Token生成呼叫即可.

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

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

效能: 一次網路往返時間（通過資料庫查詢session資訊）總比做一次HMACSHA256計算 的Token驗證和解析要費時得多.

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

基於標準化:你的API可以採用標準化的 JSON Web Token (JWT). 這個標準已經存在多個後端庫（.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

今天的分享就到這裡啦，歡迎大家點贊、轉發、留言、拍磚~

技能樹.IT修真院

“我們相信人人都可以成為一個工程師，現在開始，找個師兄，帶你入門，掌控自己學習的節奏，學習的路上不再迷茫”。

這裡是技能樹.IT修真院，成千上萬的師兄在這裡找到了自己的學習路線，學習透明化，成長可見化，師兄1對1免費指導。快來與我一起學習吧~

PPT

Cookie和 session,Token機制詳解及區別_騰訊視訊