Session、Cookie、JWT 详解：从单体到分布式的认证方案演进

Mr__Miss

190人浏览 · 2026-07-13 20:01:51

Mr__Miss · 2026-07-13 20:01:51 发布

这篇文章适合刚接触 Web 认证机制的新手，也适合想系统梳理 Session、Cookie、JWT 知识的开发者。我会从三者的定义、存储位置、生命周期出发，结合单体架构、分布式架构的演进，讲清楚它们的区别与适用场景。

一、核心概念速览

1. Cookie

Cookie 是服务器发送给浏览器并保存在客户端的一小段文本数据。

属性	说明
存储位置	浏览器客户端（SQLite 数据库或文件）
存储内容	键值对数据，如 `JSESSIONID=ABC123`
大小限制	单个 Cookie 约 4KB
生命周期	由 `Expires` 或 `Max-Age` 控制；未设置则为会话级 Cookie，浏览器关闭即失效
传输方式	通过 HTTP 请求头的 `Cookie` 字段自动携带；服务器通过 `Set-Cookie` 响应头设置
安全特性	可设置 `HttpOnly`（防 XSS 读取）、`Secure`（仅 HTTPS）、`SameSite`（防 CSRF）

Cookie 本身只是"存储介质"，不解决认证问题。它最常见的用途是承载 SessionID。

2. Session

Session 是服务器端存储用户会话状态的内存/存储对象。

属性	说明
存储位置	服务器端（Tomcat 的 `ConcurrentHashMap`、Redis、数据库等）
存储内容	用户身份信息、权限、业务上下文等敏感数据
大小限制	受服务器内存或存储限制
生命周期	由服务器控制（默认 30 分钟超时）；可手动销毁
传输方式	客户端只持有 SessionID，实际数据不经过网络传输
安全特性	数据不暴露给客户端，安全性高

Session 是"有状态"的认证方案——服务器需要记住每个用户。

3. JWT（JSON Web Token）

JWT 是一种无状态的、自包含的 Token 格式标准。

属性	说明
存储位置	客户端（localStorage / sessionStorage / Cookie / 内存）
存储内容	Header（元数据）+ Payload（用户信息）+ Signature（签名）
大小限制	比 Cookie 大，通常几 KB
生命周期	由 Payload 中的 `exp`（过期时间）字段控制
传输方式	通常放在 `Authorization: Bearer <token>` 请求头中
安全特性	Payload 仅 Base64Url 编码（非加密），不能存敏感信息；签名防止篡改

JWT 是"无状态"的认证方案——服务器不存储会话信息，只负责验证 Token 的签名。

二、三者的本质区别

维度	Cookie	Session	JWT
存储位置	客户端	服务端	客户端
是否有状态	无状态（存储介质）	有状态	无状态
数据可见性	客户端可见	客户端不可见	客户端可见（Base64Url 编码）
安全性	中（可被篡改/窃取）	高（数据不暴露）	中（需签名验证 + HTTPS）
扩展性	不涉及	分布式需共享存储	天然适合分布式
主动撤销	支持（删除/覆盖）	支持（删除 Session）	困难（需黑名单机制）

三、Session + Cookie：单体架构下的典型方案

工作流程

【用户登录】浏览器 → POST /login ↓ Tomcat 执行 request.getSession() ↓ Tomcat 内部创建 Session

生成 SessionID: "ABC123"
存入 ConcurrentHashMap: { "ABC123": {userId: 1, role: "ADMIN"} }
创建 Cookie: JSESSIONID=ABC123 ↓ 浏览器 ← Set-Cookie: JSESSIONID=ABC123; HttpOnly

【后续请求】浏览器 → GET /user/profile Cookie: JSESSIONID=ABC123 ↓ Tomcat 解析 Cookie → 查找 sessions.get("ABC123") → 返回用户数据

text

### 架构图

┌─────────────────────────────────────────────────┐
│ 浏览器 │
│ ┌──────────────────────────────────────────┐ │
│ │ Cookie: JSESSIONID=ABC123 │ │
│ └──────────────────────────────────────────┘ │
└─────────────────────────────────────────────────┘
│
│ 自动携带 Cookie
▼
┌─────────────────────────────────────────────────┐
│ Tomcat 服务器 │
│ ┌──────────────────────────────────────────┐ │
│ │ ConcurrentHashMap │ │
│ │ ┌──────────────────────────────────┐ │ │
│ │ │ "ABC123" → {userId: 1, role: ADMIN}│ │ │
│ │ └──────────────────────────────────┘ │ │
│ └──────────────────────────────────────────┘ │
└─────────────────────────────────────────────────┘

优点

实现简单，Tomcat/Undertow 等容器自动管理
数据安全，用户无法直接访问 Session 内容
支持主动踢人、强制下线等操作

缺点

有状态，服务器需要存储每个在线用户
分布式环境下 Session 不共享，需额外方案

四、Session + Redis：分布式架构的共享方案

当系统部署在多台服务器时，用户的请求可能被负载均衡到不同机器。Session 默认存储在各自的本地内存，导致用户登录后第二次请求落到另一台服务器时丢失会话。

解决方案：引入 Redis 作为共享 Session 存储

