網上有很多關于 session 的討論，不過在我看來許多都把 session 狹義化了

http 無狀態，所以為了實現有狀態 http，才有了會話(session)的概念。說實話，網上很多關于會話的討論都過于具體，會牽扯到不同的實現方案，容易讓人誤會，下文的“會話”都指的是廣義的 web 會話。

這是我在網上能找到的很貼切的，不摻雜實現方法的解釋, 會話:會話(Session)是一個客戶與服務器之間的不中斷的請求響應序列。對客戶的每個請求，服務器能夠識別出請求來自于同一個客戶。當一個未知的客戶向Web應用程序發送第一個請求時就開始了一個會話。當客戶明確結束會話或服務器在一個預定義的時限內不從客戶接受任何請求時，會話就結束了。當會話結束后，服務器就忘記了客戶以及客戶的請求。

網上很流行的一種說法是 token 無狀態，這是不嚴謹的。token 可以表明身份，讓服務器區分開多個請求分別是由誰發送的。簡單來說，token 可以校驗用戶是否登錄，登錄是否有效，這不是狀態又是什么。。。當然，如果 token 用于認證授權之外，那或許可以無狀態。

不管是“session id”，還是所謂“token”(如 jwt)，其實都是會話的一種實現方式。形式上“session id”和“token”都是“字符串”，這個“字符串”可以是任意的編碼，本質上都是 credential(會話憑證)。會話基本概念

客戶端保管方式

credential 由客戶端保管，客戶端怎么存放幾乎不關服務器的事，瀏覽器，安卓 app，ios app，桌面應用等都是客戶端

瀏覽器一般把 credential 放在cookie里，就像把曲奇餅(cookie)放在小罐子里，cookie 特殊的地方在于，瀏覽器會聽服務器的話，比如服務器在設置cookie時指定了“http only”，那瀏覽器就不會允許 js 拿到

至于其他的客戶端，想放哪放哪，直接存文件或存本地數據庫都行，或者還有其他騷操作都行。

傳輸方式

這里只討論 http 協議，最常見的說法是“session_id”放 cookie 里，“token”放自定義的headers 里。

但這不是必須的，本來就只是“字符串”而已，放哪都是可以的，何況 cookie 也在 headers 里。

主流瀏覽器都內置了對 cookie 字段的支持，其他客戶端所謂的不支持 cookie，也僅僅意味著不會自動處理而已，除非客戶端禁止該字段在 headers 里存在, 否則你都可以自行處理 cookie。

也就是說 "session_id" 可以放在自定義的 headers 里，"token"也可以放在 cookie 里，問題僅僅在于如何選擇而已。至于代碼的實現，一般的框架都自帶一套處理方式，而且也應該能允許用戶使用其他的實現方案，這就是接口存在的意義之一。如果 web 框架連 session 的實現方式都不允許自定義，還是趁早棄坑吧。

會話信息存放方式

一般來講會話中包含有一定量的信息，最核心的就是會話 id ，還有其他的信息，比如user_id 之類的。不同的實現方案會把會話信息放在不同的地方。

如果 credential 里沒有會話信息，那它就是“session id”，其他的會話信息由服務器保管，保管的地方則是各有各的法子，比如內存，數據庫，redis，甚至本地文件。

如果 credential 里包含了會話信息，也就是所謂“token”，那服務器就不需要花地方保存了，不過相應的代價是網絡流量會大一點。本來保存在服務器的信息保存在了 token 里，自然會大一點。另外根據不同的字符串編碼，可能還要要花時間計算(比如 jwt)

有人說 token 可以減小服務器存儲空間，但這可以不一定是好事，如果光是活躍的會話信息就大到幾個g了，那活躍期的網絡流量光是傳個 token 就要占用幾個g的帶寬，何況其他的信息所占流量。如果實際峰值流量沒那么大，也說明花掉的存儲空間不值一提。至少存儲空間不應該成為選擇方案的理由。

控制力

基本上，服務器保管的會話信息越多，對會話的控制力就越高。

比如很普遍的一個情況，你要禁止一個用戶同時登錄多個瀏覽器，或同時登錄多個客戶端。

如果用“session id”的方式實現，你只需要在服務器端刪掉該用戶的其他會話，或讓他過期即可，客戶端單方面持有舊“session id”也沒用。

如果用“token”的方式實現，由于你無法要求客戶端刪除他的 token ，所以無法僅僅依靠 token 來實現。可行的實現方案之一， token 里加時間戳，某個時間點以前的 token 全部失效。是不是很容易就實現了？然而這個失效的時間點，卻需要依然服務器來記錄，一旦你這么做了，其實就相當于把一部分會話信息保存在了服務器，同時，不同客戶端保存各自的 token 里也有一部分會話信息。

實際項目中，很少會使用純粹的 token 實現方案，即會話信息全部保存在 token 里，服務端不保存任何信息。就如上面所說，實現某些功能時，需要 token 和服務端分別保存用于校驗的信息，才能對 token 進行校驗，實現對 token 的控制。

綜上

“session id”和“token”之間絕對沒有高下之分，無非是取舍而已，空間還是時間，流量大還是小，控制力高還是低。

在各種 session 方案中，你會發現實現細節都不一樣，flask session, django session, spring session, jwt 等等。但萬變不離其宗， credential 的客戶端保存方式，credential 的傳輸方式和會話信息的保存方式，都只是這幾個流程的細節有改變而已，本質都是為了實現有狀態的 http。

總結

以上是生活随笔為你收集整理的cookie被淘汰_session正在被淘汰吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。