session 、cookie、token的區別及聯繫

session

session的中文翻譯是「會話」，當用戶打開某個web應用時，便與web服務器產生一次session。服務器使用session把用戶的信息臨時保存在了服務器上，用戶離開網站後session會被銷燬。這種用戶信息存儲方式相對cookie來講更安全，但是session有一個缺陷：若是web服務器作了負載均衡，那麼下一個操做請求到了另外一臺服務器的時候session會丟失。

cookie

cookie是保存在本地終端的數據。cookie由服務器生成，發送給瀏覽器，瀏覽器把cookie以kv形式保存到某個目錄下的文本文件內，下一次請求同一網站時會把該cookie發送給服務器。因爲cookie是存在客戶端上的，因此瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會佔據太多磁盤空間，因此每一個域的cookie數量是有限的。

cookie的組成有：名稱(key)、值(value)、有效域(domain)、路徑(域的路徑，通常設置爲全局:"")、失效時間、安全標誌(指定後，cookie只有在使用SSL鏈接時才發送到服務器(https))。下面是一個簡單的js使用cookie的例子:

用戶登陸時產生cookie:

document.cookie = "id="+result.data['id']+"; path=/";

document.cookie = "name="+result.data['name']+"; path=/";

document.cookie = "avatar="+result.data['avatar']+"; path=/";

使用到cookie時作以下解析：

var cookie = document.cookie;var cookieArr = cookie.split(";");var user_info = {};for(var i = 0; i < cookieArr.length; i++) {

    user_info[cookieArr[i].split("=")[0]] = cookieArr[i].split("=")[1];

}

$('#user_name').text(user_info[' name']);

$('#user_avatar').attr("src", user_info[' avatar']);

$('#user_id').val(user_info[' id']);

token

token的意思是「令牌」，是用戶身份的驗證方式，最簡單的token組成:uid(用戶惟一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽以哈希算法壓縮成必定長的十六進制字符串，能夠防止惡意第三方拼接token請求服務器)。還能夠把不變的參數也放進token，避免屢次查庫

cookie 和session的區別

1. cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。
2. cookie不是很安全，別人能夠分析存放在本地的COOKIE並進行COOKIE欺騙
   考慮到安全應當使用session。
3. session會在必定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能
   考慮到減輕服務器性能方面，應當使用COOKIE。
4. 單個cookie保存的數據不能超過4K，不少瀏覽器都限制一個站點最多保存20個cookie。
5. 因此我的建議：
   將登錄信息等重要信息存放爲SESSION
   其餘信息若是須要保留，能夠放在COOKIE中

token 和session 的區別

session 和 oauth token並不矛盾，做爲身份認證 token安全性比session好，由於每一個請求都有簽名還能防止監聽以及重放攻擊，而session就必須靠鏈路層來保障通信安全了。如上所說，若是你須要實現有狀態的會話，仍然能夠增長session來在服務器端保存一些狀態;

App一般用restful api跟server打交道。Rest是stateless的，也就是app不須要像browser那樣用cookie來保存session,所以用session token來標示本身就夠了，session/state由api server的邏輯處理。 若是你的後端不是stateless的rest api, 那麼你可能須要在app裏保存session.能夠在app裏嵌入webkit,用一個隱藏的browser來管理cookie session.

Session 是一種HTTP存儲機制，目的是爲無狀態的HTTP提供的持久機制。所謂Session 認證只是簡單的把User 信息存儲到Session 裏，由於SID 的不可預測性，暫且認爲是安全的。這是一種認證手段。 而Token ，若是指的是OAuth Token 或相似的機制的話，提供的是 認證 和 受權 ，認證是針對用戶，受權是針對App 。其目的是讓 某App有權利訪問 某用戶 的信息。這裏的 Token是惟一的。不能夠轉移到其它 App上，也不能夠轉到其它 用戶 上。 轉過來講Session 。Session只提供一種簡單的認證，即有此 SID，即認爲有此 User的所有權利。是須要嚴格保密的，這個數據應該只保存在站方，不該該共享給其它網站或者第三方App。 因此簡單來講，若是你的用戶數據可能須要和第三方共享，或者容許第三方調用 API 接口，用 Token 。若是永遠只是本身的網站，本身的 App，用什麼就無所謂了。

token就是令牌，好比你受權（登陸）一個程序時，他就是個依據，判斷你是否已經受權該軟件；cookie就是寫在客戶端的一個txt文件，裏面包括你登陸信息之類的，這樣你下次在登陸某個網站，就會自動調用cookie自動登陸用戶名；session和cookie差很少，只是session是寫在服務器端的文件，也須要在客戶端寫入cookie文件，可是文件裏是你的瀏覽器編號.Session的狀態是存儲在服務器端，客戶端只有session id；而Token的狀態是存儲在客戶端。

cookie機制

