session,cookie,token總結

HTTP簡介

       HTTP是Hyper Text Transfer Protocol（超文本傳輸協定）的縮寫。它的發展是網際網路協會（World Wide Web Consortium）和Internet工作小組IETF（Internet Engineering Task Force）合作的結果，（他們）最終釋出了一系列的RFC，RFC 1945定義了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定義了今天普遍使用的一個版本——HTTP 1.1。

       HTTP協定（HyperText Transfer Protocol，超文本傳輸協定）是用于從WWW伺服器傳輸超文本到本地浏覽器的傳送協定。它可以使浏覽器更加高效，使網絡傳輸減少。它不僅保證計算機正确快速地傳輸超文本文檔，還确定傳輸文檔中的哪一部分，以及哪部分内容首先顯示(如文本先于圖形)等。

       HTTP是一個應用層協定，由請求和響應構成，是一個标準的用戶端伺服器模型。HTTP是一個無狀态的協定。

       由于http的無狀态性，為了使某個域名下的所有網頁能夠共享某些資料，session和cookie出現了。

用戶端通路伺服器的流程

• 用戶端會發送一個http請求到伺服器端
• 伺服器端接受用戶端請求後，建立一個session，并發送一個http響應到用戶端，這個響應頭，其中就包含Set-Cookie頭部。該頭部包含了sessionId。Set-Cookie格式如下

  Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]

• 在用戶端發起的第二次請求，假如伺服器給了set-Cookie，浏覽器會自動在請求頭中添加cookie
• 伺服器接收請求，分解cookie，驗證資訊，核對成功後傳回response給用戶端

注意點：

• cookie隻是實作session的其中一種方案。雖然是最常用的，但并不是唯一的方法。禁用cookie後還有其他方法存儲，比如放在url中
• 現在大多都是Session + Cookie，但是隻用session不用cookie，或是隻用cookie，不用session在理論上都可以保持會話狀态。可是實際中因為多種原因，一般不會單獨使用
• 用session隻需要在用戶端儲存一個id，實際上大量資料都是儲存在服務端。如果全部用cookie，資料量大的時候用戶端是沒有那麼多空間的。
• 如果隻用cookie不用session，那麼賬戶資訊全部儲存在用戶端，一旦被劫持，全部資訊都會洩露。并且用戶端資料量變大，網絡傳輸的資料量也會變大

Cookie

         cookie 是一個非常具體的東西，指的就是浏覽器裡面能永久存儲的一種資料，僅僅是浏覽器實作的一種資料存儲功能。

         cookie由伺服器生成，發送給浏覽器，浏覽器把cookie以kv形式儲存到某個目錄下的文本檔案内，下一次請求同一網站時會把該cookie發送給伺服器。由于cookie是存在用戶端上的，是以浏覽器加入了一些限制確定cookie不會被惡意使用，同時不會占據太多磁盤空間，是以每個域的cookie數量是有限的。

Session

        session 從字面上講，就是會話。

       為了做身份區分，伺服器就要給每個用戶端配置設定不同的“身份辨別”，然後用戶端每次向伺服器發請求的時候，都帶上這個“身份辨別”，伺服器就知道這個請求來自于誰了。至于用戶端怎麼儲存這個“身份辨別”，可以有很多種方式，對于浏覽器用戶端，大家都預設采用 cookie 的方式。

       伺服器使用session把使用者的資訊臨時儲存在了伺服器上，使用者離開網站後session會被銷毀。這種使用者資訊存儲方式相對cookie來說更安全，可是session有一個缺陷：如果web伺服器做了負載均衡，那麼下一個操作請求到了另一台伺服器的時候session會丢失。

token

       token 也稱作令牌，由uid+time+sign[+固定參數]

       token 的認證方式類似于臨時的證書簽名, 并且是一種服務端無狀态的認證方式, 非常适合于 REST API 的場景. 所謂無狀态   就是服務端并不會儲存身份認證相關的資料。

組成

• uid: 使用者唯一身份辨別
• time: 目前時間的時間戳
• sign: 簽名, 使用 hash/encrypt 壓縮成定長的十六進制字元串，以防止第三方惡意拼接
• 固定參數(可選): 将一些常用的固定參數加入到 token 中是為了避免重複查庫

存放

        token在用戶端一般存放于localStorage，cookie，或sessionStorage中。在伺服器一般存于資料庫中

token認證流程

        token 的認證流程與cookie很相似

• 使用者登入，成功後伺服器傳回Token給用戶端。
• 用戶端收到資料後儲存在用戶端
• 用戶端再次通路伺服器，将token放入headers中
• 伺服器端采用filter過濾器校驗。校驗成功則傳回請求資料，校驗失敗則傳回錯誤碼

Tokens的優勢

• 無狀态、可擴充

        在用戶端存儲的Tokens是無狀态的，并且能夠被擴充。基于這種無狀态和不存儲Session資訊，負載負載均衡器能夠将使用者資訊從一個服務傳到其他伺服器上。如果我們将已驗證的使用者的資訊儲存在Session中，則每次請求都需要使用者向已驗證的伺服器發送驗證資訊(稱為Session親和性)。使用者量大時，可能會造成一些擁堵。但是不要着急。使用tokens之後這些問題都迎刃而解，因為tokens自己hold住了使用者的驗證資訊。

• 安全性

        請求中發送token而不再是發送cookie能夠防止CSRF(跨站請求僞造)。即使在用戶端使用cookie存儲token，cookie也僅僅是一個存儲機制而不是用于認證。不将資訊存儲在Session中，讓我們少了對session操作。 

         token是有時效的，一段時間之後使用者需要重新驗證。我們也不一定需要等到token自動失效，token有撤回的操作，通過token revocataion可以使一個特定的token或是一組有相同認證的token無效。

• 可擴充性

        Tokens能夠建立與其它程式共享權限的程式。例如，能将一個随便的社交帳号和自己的大号(Fackbook或是Twitter)聯系起來。當通過服務登入Twitter(我們将這個過程Buffer)時，我們可以将這些Buffer附到Twitter的資料流上(we are allowing Buffer to post to our Twitter stream)。

        使用tokens時，可以提供可選的權限給第三方應用程式。當使用者想讓另一個應用程式通路它們的資料，我們可以通過建立自己的API，得出特殊權限的tokens。

• 多平台跨域

        我們提前先來談論一下CORS(跨域資源共享)，對應用程式和服務進行擴充的時候，需要介入各種各種的裝置和應用程式。

隻要使用者有一個通過了驗證的token，資料和資源就能夠在任何域上被請求到。

Access-Control-Allow-Origin: *       
           

• 基于标準

        建立token的時候，你可以設定一些選項。标準的用法會在JSON Web Tokens展現。