本文轉自：https://blog.csdn.net/jikeehuang/article/details/51488020；https://blog.csdn.net/weixin_37196194/article/details/55806366

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與Session做一個介紹和總結，並分別對兩個知識點進行對比分析，讓大家對Cookie和Session有一個更深入的瞭解，並對自己的開發工作中靈活運用帶來啟示。　　

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,你有你自己的

學而時習之不亦說乎！