Cookies是服務器在本地機器上存儲的小段文本並隨每個請求發送至同一個服務器。IETF RFC 2965 HTTP State Management Mechanism 是通用cookie規範。網絡服務器用HTTP頭向客戶端發送cookies，在客戶終端，瀏覽器解析這些cookies並將它們保存爲一個本地文件，它會自動將同一服務器的任何請求縛上這些cookies 。

具體來講cookie機制採用的是在客戶端保持狀態的方案。它是在用戶端的會話狀態的存貯機制，他須要用戶打開客戶端的cookie支持。cookie的做用就是爲了解決HTTP協議無狀態的缺陷所做的努力。
正統的cookie分發是經過擴展HTTP協議來實現的，服務器經過在HTTP的響應頭中加上一行特殊的指示以提示瀏覽器按照指示生成相應的cookie。然而純粹的客戶端腳本如JavaScript也能夠生成cookie。而cookie的使用是由瀏覽器按照必定的原則在後臺自動發送給服務器的。瀏覽器檢查全部存儲的cookie，若是某個cookie所聲明的做用範圍大於等於將要請求的資源所在的位置，則把該cookie附在請求資源的HTTP請求頭上發送給服務器。

cookie的內容主要包括：名字，值，過時時間，路徑和域。路徑與域一塊兒構成cookie的做用範圍。若不設置過時時間，則表示這個cookie的生命期爲瀏覽器會話期間，關閉瀏覽器窗口，cookie就消失。這種生命期爲瀏覽器會話期的cookie被稱爲會話cookie。會話cookie通常不存儲在硬盤上而是保存在內存裏，固然這種行爲並非規範規定的。若設置了過時時間，瀏覽器就會把cookie保存到硬盤上，關閉後再次打開瀏覽器，這些cookie仍然有效直到超過設定的過時時間。存儲在硬盤上的cookie能夠在不一樣的瀏覽器進程間共享，好比兩個IE窗口。而對於保存在內存裏的cookie，不一樣的瀏覽器有不一樣的處理方式。

而session機制採用的是一種在服務器端保持狀態的解決方案。同時咱們也看到，因爲採用服務器端保持狀態的方案在客戶端也須要保存一個標識，因此session機制可能須要藉助於cookie機制來達到保存標識的目的。而session提供了方便管理全局變量的方式 。

session是針對每個用戶的，變量的值保存在服務器上，用一個sessionID來區分是哪一個用戶session變量,這個值是經過用戶的瀏覽器在訪問的時候返回給服務器，當客戶禁用cookie時，這個值也可能設置爲由get來返回給服務器。

就安全性來講：當你訪問一個使用session 的站點，同時在本身機子上創建一個cookie，建議在服務器端的session機制更安全些，由於它不會任意讀取客戶存儲的信息。

session機制

session機制是一種服務器端的機制，服務器使用一種相似於散列表的結構（也可能就是使用散列表）來保存信息。

當程序須要爲某個客戶端的請求建立一個session時，服務器首先檢查這個客戶端的請求裏是否已包含了一個session標識（稱爲session id），若是已包含則說明之前已經爲此客戶端建立過session，服務器就按照session id把這個session檢索出來使用（檢索不到，會新建一個），若是客戶端請求不包含session id，則爲此客戶端建立一個session而且生成一個與此session相關聯的session id，session id的值應該是一個既不會重複，又不容易被找到規律以仿造的字符串，這個session id將被在本次響應中返回給客戶端保存。

保存這個session id的方式能夠採用cookie，這樣在交互過程當中瀏覽器能夠自動的按照規則把這個標識發揮給服務器。通常這個cookie的名字都是相似於SEEESIONID。但cookie能夠被人爲的禁止，則必須有其餘機制以便在cookie被禁止時仍然可以把session id傳遞迴服務器。
常常被使用的一種技術叫作URL重寫，就是把session id直接附加在URL路徑的後面。還有一種技術叫作表單隱藏字段。就是服務器會自動修改表單，添加一個隱藏字段，以便在表單提交時可以把session id傳遞迴服務器。

Cookie與Session都可以進行會話跟蹤，可是完成的原理不太同樣。普通情況下兩者均可以知足需求，但有時分不可以運用Cookie，有時分不可以運用Session。下面通過比擬闡明兩者的特性以及適用的場所。

1 .存取方式的不一樣

Cookie中只能保管ASCII字符串，假如需求存取Unicode字符或者二進制數據，需求先進行編碼。Cookie中也不能直接存取Java對象。若要存儲略微複雜的信息，運用Cookie是比擬艱難的。
而Session中可以存取任何類型的數據，包括而不限於String、Integer、List、Map等。Session中也可以直接保管Java Bean乃至任何Java類，對象等，運用起來十分便當。可以把Session看作是一個Java容器類。

2 .隱私策略的不一樣

