1. 爲什麼要有session的出現？
答：是由於網絡中http協議造成的，因爲http本身是無狀態協議，
這樣，無法確定你的本次請求和上次請求是不是你發送的。
如果要進行類似論壇登陸相關的操作，就實現不了了。
2. session生成方式？
答：瀏覽器第一次訪問服務器，服務器會創建一個session，然後同時爲該session生成一個唯一的會話的key,也就是sessionid，然後，將sessionid及對應的session分別作爲key和value保存到緩存中，也可以持久化到數據庫中，然後服務器再把sessionid，以cookie的形式發送給客戶端。這樣瀏覽器下次再訪問時，會直接帶着cookie中的sessionid。然後服務器根據sessionid找到對應的session進行匹配；
還有一種是瀏覽器禁用了cookie或不支持cookie，這種可以通過URL重寫的方式發到服務器；
簡單來講，用戶訪問的時候說他自己是張三，他騙你怎麼辦？ 那就在服務器端保存張三的信息，給他一個id，讓他下次用id訪問。
3. 爲什麼會有token的出現？
答：首先，session的存儲是需要空間的，其次，session的傳遞一般都是通過cookie來傳遞的，或者url重寫的方式；
而token在服務器是可以不需要存儲用戶的信息的，而token的傳遞方式也不限於cookie傳遞，當然，token也是可以保存起來的；
4. token的生成方式？
答：瀏覽器第一次訪問服務器，根據傳過來的唯一標識userId，服務端會通過一些算法，如常用的HMAC-SHA256算法，然後加一個密鑰，生成一個token，然後通過BASE64編碼一下之後將這個token發送給客戶端；客戶端將token保存起來，下次請求時，帶着token，服務器收到請求後，然後會用相同的算法和密鑰去驗證token，如果通過，執行業務操作，不通過，返回不通過信息；
5. token和session的區別？
token和session其實都是爲了身份驗證，session一般翻譯爲會話，而token更多的時候是翻譯爲令牌；
session服務器會保存一份，可能保存到緩存，文件，數據庫；同樣，session和token都是有過期時間一說，都需要去管理過期時間；
其實token與session的問題是一種時間與空間的博弈問題，session是空間換時間，而token是時間換空間。兩者的選擇要看具體情況而定。
雖然確實都是“客戶端記錄，每次訪問攜帶”，但 token 很容易設計爲自包含的，也就是說，後端不需要記錄什麼東西，每次一個無狀態請求，每次解密驗證，每次當場得出合法 /非法的結論。這一切判斷依據，除了固化在 CS 兩端的一些邏輯之外，整個信息是自包含的。這纔是真正的無狀態。
而 sessionid ，一般都是一段隨機字符串，需要到後端去檢索 id 的有效性。萬一服務器重啓導致內存裏的 session 沒了呢？萬一 redis 服務器掛了呢？
方案 A ：我發給你一張身份證，但只是一張寫着身份證號碼的紙片。你每次來辦事，我去後臺查一下你的 id 是不是有效。
方案 B ：我發給你一張加密的身份證，以後你只要出示這張卡片，我就知道你一定是自己人。
就這麼個差別。
token的使用可以參考：json web token(JWT);
參考自：https://www.v2ex.com/t/80003
https://www.v2ex.com/t/276207
https://ninghao.net/blog/2834
本文轉載自：https://www.cnblogs.com/xiaozhang2014/p/7750200.html
補充：
什麼是token
token的意思是“令牌”，是服務端生成的一串字符串，作爲客戶端進行請求的一個標識。
當用戶第一次登錄後，服務器生成一個token並將此token返回給客戶端，以後客戶端只需帶上這個token前來請求數據即可，無需再次帶上用戶名和密碼。
簡單token的組成；uid(用戶唯一的身份標識)、time(當前時間的時間戳)、sign（簽名，token的前幾位以哈希算法壓縮成的一定長度的十六進制字符串。爲防止token泄露）。
身份認證概述
由於HTTP是一種沒有狀態的協議，它並不知道是誰訪問了我們的應用。這裏把用戶看成是客戶端，客戶端使用用戶名還有密碼通過了身份驗證，不過下次這個客戶端再發送請求時候，還得再驗證一下。
通用的解決方法就是，當用戶請求登錄的時候，如果沒有問題，在服務端生成一條記錄，在這個記錄裏可以說明登錄的用戶是誰，然後把這條記錄的id發送給客戶端，客戶端收到以後把這個id存儲在cookie裏，下次該用戶再次向服務端發送請求的時候，可以帶上這個cookie，這樣服務端會驗證一下cookie裏的信息，看能不能在服務端這裏找到對應的記錄，如果可以，說明用戶已經通過了身份驗證，就把用戶請求的數據返回給客戶端。
以上所描述的過程就是利用session，那個id值就是sessionid。我們需要在服務端存儲爲用戶生成的session，這些session會存儲在內存，磁盤，或者數據庫。
基於token機制的身份認證
使用token機制的身份驗證方法，在服務器端不需要存儲用戶的登錄記錄。大概的流程：
客戶端使用用戶名和密碼請求登錄。服務端收到請求，驗證用戶名和密碼。驗證成功後，服務端會生成一個token，然後把這個token發送給客戶端。客戶端收到token後把它存儲起來，可以放在cookie或者Local Storage（本地存儲）裏。客戶端每次向服務端發送請求的時候都需要帶上服務端發給的token。服務端收到請求，然後去驗證客戶端請求裏面帶着token，如果驗證成功，就向客戶端返回請求的數據。
利用token機制進行登錄認證，可以有以下方式：
a.用設備mac地址作爲token
客戶端：客戶端在登錄時獲取設備的mac地址，將其作爲參數傳遞到服務端
服務端：服務端接收到該參數後，便用一個變量來接收，同時將其作爲token保存在數據庫，並將該token設置到session中。客戶端每次請求的時候都要統一攔截，將客戶端傳遞的token和服務器端session中的token進行對比，相同則登錄成功，不同則拒絕。
此方式客戶端和服務端統一了唯一的標識，並且保證每一個設備擁有唯一的標識。缺點是服務器端需要保存mac地址；優點是客戶端無需重新登錄，只要登錄一次以後一直可以使用，對於超時的問題由服務端進行處理。
b.用sessionid作爲token
客戶端：客戶端攜帶用戶名和密碼登錄
服務端：接收到用戶名和密碼後進行校驗，正確就將本地獲取的sessionid作爲token返回給客戶端，客戶端以後只需帶上請求的數據即可。
此方式的優點是方便，不用存儲數據，缺點就是當session過期時，客戶端必須重新登錄才能請求數據。
當然，對於一些保密性較高的應用，可以採取兩種方式結合的方式，將設備mac地址與用戶名密碼同時作爲token進行認證。
APP利用token機制進行身份認證
用戶在登錄APP時，APP端會發送加密的用戶名和密碼到服務器，服務器驗證用戶名和密碼，如果驗證成功，就會生成相應位數的字符產作爲token存儲到服務器中，並且將該token返回給APP端。
以後APP再次請求時，凡是需要驗證的地方都要帶上該token，然後服務器端驗證token，成功返回所需要的結果，失敗返回錯誤信息，讓用戶重新登錄。其中，服務器上會給token設置一個有效期，每次APP請求的時候都驗證token和有效期。
token的存儲
token可以存到數據庫中，但是有可能查詢token的時間會過長導致token丟失（其實token丟失了再重新認證一個就好，但是別丟太頻繁，別讓用戶沒事兒就去認證）。
爲了避免查詢時間過長，可以將token放到內存中。這樣查詢速度絕對就不是問題了，也不用太擔心佔據內存，就算token是一個32位的字符串，應用的用戶量在百萬級或者千萬級，也是佔不了多少內存的。
token的加密
token是很容易泄露的，如果不進行加密處理，很容易被惡意拷貝並用來登錄。
加密的方式一般有：
在存儲的時候把token進行對稱加密存儲，用到的時候再解密。sign：將請求URL、時間戳、token三者合併，通過算法進行加密處理。
在網絡層面上token使用明文傳輸的話是非常危險的，所以要使用HTTPS協議。