1. JWT 基础概念
1.1 JWT 定义
JWT（JSON Web Token） 是一种基于 JSON 格式的开放标准（RFC 7519），用于在各方之间以紧凑且自包含的方式安全传输信息。JWT 通常用于身份认证和信息交换，其核心特点是：
- 自包含：Token 本身携带用户身份、权限等声明信息，无需服务端存储会话状态。
- 紧凑：通过 Base64URL 编码，体积小，适合 HTTP 头部、URL 参数等传输场景。
- 防篡改：通过签名机制（HMAC 或 RSA/ECDSA）保证数据完整性。
压测视角：JWT 的无状态特性使其在分布式压测场景中天然具备高可扩展性，但签名验证的计算开销会成为性能瓶颈，需重点关注。
1.2 JWT 结构详解
一个完整的 JWT 由三部分组成，以点号（.）分隔：Header.Payload.Signature。以下通过 SVG 结构图展示其组成关系：
1.3 三部分详细说明
1.3.1 Header（头部）
Header 通常包含两部分信息：Token 类型（typ）和签名算法（alg）。示例：
{
"alg": "HS256",
"typ": "JWT"
}| 字段 | 含义 | 常见值 |
|---|---|---|
| alg | 签名算法 | HS256、RS256、ES256 |
| typ | Token 类型 | JWT |
| kid | 密钥 ID（可选） | 用于多密钥场景 |
1.3.2 Payload（载荷）
Payload 包含声明（Claims），分为三类：
- 注册声明（Registered Claims）：预定义的标准字段，如
iss（签发者）、sub（主题）、exp（过期时间）、iat（签发时间）。 - 公共声明（Public Claims）：自定义字段，需在 IANA JSON Web Token Registry 注册或使用命名空间避免冲突。
- 私有声明（Private Claims）：双方约定的自定义字段，如
userId、role。
{
"sub": "1234567890",
"name": "John Doe",
"role": "admin",
"iat": 1516239022,
"exp": 1516242622
}
压测注意：Payload 体积直接影响 JWT 大小和网络传输开销。压测时应控制自定义声明数量，避免 Token 过大导致带宽和解析性能下降。
1.3.3 Signature（签名）
签名由 Header 指定的算法生成，用于验证 Token 在传输过程中未被篡改。生成过程：
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret
)服务端验证时，使用相同的密钥和算法重新计算签名，与 Token 中的签名比对。若不一致，则拒绝请求。
1.4 JWT 与 Session 对比
在压测场景中，选择 JWT 还是 Session 直接影响测试架构设计。以下从多个维度进行对比：
| 对比维度 | JWT | Session |
|---|---|---|
| 状态存储 | 无状态，Token 自包含用户信息 | 有状态，服务端存储 Session 数据 |
| 扩展性 | 天然支持分布式，无需共享存储 | 需 Redis/DB 等共享存储，增加复杂度 |
| 性能开销 | 签名验证计算开销（CPU 密集型） | Session 查询开销（IO 密集型） |
| 安全性 | 签名防篡改，但 Payload 仅 Base64 编码（非加密） | Session ID 随机生成，数据存储在服务端 |
| 跨域支持 | 天然支持跨域（CORS） | 需额外配置跨域 Session 共享 |
| Token 大小 | 较大（通常 200-500 字节） | Session ID 很小（通常 16-32 字节） |
| 吊销机制 | 需黑名单或短过期时间 | 直接删除服务端 Session 即可 |
以下 SVG 图展示 JWT 与 Session 在典型请求流程中的差异：
1.5 压测场景选择建议
选择 JWT 的场景：
- 微服务架构，需要无状态认证
- 移动端或跨域 API 服务
- 高并发分布式部署，避免 Session 共享瓶颈
选择 Session 的场景：
- 单体应用，服务端可快速访问 Session 存储
- 需要服务端主动吊销用户会话
- Token 大小敏感的低带宽环境