<h1類"pgc-h-right-arrow"資料軌道">的前言。</h1>
我們知道HTTP是一種無狀态協定，服務端不知道哪個請求是由哪個使用者發起的。在某些情況下，我們需要知道哪個使用者發起了請求以及哪個使用者操作了請求。例如，在市場服務中，使用者發起下訂單請求，服務端需要确定它是哪個特定使用者。是以，服務端需要使用某種機制來識别和記錄使用者的資訊，狀态等。
會話機制是通過使無狀态協定的 HTTP 成為有狀态來實作的。服務端為每個請求服務端使用者建立自己的會話，以識别和跟蹤使用者。會話存儲在服務端，可以存儲在檔案、記憶體、資料等中，并具有唯一的辨別會話 ID。服務端建立會話後，服務端通過 HTTP 協定告訴用戶端在本地 Cookie 中記錄會話 ID。這允許來自同一用戶端的每個後續請求将 Cookie 發送到服務端，服務端通過檢測存儲在服務端的會話 ID 來找出哪個使用者是請求的使用者。
<h1 class="pgc-h-arrow-right" data-track="13">Session</h1>
會話中文是指會話，訴訟時效。實際上，用戶端和服務端一對一互動是一種抽象的概念。許多人認為 Session 是由以下代碼擷取的 Session 對象，但這隻是 Cookie 的更通用的實作之一。會話有許多實作。
由于大多數應用程式使用 Cookie 來實作會話跟蹤，是以這是上面的代碼行。餅幹是真實的。當用戶端請求用戶端并首先建立會話時，用戶端通過 HTTP 協定（用于 HTTP 響應标頭的 Set-Cookie）告訴用戶端會話 ID 需要記錄在本地 Cookie 中。該鍵的值為 JSESSIONID。
然後，來自同一用戶端的每個後續請求都将 Cookie 發送到服務端，服務端通過檢測存儲在服務端的會話 ID 來找出哪個使用者是請求的使用者。
但是，用戶端浏覽器可以禁用 Cookie，這可能會導緻問題。但是我們可以使用URL覆寫技術來實作會話跟蹤，即向請求服務端的所有請求參數添加代表性使用者ID或會話ID。
正如我們之前所說，會話可以存儲在檔案，記憶體，資料庫等中。會話資訊存儲在哪裡其實要根據自己的業務來決定，所有出廠業務場景來講技術架構都是流氓，技術本身不是好是壞，但什麼業務場景适合什麼技術，這也是架構師考慮技術選擇能力的一個方面。
但是，會話機制需要考慮群集服務中的會話一緻性問題。會話同步可以在叢集服務中完成，但這種方法存在一些缺點，如同步麻煩、同步延遲，以及同一會話的多機存儲浪費存儲空間。另一種常見的方法是使用專用的會話服務叢集來儲存使用者會話資訊，例如 Redis 緩存服務，它不僅支援叢集的高可用性，而且還基于快速記憶體性能。
<h1 class="pgc-h-arrow-right" data-track="24">Cookie</h1>
Cookie 是用戶端技術，是許多人實作會話會話的選擇，服務端允許用戶端将一些資訊寫入本地 Cookie 以進行會話跟蹤。但是，請注意，浏覽器會在本地禁用 Cookie。
當涉及到cookie時，很難說許多廣告商，網站等使用我們的個人隐私來跟蹤，分析我們的行為并提出個性化推薦。許多網站使用第三方cookie來擷取使用者資訊并将其發送到服務以記錄使用者的行為。你肯定還會在其他應用中遇到關于抗脫發的讨論，然後你打開淘寶驚喜發現，向你推薦各種抗脫發洗髮乳。但是，某些浏覽器已禁用第三方cookie或優化處理，例如Safari，Mozilla等。
我們可以手動将一些資訊設定為cookie，以便客戶不僅可以使用它，還可以在随後的請求中相應地處理它。
我們可以通過浏覽器檢視本地存儲的 Cookie 資訊，其他網站可以掃描使用我們存儲的 Cookie，是以某些安全或機密資訊不應存儲在 Cookie 中，因為資料的安全性較低。一般情況下，更重要的資訊，如使用者登入資訊，存儲在服務端會話中，其他資訊，如會話ID，可以存儲在cookie中。
而且單個cookie的大小是有限的，不同的浏覽器限制是不同的，典型的大小是幾kb.不同的浏覽器對于一個域名下的cookie的數量也是有限的，一般是幾十個，而且淘汰政策的時候有一些飽和，是以要注意這些情況， 盡量不要超過浏覽器限制。
作者：傑克·陳
友情連結： https://blog.csdn.net/chenlixiao007/article/details/118873800