Cookie 與 Session 區別與聯繫詳解：原理、存儲、安全性與分布式擴展

Cookie 與 Session 區別與聯繫詳解：原理、存儲、安全性與分布式擴展

Cookie 和 Session 是 Web 會話管理的雙基石。本文從 HTTP 無狀態本質切入，系統對比兩者機制、存儲位置、生命周期、安全性、跨域行為，並給出分布式 Session 共享方案。

一、HTTP 無狀態與會話管理需求

HTTP 協議本質是無狀態的：每個請求獨立，服務端不記住客戶端身份。為了識別用戶狀態（登錄態、購物車、偏好設置），引入了會話管理機制：

• Cookie：客戶端存儲，隨請求自動發送
• Session：服務端存儲，通過 SessionID 關聯

二、核心差異對比表

三、工作原理深度解析

1. Cookie 機制

// 服務端設置 Cookie (Servlet)
Cookie cookie = new Cookie("userId", "12345");
cookie.setMaxAge(60 * 60 * 24 * 7); // 7天過期，秒為單位；-1=會話級；0=刪除
cookie.setPath("/");                // 生效路徑
cookie.setDomain(".example.com");   // 跨子域共享
cookie.setHttpOnly(true);           // 防 XSS：JS 無法讀取
cookie.setSecure(true);             // 僅 HTTPS 傳輸
response.addCookie(cookie);

// 瀏覽器自動攜帶
// Request Headers: Cookie: userId=12345; JSESSIONID=ABC...

2. Session 機制

// 服務端創建/獲取 Session
HttpSession session = request.getSession(); // 無則創建，有則返回
HttpSession session = request.getSession(false); // 無則返回 null

// 存取數據
session.setAttribute("user", userObj);
User user = (User) session.getAttribute("user");

// 設置超時 (秒)
session.setMaxInactiveInterval(30 * 60); // 30分鐘

// 銷毀
session.invalidate();

// 底層流程：
// 1. 首次請求 → 服務端生成 SessionID (UUID) → 存入內存 Map
// 2. 通過 Set-Cookie: JSESSIONID=xxx 發送給瀏覽器
// 3. 後續請求 → 瀏覽器自動攜帶 Cookie: JSESSIONID=xxx
// 4. 服務端解析 Cookie → 從 Map 獲取 SessionData

四、SessionID 傳遞的三種方式

1. Cookie (默認)：JSESSIONID=abc 在 Cookie 中
2. URL 重寫：/app/action;jsessionid=abc (Cookie 被禁用時備選)
3. 隱藏表單字段：<input type="hidden" name="jsessionid" value="abc"> (極少用)

Servlet 容器自動處理，開發者無感知。response.encodeURL(url) 可自動追加 SessionID。

五、安全性最佳實踐

Cookie 安全屬性組合拳

Cookie cookie = new Cookie("token", "xxx");
cookie.setHttpOnly(true);   // 必須：防 XSS 竊取
cookie.setSecure(true);     // 必須：僅 HTTPS (生產環境)
cookie.setPath("/");        // 最小權限路徑
cookie.setDomain(".api.example.com"); // 最小權限域名
cookie.setMaxAge(3600);     // 短期過期
// SameSite 屬性 (Servlet 2.5+ 需手動設置 Header)
// response.addHeader("Set-Cookie", "token=xxx; SameSite=Strict; Secure; HttpOnly");

Session 安全加固

• SessionID 足夠長、足夠隨機 (容器默認滿足)
• 登錄後重新生成 SessionID：request.changeSessionId() 防 Session Fixation
• 敏感操作二次驗證：修改密碼、轉賬需重新輸入密碼/OTP
• 並發登錄控制：單用戶單 Session，新登錄踢舊

六、分布式 Session 共享方案

單體應用 Session 存內存，集群下請求分發到不同節點導致 Session 丟失。

Spring Session + Redis 實戰配置

    org.springframework.session
    spring-session-data-redis



spring:
  session:
    store-type: redis
    redis:
      namespace: spring:session
      flush-mode: on_save
  redis:
    host: localhost
    port: 6379

七、總結：如何選擇？

• 少量非敏感、需持久化、跨會話 → Cookie (設置 HttpOnly+Secure+SameSite)
• 用戶身份、權限、敏感業務、大數據 → Session (配合 Redis 共享)
• 微服務、前後端分離、移動端、跨域 → JWT Token (Access Token + Refresh Token)
• 極簡部署、單體、低併發 → 內存 Session + Sticky Session