【Java EE】Cookie

Cookie

• [为什么需要 Cookie](#为什么需要 Cookie)
• 认证流程详解
• • [Session 对象](#Session 对象)
  • SessionId
  • [Cookie 传递](#Cookie 传递)
  • 过期机制
• 安全相关配置
• 注销处理
• 分布式环境注意事项

为什么需要 Cookie

HTTP 是无状态协议，每次请求相互独立，服务器默认无法判断两次请求是否来自同一用户。同时，浏览器出于安全限制，不允许 JavaScript 直接读写本地文件系统。因此，浏览器引入 Cookie 机制，将少量数据存储在浏览器端，请求时自动发送给服务器，以此实现状态保持。

认证流程详解

最常见的应用场景是登录认证。
服务器 浏览器 服务器 浏览器 2. 验证用户名密码 3. 匹配成功， 生成 sessionId + session 对象 存入内存哈希表 5. 浏览器保存 Cookie --- 后续请求 --- 7. 通过 sessionId 识别用户身份 1. 发送登录请求（用户名、密码） 4. Set-Cookie: sessionId=xxxx 6. 请求 + Cookie: sessionId=xxxx 8. 返回用户相关数据

Session 对象

• 存储在服务器端，通常是一个键值对结构。
• 保存当前会话的用户信息，如 userId、username、登录时间、权限等。
• 客户端看不到 Session 的具体内容，只能拿到对应的 sessionId。

SessionId

• 会话的唯一标识，由服务器生成。
• 生成要求：长度足够（通常 128 位以上），使用密码学安全随机数，防止被猜测或遍历。
• 本身不包含业务数据，只是一把"钥匙"。

Cookie 传递

• 服务器通过响应头 Set-Cookie 下发 sessionId。
• 浏览器收到后自动存储，后续相同域名的请求自动在请求头 Cookie 中携带。
• 这个携带过程由浏览器自动完成，代码无需手动拼接。

过期机制

• Cookie 可通过 Max-Age（相对时间，单位秒）或 Expires（绝对时间）设置有效期。
• 过期后浏览器自动删除，下次请求不再携带，服务器视为未登录。
• 服务器端 Session 通常也设置过期时间（如 30 分钟无操作则失效），二者共同控制会话的生命周期。

安全相关配置

属性	作用	建议
HttpOnly	禁止 JavaScript 读取 Cookie	必须设置，防 XSS 窃取
Secure	仅在 HTTPS 下传输 Cookie	生产环境必须设置
SameSite	控制跨站请求是否携带 Cookie	设为 Lax 或 Strict，防 CSRF

示例响应头：

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=86400

注销处理

用户退出登录时，需要同时做两件事：

1. 服务端：销毁对应的 Session 对象，使该 sessionId 失效。
2. 浏览器端 ：删除对应 Cookie（可通过设置 Max-Age=0 覆盖）。

只清除前端 Cookie 而不销毁 Session，攻击者仍可能利用已泄露的 sessionId 完成认证。

分布式环境注意事项

单机部署时 Session 存储在服务器内存中；多机部署时，需使用共享存储方案：

• Redis（最常用）：集中存储 Session，所有服务器共享读写。
• 数据库：读写压力较大，一般不推荐。
• 粘性会话（Sticky Session）：负载均衡将同一用户始终路由到同一台机器，有单点故障风险，不推荐。