很久很久以前，web基本上就是文件的瀏覽而已,既然是瀏覽，作為伺服器、不需要記錄誰在某一段時間裡都瀏覽了什麼文件。
每次請求都是乙個新的http協議,就是請求加響應，尤其不用記住是誰則剛發了http請求,每個請求相對來說都是全新的。
也就是說必須把每個人區分開，這是乙個不小的挑戰,因為http請求是無狀態的,所以想出的辦法就是給大家發乙個會話標識(session id)。
說白了就是乙個隨機的字串,每個人收到的都不一樣，每次大家發起http請求的時候,把這個字串給一併捎過來,這樣就能區分開誰是誰了。
這樣大家很高興了，可是伺服器就不高興了，每個人只需要儲存自己的session id，而伺服器則要儲存所有人的session id。如果訪問伺服器多了，就得有成千上萬，甚至幾十萬或上百萬個。這對伺服器來說是乙個巨大的開銷，嚴重限制了伺服器擴充套件能力。
比如用2個機器組成了乙個集群，小明通過機器a登入了系統，那麼sessionid會儲存在機器a上，假設小明的下一次請求被**到機器b怎麼辦？機器b沒有小明的session id。
這時候會採用一點小伎倆：session sticky，就是讓小明的請求一直粘連在機器a上，但是這也不管用，要是機器a掛掉了，請求還得轉到機器b上去。
那只好做session 的複製了，把session id在2個機器之間來搬去，非常累。
後來有個叫mencached的支了招：把session id集中儲存到乙個地方，所有的機器都來訪問這個地方的session資料。
這樣一來，就不用複製了，但是增加了單點失敗的可能性，要是那個負責session的機器掛了，所有人都得重新登入一遍，估計得被網路噴子「照顧」一番。
後來嘗試把這個單點的機器也集群，增加可靠性，但不管如何，這小小的session還是乙個沉重的負擔。
於是有人提出，為什麼要儲存這個可惡的session，只讓每個客戶端去儲存該多好。可是如果不儲存這些sessionid，怎麼驗證客戶端發出的session id的確是正確生成的呢?
如果不去驗證，都不知道他們是不是合法登入的使用者，哪些不懷好意的傢伙們就可以偽造session id為所欲為了。
關鍵點就是驗證。比如說，小明已經登入了系統，給他發了乙個令牌(token)，這裡邊包含了小明的user id，下一次小明再次通過http請求訪問的時候，把這個token通過http header帶過來不就可以了。不過這和session id沒有本質區別，任何人都可以偽造，所以得想辦法，讓別人偽造不了。
那就對資料做乙個簽名(加密)吧，比如說用hmac-sha256真法，加上乙個只有我才知道的金鑰，對資料做乙個簽名,把這個簽名和資料一起作為token，由於金鑰別人不知道，就無法偽造token 了。
這個token不儲存，當小明把這個token發過來的時候，再用同樣的hmac-sha256演算法和同樣的金鑰,對資料再計算一次簽名，和token中的簽名做個比較，如果相同，就知道小明已經登入過了，並且可以直接取到小明的user id，如果不相同，資料部分肯定被人篡改過，就告訴傳送者：對不起，沒有您認證。
token中的資料是明文儲存的(雖然會用base64做下編碼,但那不是加密)，還是可以被別人看到的，所以不能在其中儲存像密碼這樣的敏感資訊。
當然，如果乙個人的token被別人偷走了，那也沒辦法，也會認為小偷就是合法使用者，這其實和乙個人的session id被人偷走是一樣的。這樣一來，就不用儲存session id了，只是生成token，然後驗證token，用cpu計算時間獲取了我的session 儲空間。解除了session d這個負擔,可以說是無事一身輕，機器集群現在可以輕鬆地做水平擴充套件，使用者訪問量增大，直接加機器就行。這種無狀態的感覺實在是太好了。
cookie是乙個非常具體的東西，指的就是瀏覽器裡面能永久儲存的一種資料，僅僅是瀏覽器實現的一種資料儲存功能。cookie是由伺服器生成，傳送給瀏覽器，瀏覽器把cookie以key-value形式儲存到某個目錄下的文字檔案內,下一次請求同一**時會把該cookie傳送給伺服器。
由於cookie是存在客戶端上的，所以瀏覽器加入一些限制,確保cookie 不會被惡療使用，同時不會佔據太多磁碟空間。所以每個域的cookie數量是有限的。
session從字面上講，就是會話。這個就類似於正在和乙個人交談，怎麼知道當前和你交談的是張三而不是李四呢？對方肯定有某種特徵表明他就是張三。
session也是類似的道理，伺服器要知道當前發請求給自己的是誰。
為了做這種區分，伺服器就要給每個客戶端分配不同的身份標識，然後客戶端每次向伺服器發請求的時候，都帶上這個身份標識，伺服器就知道這個請求來自於誰了。
至於客戶端怎麼儲存這個「身份標識"，可以有很多種方式，對於瀏覽器客戶端，大家都預設採用cookie的方式。
伺服器使用session 把使用者的資訊臨時儲存在了伺服器上，使用者離開**後session會被銷毀。
在web領域基於token的身份驗證隨處可見。在大多數使用web api的網際網路公司中，token是多使用者下處理認證的最佳方式。
以下特性會在程式中使用基於token的身份驗證：
1、無狀態、可擴充套件大部分的api和web應用部使用token。例如facebook，twiter，google+，github等2、支援移動裝置
3、跨程式呼叫
4、安全
在介紹基於token的身份驗證的原理與優勢之前，不妨先看看之前的認證都是怎麼做的。
http協議是無狀態的，這種無狀態意味著程式需要驗證每一次請求，從而辨別客戶端的身份。
在這之前，程式都是通過在服務端儲存的登入資訊來辨別i求的。這種方式一般都是通過儲存session來完成。隨著we應用程式移動端的興起，這種驗證的方式逐漸暴露出了問題，尤其是在可擴充套件性方面。
基於伺服器驗證方式暴露的一些問題:
1、seesion;每次認證使用者發起請求時，伺服器需要去建立乙個記錄來儲存資訊。當越來越多的使用者發請求時，記憶體的開銷也會不斷增加。在這些問題中，可擴充套件性是最突出的，因此有必要去尋求種更有行之有效的方法。2、可擴充套件性：在服務端的記憶體中使用seesion 儲存登入資訊，伴隨而來的是可擴充套件性問題。
3、跨域資源共享(cors)：當需要讓資料跨多合移動裝置使用時，跨域驚源的共享會是乙個讓人頭疼的問題，在使用ajax抓取另乙個域的資源，就可能會出現禁止請求的情況。
4、跨站請求偽造(srf）：使用者在訪問銀行**時，很容易受到跨站請求偽造的攻擊，並且容易被利用訪回其他的**。
基於token的身份驗證是無狀態的，不將使用者資訊存在伺服器或session中，這種概念解決了在服務端儲存資訊時的許多問題。
nossession意味著程式可以根據需要去增減機器，而不用擔心使用者是否登入。
基於token的身份驗證的過程如下:
1、使用者通過使用者名稱和密碼傳送請求每一次請求都需要token。token應該在http的頭部傳送從而保證了http請求無狀態。2、程式驗證
3、程式返回乙個簽名的token給客戶端
4、客戶端儲存token，並且每次用於每次傳送請求
5、服務端驗itoken並返回資料
通過設定伺服器屬性 access-control-allow-origin:*， 讓伺服器能接受到來自所有城的請求。、
需要注意的是，在acao頭部標明(designating)*時，不得帶有像http認證，客戶端ssl證書和cookie的證書。
實現思路:
1、使用者登入校驗,校驗成功後就返回token給客戶端當在程式中認證了資訊並取得token之後，便能通過這個token做許多的事情。2、客戶端收到資料後儲存在客戶端
3、客戶端每次訪問api是攜帶token到伺服器端
4、伺服器端採用filter過濾器校驗。校驗成功則返回請求資料，校驗失敗則返回錯誤碼。
甚至能建立乙個基於許可權的token傳給第三方應用程式，這些第三方程式能夠獲取到我們的資料(當然只有在我們允許的特定的token下)。
在客戶端儲存的tokens是無狀態的，並且能夠被擴充套件。基於這種無狀態和不儲存session資訊，負載均衡器能夠將使用者資訊從乙個伺服器傳到其他伺服器上。
如果將已驗證的使用者資訊儲存在session，則每次請求都需要使用者向已驗證的伺服器傳送驗證資訊。
但是不要著急。使用token之後這些問題都會迎刃而解，因為tokens 自己hold住了使用者的驗證資訊。
請求中傳送token而不再是傳送cookie能夠防止跨站請求偽造(csrf).
即使在客戶端使用cookie儲存token。cookie也僅是乙個儲存機制而不是用於認證。不怒急昂資訊儲存在session中，讓我們少了對session的操作。
token 是有時效的，一段時間後使用者需要重新驗證。我們也不一定需要等到token自動失效，token有撤回操作，通過ken revocation 可以使乙個特定的token或是一組形同的認證的token無效。
token 能夠建立與其他程式共享許可權的程式。例如，能將乙個隨便的社交帳號和自己的fackbook或twitter 系起來。
當通過服務登入twitter (我們將這個過程稱作buffer)時，可以將這些buffer附到twitter 資料流上。
使用token時，可以提供可選的許可權給第三方應用程式。當使用者想讓另乙個應用程式訪問它們的資料，可以通過建自己的api，產生特殊許可權的tokens.。
再來談論一下跨域資源共享(cors)，對應用程式和服進行擴充套件的時候，需要介入各種各種的裝置和應用程式。
只要使用者有乙個通過了驗證的token,資料和資源就能在任何域上被請求到。
本文出自 《計算機與網路》 2019. 22期 「詳細了解 cookie session token」
apply call詳細了解
function thisobj argarray call 方法 function call thisobj arg1 arg2.定義 call 呼叫乙個物件的乙個方法，用另乙個物件替換當前物件。例 b.call a,args1,args2 a物件應用b物件的方法 他們都是用來代替另乙個物件呼叫乙...
詳細了解try catch return
情況1 try中有return，finally中沒有return public class trytest private static inttest catch exception e finally system.out.println finally return num 輸出結果如下 tr...
詳細了解 int 型別
一 int?是什麼 二 了解nullable結構體 三 nullable型別的取值與轉換 1.getvalueordefault 2.運算子過載 一 int?是什麼 說到int?或者double?平時只是在接收資料庫傳來的可空值型別資料時用用。但int既然是值型別，不能為空，為什麼int?就可空了呢...