Cookie 和 Session 是 Web 應用程序中用于保持用戶狀態的兩種常見機制，它們之間既有聯系也有區別。

Cookie 是由服務器在 HTTP 響應中發送給客戶端（通常是瀏覽器）的一小段數據。客戶端將這些信息保存在本地，并在后續的請求中自動將其發送回服務器。

而 Session 是在服務器端創建的一種機制，用于跟蹤用戶的會話狀態。服務器會給每個用戶分配一個唯一的會話 ID，并將該 ID 通過 Cookie 或其他方式傳遞給客戶端。客戶端隨后在請求時攜帶會話 ID，服務器根據這個 ID 從內存或數據庫中檢索與該用戶相關的會話數據。

1.Cookie和Session的關系

嚴格意義上來說，Cookie 和 Session 是沒有任何關系的，但 Session 的實現中借助了 Cookie 機制。

通過以下 Session 執行的機制，我們就能知道 Session 是如何借助 Cookie 完成自己的執行流程的：

• 會話創建：通常情況下，當用戶登錄成功后，服務器會為該用戶創建一個新的會話。在創建會話過程中，服務器會為該會話生成一個唯一的標識符，通常稱為 Session ID。
• Session ID 傳遞：服務器將生成的 Session ID 通過響應的方式發送給客戶端，使用 SetCookie 命令，將用戶的 Session ID 保存在 Cookie 中，通常是一個名為 JSESSIONID 的 Cookie。
• Session 數據存儲：在服務器端，Session 數據會被存儲在一個能夠關聯 Session ID 的數據結構中（例如內存、數據庫或者文件存儲等）。常用的方式是將 Session ID 作為鍵，與對應的 Session 用戶身份數據進行關聯。
• Session ID 驗證與檢索：當用戶發送一個新的請求時，客戶端會將之前存儲的 Session ID 攜帶在請求的 Cookie 或請求頭中發送給服務器。服務器會根據 Session ID 找到對應的 Session 數據，從而獲得用戶的狀態信息。
• Session 數據使用：服務器在獲取到 Session 數據后，可以根據具體需求讀取、修改或刪除其中保存的狀態信息。服務器可以通過 Session 來管理用戶的登錄狀態、購物車內容、用戶配置等。
• Session 過期與銷毀：Session 有一個有效期限，一般通過設置一個固定的時間，或者在一定時間內沒有用戶活動時會將 Session 標記為過期。當 Session 過期時，服務器會銷毀對應的 Session 數據，釋放內存或其他資源。

所以默認情況下，Session 是借助 Cookie 來完成身份標識的傳遞的，這樣服務器端才能根據 Session ID 和保存的會話信息進行關聯，用于找到某個具體登錄的用戶，所以說：默認情況下，Session 機制是依賴 Cookie 實現的。

2.禁用Cookie后Session還能用嗎？

那么問題來了，禁用 Cookie 后 Session 還能用嗎？

答案是：默認情況下禁用 Cookie 后，Session 是無法正常使用的。

“

這是因為大多數 Web 服務器都是依賴于 Cookie 來傳遞 Session 的會話 ID 的。客戶端瀏覽器禁用 Cookie 時，服務器將無法把會話 ID 發送給客戶端，客戶端也無法在后續請求中攜帶會話 ID 返回給服務器，從而導致服務器無法識別用戶會話。

”

但是，默認情況下禁用 Cookie 后，Session 就不能用了，但可以通過一些手段來解決這個問題。

3.解決方案

以下的兩種解決方案可以繞過 Cookie 繼續運行 Session：

• URL 中攜帶 SessionID：可以通過 URL 重寫的方式將 Session ID 添加到所有的 URL 中。服務器生成 Session ID 后，將其作為 URL 的一部分傳遞給客戶端，客戶端在后續的請求中將 Session ID 帶在 URL 中。服務器端需要相應地解析 URL 來獲取 Session ID，并維護用戶的會話狀態。
• 隱藏表單字段傳遞 SessionID：將 Session ID 添加到 HTML 表單的隱藏字段中。在每個表單中添加一個隱藏的字段，保存 Session ID，客戶端提交表單時會將 Session ID 隨表單數據一起發送到服務器，服務器通過解析表單數據中的 Session ID 來獲取用戶的會話狀態。
• 這些方法雖然可以在禁用 Cookie 的情況下繼續使用 Session，但需要在服務器端進行相應的代碼修改和配置。但同時這些手段也帶來了以下幾個新問題：
• 增加了編碼復雜度：需要改前端和后端代碼才能繼續使用 Session 機制，增加了編碼復雜度。
• 增加了安全風險：這些替代方法可能會增加一些安全風險，因為 Session ID 將以明文形式出現在 URL 或表單中，很容易被第三方劫持和獲取。

小結

Session 實現是依賴 Cookie 來存儲會話 ID 的，所以默認情況下，如果禁用了 Cookie，Session 就不能使用了。

但是我們可以通過特殊的手段，例如在 URL 中傳遞 SessionID 或表單中使用隱藏字段傳遞 SessionID 的方式，配合服務器端代碼的修改，是 Session 機制繼續使用，但這樣使用增加了編碼的復雜度，和帶來了一定的安全風險。