大約幾十年前，那時候的web和現在有很大區別，很多網頁就是簡單的靜態網頁，後端伺服器要做的也只是收到請求後相應相應的html文件、圖片。完全不用記得剛剛是誰發了HTTP請求，而30年前的Web 基本上就是文件的瀏覽而已， 既然是瀏覽，我作為一個伺服器， 為什麼要記住誰在一段時間裡都瀏覽了什麼文件呢？

• session
  

但是web發展太快了，很快互動式的web應用開始興起，比如論壇、電商網站等等。

HTTP作為無狀態協議，他本身是沒有辦法去維持一個狀態的，比如登陸後再點選其他網頁，他是沒有辦法知道你這次是不是以及登陸的，除非你每次都訪問都post你的使用者和密碼。於是人們就想出了一些辦法來解決這個問題，最先登場的就是session和cookie。

web後端需要完成的是管理會話，要記住哪些人登入了系統，還需要區別使用者和使用者。

session是怎麼做的呢，就是給大家發一個seesion id，一個隨機的唯一字串。把這個字串發給使用者，使用者儲存在cookie中，每次傳送http請求時，順便把seesionid給我，這樣就能識別使用者了。

• Memcached

有了session之後，問題似乎得到了解決，使用者只需要記得自己的id就行了，但是對於伺服器而言，需要儲存所有人的seesion id。這是一把巨大的開銷，而且嚴重限制了擴充套件能力。

比如，我用兩臺伺服器做了一個小叢集，使用者A通過伺服器A登陸了系統，那sessionid就會儲存在伺服器A上，假設使用者A下一次請求定向到了伺服器B怎麼辦，伺服器B中並沒有使用者A的seesionid。

這時可以用個小魔法，session sticky。你不是有時候要訪問伺服器B嗎，那我就讓你一直訪問伺服器A不就完了。但是這個辦法也不能解決根本的問題。如果伺服器A掛了，還是得訪問伺服器B。

既然這樣，那我把seesion id各存一份在AB之間，這樣是沒有問題。但是一直在AB之間傳輸session也是一筆巨大的開銷，而且如果是很多臺伺服器呢，這怎麼解決。

然後就有了memcached：把所有人的session id 儲存在一個地方，所有的其他伺服器都來訪問這個地方。這樣就不用在每臺伺服器上都儲存所有人的seesionid了。但這樣也有弊端啊，如果這個memcached掛了，那就也沒得搞了。

• token
  
  

然後我們又進化了，既然存session這麼麻煩，那我們不存了，換個方式進行驗證。

首先我們還是發一個token給使用者，裡面有使用者的userid，這樣我收到taoken的時候我就可以知道使用者是誰了。不過這樣有安全問題，所以我們再來做一個簽名。

比如說我用HMAC-SHA256 演算法，加上一個只有我才知道的金鑰，  對資料做一個簽名， 把這個簽名和資料一起作為token ，   由於金鑰別人不知道， 就無法偽造token了。

和session最大的區別是這個token我不儲存。當我收到token時，我再用同樣的HMAC-SHA256 演算法和同樣的金鑰，對資料再計算一次簽名， 和token 中的簽名做個比較， 如果相同， 我就知道使用者已經登入過了，並且可以直接取到使用者的user id ,  如果不相同， 資料部分肯定被人篡改過， 我就告訴傳送者： 對不起，沒有認證。

Token 中的資料是明文儲存的（雖然我會用Base64做下編碼， 但那不是加密）， 還是可以被別人看到的， 所以我不能在其中儲存像密碼這樣的敏感資訊。

當然， 如果一個人的token 被別人偷走了， 那我也沒辦法， 我也會認為小偷就是合法使用者， 這其實和一個人的session id 被別人偷走是一樣的。

這樣一來， 我就不儲存session id 了， 我只是生成token , 然後驗證token ，  我用我的CPU計算時間獲取了我的session 儲存空間 ！