HTTP 无状态 :底层原理、完整执行流程、数据结构、安全机制、优缺点、适用场景
HTTP 是无状态协议：服务器不记忆任何用户信息，请求之间毫无关联。→ 无法实现：登录、购物车、个人中心、权限校验。
所以：必须给 HTTP 强行 “加状态” 这就是 Cookie、Session、Token、JWT 诞生的根本原因
后续状态指的是什么意思:
在Web 身份认证 / 服务端会话这个语境下，「状态」特指：
服务端需要主动存储、维护的「用户会话信息」（比如用户 ID、登录状态、权限、会话有效期等），用来识别和关联同一个用户的多次请求。
关键区分：
- 有状态（Stateful） ：服务端必须在本地存储用户的会话数据，每次请求都要从存储中查询、校验这个状态，才能识别用户。
- 无状态（Stateless） ：服务端不需要存储任何用户会话数据，所有身份信息都由客户端在请求中携带，服务端只需要验证信息的合法性，就能识别用户，不依赖本地存储。
一、Cookie：浏览器的 “存储小盒子”（原理 + 细节）
1. 官方定义
Cookie 是服务器通过响应头种植、浏览器自动存储、自动携带的键值对文本数据。它不是认证方案，它是存储载体。
2. 底层原理（HTTP 头工作流程）
第 1 步：服务器下发 Cookie
登录成功后，服务器在响应头里加：
Set-Cookie: userId=123; Expires=xxx; HttpOnly; Secure; SameSite
浏览器自动解析并保存到本地。
第 2 步：浏览器自动携带 Cookie
下次请求同一域名时，请求头自动带上：
Cookie: userId=123
全程无需代码干预。
3. Cookie 核心属性（决定安全与行为）
| 属性 | 作用 |
|---|---|
Expires/Max-Age | 过期时间 |
HttpOnly | 禁止 JS 读取，防 XSS 窃取 |
Secure | 仅 HTTPS 传输 |
SameSite | 防 CSRF 跨站攻击 |
4. 本质局限
- 大小限制 4KB
- 纯文本，可篡改
- 不能存敏感信息（密码、身份证）
- 浏览器专属，APP 不支持
二、Session：服务器的 “会话账本”（原理 + 流程）
1. 一句话原理
Session = 服务器内存 / 缓存中的用户数据 Cookie = 存 SessionID（钥匙）
Session 是有状态认证。
2. 完整执行流程（最经典的 Web 登录）
① 登录请求
用户输入账号密码 → 后端验证成功
② 服务器创建 Session
生成唯一 SessionID：sess_abc123
服务器存储：
sess_abc123 → { userId: 1, username: "张三", login: true }
③ 服务器把 SessionID 写入 Cookie
Set-Cookie: JSESSIONID=sess_abc123; HttpOnly
④ 后续请求
浏览器自动携带 Cookie：
Cookie: JSESSIONID=sess_abc123
⑤ 服务器验证
服务器根据 sess_abc123 查存储 → 拿到用户信息 → 认证通过。
3. Session 底层原理
- Session 存储：内存、Redis、数据库
- SessionID：随机字符串（无法猜测）
- 依赖 Cookie：没有 Cookie，Session 几乎无法工作
4. Session 致命缺点
- 服务器有状态 → 无法随便扩容
- 分布式 / 集群必须共享 Session（Redis 方案）
- 跨域极难（Cookie 不支持跨域）
- APP 不友好（APP 没有浏览器 Cookie 机制）
三、Token：通用 “加密身份凭证”
1. 核心思想
服务器不存储任何用户状态 → 彻底无状态
Token = 服务器签发的身份字符串
2. 与 Session 最大区别
- Session：服务器存数据 → 查库验证
- Token：服务器不存数据 → 解密 / 验签验证
3. Token 工作流程
① 登录成功
服务器生成 Token：
token = encrypt(用户信息 + 过期时间 + 签名)
② 返回给前端
前端自己存储：
- localStorage
- cookie
- vuex/react state
③ 后续请求（手动携带）
前端在请求头里手动加：
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
④ 服务器验证
解密 / 验签 → 合法 → 通过
4. Token 优点
- 无状态，服务器零存储
- 天然支持分布式、微服务
- 跨域友好
- 支持 APP、小程序、Web 全端
四、JWT：Token 的标准实现（最详细原理）
1. 官方全称
JSON Web Token它是一套标准化的 Token 格式，不是新技术。
2. JWT 核心特点
自包含 + 防篡改 + 跨语言
3. JWT 数据结构（三段式。分割）
Header.Payload.Signature
① Header（头部）
声明加密算法，默认 HS256
{
"alg": "HS256",
"typ": "JWT"
}
② Payload（负载）
存放用户数据（不加密！仅编码）
{
"sub": "1",
"name": "张三",
"exp": 1735689600
}
Payload 可以被任何人解码，绝对不能存密码！
③ Signature（签名）【核心安全】
Signature = HMACSHA256(
Base64(Header) + "." + Base64(Payload),
密钥 (SecretKey)
)
作用：防止篡改只要内容被改，签名立刻失效。
4. JWT 验证原理（超级重要）
- 前端传 JWT
- 后端拆分出 Header.Payload.Signature
- 用同样密钥重新计算签名
- 对比新签名 vs 旧签名
- 一致 → 未篡改，可信
- 不一致 → 伪造，拒绝
5. JWT 优点
- 无存储、无状态
- 跨语言、跨平台
- 微服务、前后端分离首选
- 不依赖 Cookie
6. JWT 缺点（必须知道）
- 无法主动作废未过期的 JWT 永远有效，想拉黑只能加黑名单（Redis）
- Payload 可解码敏感信息禁止放入
- 体积比 SessionID 大
五、终极对比：4 者本质关系（彻底懂）
一句话总结
- Cookie：浏览器存储工具
- Session：服务端存储状态（依赖 Cookie）
- Token：无状态身份凭证
- JWT：Token 的标准格式
最清晰的层级关系
plaintext
HTTP 无状态
↓
Cookie（存储）
↓
Session（基于 Cookie 的服务端状态）
↓
Token（无状态、跨平台）
↓
JWT（标准 Token）
核心区别表
| 维度 | Cookie | Session | Token | JWT |
|---|---|---|---|---|
| 存储位置 | 客户端 | 服务端 | 客户端 | 客户端 |
| 服务端存储 | 无 | 有 | 无 | 无 |
| 传输方式 | 自动 | 自动 | 手动 | 手动 |
| 跨域 | 不支持 | 不支持 | 支持 | 支持 |
| 分布式 | 不支持 | 需共享 | 天然支持 | 天然支持 |
| 安全性 | 中 | 高 | 高 | 高 |
| 适用端 | Web | Web | 全端 | 全端 |
六、实战选择指南（工作中怎么选？）
1. 传统 Web 项目（不分离）
Session + Cookie最简单、最安全。
2. 前后端分离 / 微服务 / 小程序 / APP
JWT行业标准方案。
3. 超高安全需求（金融、支付）
JWT + 黑名单 + 短过期 + HTTPS
Q1：Session 为什么不适合分布式？
因为状态存在服务器本地，其他服务器查不到。
Q2：JWT 为什么安全？
因为签名无法伪造，内容一改就失效。
Q3：Cookie 被禁用了怎么办？
Session 会失效，但 JWT 不受影响。
Q4：JWT 能存密码吗？
绝对不能，因为 Payload 可解码。
Q5：JWT 泄露了怎么办？
没办法，只能等过期或拉黑。