┌─────────────────────────────────────────────────────────┐
│ 浏览器 │
│ ┌──────────────────────────────────────────────────┐ │
│ │ Cookie: JSESSIONID=ABC123 │ │
│ └──────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
│
│ 请求可能落到任意一台服务器
▼
┌───────────────┼───────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Tomcat-1 │ │ Tomcat-2 │ │ Tomcat-3 │
│ 查 Session │ │ 查 Session │ │ 查 Session │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
└────────────────┼────────────────┘
▼
┌───────────────────────┐
│ Redis 集群 │
│ ┌──────────────────┐ │
│ │ "ABC123" → {...} │ │ ← 所有服务器共享
│ └──────────────────┘ │
└───────────────────────┘

Spring Boot 配置示例

@Configuration
@EnableRedisHttpSession  // 启用 Redis 共享 Session
public class SessionConfig {
    // 所有服务器从 Redis 读写 Session，实现共享
}

特点

解决了分布式 Session 共享问题
但仍然是有状态的——Redis 存储了会话数据
引入额外组件（Redis），增加运维复杂度
每次请求都要查 Redis，有一定性能开销

五、JWT：彻底走向无状态的分布式方案

Session + Redis 虽然解决了共享问题，但本质还是"有状态"——服务器需要依赖 Redis 存储用户状态。

JWT 则把状态从服务器转移到了客户端。

JWT 的结构

text

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.abc123xyz
       ↑                    ↑              ↑
    Header              Payload        Signature
   (元数据)            (用户信息)        (防篡改签名)

Header：声明算法和类型
Payload：存储用户信息（如 userId、role、exp 过期时间）
Signature：对前两部分签名，防止篡改

注：三段各自 Base64Url 编码，然后用 . 拼接，不是整体编码。

JWT 的工作流程

【用户登录】
浏览器 → POST /login
         ↓
       Spring Boot 验证身份 → 生成 JWT
         - Header 转 JSON → Base64Url
         - Payload 转 JSON → Base64Url  
         - 拼接后用密钥签名
         ↓
浏览器 ← { "token": "eyJhbGciOi...eyJzdWIi...abc123" }

【后续请求】
浏览器 → GET /user/profile
         Authorization: Bearer eyJhbGciOi...eyJzdWIi...abc123
         ↓
       任意服务器 → 验证签名 → 解析 Payload → 获取 userId
         - 无需查 Redis/数据库
         - 无需共享存储

分布式架构下的 JWT 优势

┌─────────────────────────────────────────────────────────┐
│                   浏览器                                │
│  ┌──────────────────────────────────────────────────┐  │
│  │  存储 JWT（localStorage / 内存 / Cookie）        │  │
│  └──────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────┘
                        │
                        │ 请求携带 JWT（请求头）
                        ▼
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│  服务器-1    │ │  服务器-2    │ │  服务器-3    │
│  验证签名    │ │  验证签名    │ │  验证签名    │
│  解析用户    │ │  解析用户    │ │  解析用户    │
└──────────────┘ └──────────────┘ └──────────────┘
        │               │               │
        └───────────────┴───────────────┘
                        │
            无需共享存储，每台服务器独立工作

为什么 JWT 适合分布式？

场景	Session + Redis	JWT
新增服务器	需要配置 Redis 连接	直接加入集群，无需额外配置
服务器重启	Redis 中 Session 仍在	无影响（服务器不存储状态）
请求处理	每次查 Redis	只做签名运算（CPU），无 I/O
扩展性	受 Redis 连接数限制	水平扩展无瓶颈

六、最佳实践：双 Token 机制

生产环境中，通常采用 Access Token（短有效期）+ Refresh Token（长有效期） 的组合方案：

text

用户登录
    ↓
签发 Access Token（15分钟有效期）→ 存在内存中
    ↓
签发 Refresh Token（7天有效期）→ 存在 HttpOnly Cookie 中
    ↓
日常请求：携带 Access Token
    ↓
Access Token 过期 → 用 Refresh Token 换新的 Access Token

Token 类型	存储位置	有效期	特点
Access Token	内存	15分钟	无状态，短命，降低泄露风险
Refresh Token	HttpOnly Cookie	7天	有状态（可撤销），用于无感刷新

这种方案结合了无状态 API 的性能优势和主动撤销的安全管控能力。

七、总结与选型建议

一句话总结

Cookie 是客户端的存储容器，Session 是服务端的有状态会话，JWT 是客户端的无状态凭证。

选型参考

应用场景	推荐方案	理由
单体应用 / 后台管理系统	Session + Cookie	实现简单，容器自动管理
分布式应用（多服务器）	Session + Redis	共享会话，保留主动控制能力
微服务 / 前后端分离	JWT	无状态，天然适合分布式
移动端 / 第三方 API	JWT	跨平台，无 Cookie 依赖
高安全要求应用	JWT + Refresh Token	短生命周期 + 可撤销

核心思考：有状态 vs 无状态

text

有状态（Session）：服务器说"我记得你"
    - 优点：数据安全、可主动撤销
    - 缺点：需要存储、分布式需共享
    
无状态（JWT）：服务器说"我不记得你，但你的凭证说明了你是谁"
    - 优点：无需存储、天然分布式友好
    - 缺点：无法主动撤销、Token 需管理

没有绝对的好坏，只有是否适合当前场景。理解三者的本质，才能在设计系统架构时做出正确的选择。