Cookie存儲在客戶端閱讀器中，對客戶端是可見的，客戶端的一些程序可能會窺探、複製以致修正Cookie中的內容。而Session存儲在服務器上，對客戶端是透明的，不存在敏感信息泄露的風險。
假如選用Cookie，比較好的方法是，敏感的信息如帳號密碼等儘可能不要寫到Cookie中。最好是像Google、Baidu那樣將Cookie信息加密，提交到服務器後再進行解密，保證Cookie中的信息只要本人能讀得懂。而假如選擇Session就省事多了，反正是放在服務器上，Session裏任何隱私都可以有效的保護。
3.有效期上的不一樣

使用過Google的人都曉得，假如登陸過Google，則Google的登陸信息長期有效。用戶不用每次訪問都從新登陸，Google會持久地記載該用戶的登陸信息。要到達這種效果，運用Cookie會是比較好的選擇。只須要設置Cookie的過時時間屬性爲一個很大很大的數字。

因爲Session依賴於名爲JSESSIONID的Cookie，而Cookie JSESSIONID的過時時間默許爲–1，只需關閉了閱讀器該Session就會失效，於是Session不能完成信息永世有效的效果。運用URL地址重寫也不能完成。並且假如設置Session的超時時間過長，服務器累計的Session就會越多，越容易招致內存溢出。

4.服務器壓力的不一樣

Session是保管在服務器端的，每一個用戶都會產生一個Session。假如併發訪問的用戶十分多，會產生十分多的Session，耗費大量的內存。於是像Google、Baidu、Sina這樣併發訪問量極高的網站，是不太可能運用Session來追蹤客戶會話的。

而Cookie保管在客戶端，不佔用服務器資源。假如併發閱讀的用戶十分多，Cookie是很好的選擇。關於Google、Baidu、Sina來講，Cookie或許是惟一的選擇。

5 .瀏覽器支持的不一樣

Cookie是須要客戶端瀏覽器支持的。假如客戶端禁用了Cookie，或者不支持Cookie，則會話跟蹤會失效。關於WAP上的應用，常規的Cookie就派不上用場了。

假如客戶端瀏覽器不支持Cookie，須要運用Session以及URL地址重寫。須要注意的是一切的用到Session程序的URL都要進行URL地址重寫，不然Session會話跟蹤還會失效。關於WAP應用來講，Session+URL地址重寫或許是它惟一的選擇。

假如客戶端支持Cookie，則Cookie既可以設爲本瀏覽器窗口以及子窗口內有效（把過時時間設爲–1），也可以設爲一切閱讀器窗口內有效（把過時時間設爲某個大於0的整數）。但Session只能在本閱讀器窗口以及其子窗口內有效。假如兩個瀏覽器窗口互不相干，它們將運用兩個不一樣的Session。（IE8下不一樣窗口Session相干）

6.跨域支持上的不一樣

Cookie支持跨域名訪問，例如將domain屬性設置爲「.biaodianfu.com」，則以「.biaodianfu.com」爲後綴的一切域名均可以訪問該Cookie。跨域名Cookie現在被廣泛用在網絡中，例如Google、Baidu、Sina等。而Session則不會支持跨域名訪問。Session僅在他所在的域名內有效。
僅運用Cookie或者僅運用Session可能完成不了理想的效果。這時應該嘗試一下同時運用Cookie與Session。Cookie與Session的搭配運用在實踐項目中會完成不少意想不到的效果。

關係的理解
客戶第一次發送請求給服務器，此時服務器產生一個惟一的sessionID，並返回給客戶端(經過cookie)，保存於客戶端的內存中，並與一個瀏覽器窗口對應着,因爲HTTP協議的特性，這一次鏈接就斷開了之後此客戶端再發送請求給服務器的時候，就會在請求request中攜帶cookie,因爲cookie中有sessionID,因此服務器就知道這是剛纔那個客戶端。舉個簡單例子就像人們去超市購物，去存包，第一個去的時候(客戶第一次發送請求給服務器),超市會給你一個號碼牌(此時服務器產生一個惟一的sessionID，並返回給客戶端(經過cookie)),你能夠在你本身的櫃子裏存東西(在服務器屬於此客戶的內存區域存數據),下次你再去的時候，拿着這個號碼牌(請求request中攜帶cookie),超市就知道哪些東西是你的，而後給你取出來，若是你幾天都沒去取（session失效了，在服務器端配置）,你再去的時候東西就拿不到了若是你把這個號碼牌丟了(剛纔的cookie失效了，好比你重啓電腦，剛纔存於內存中sessionID也就丟了)，再去拿東西，固然沒法定位了，也就拿不到東西了若是是新打開一個瀏覽器的狀況，那就像是又一我的去超市存東西同樣，你的東西跟他的東西是兩碼事，互不影響,他有他本身的sessionID,你有你本身的