1.1 无状态的定义#

HTTP 的无状态性是指：服务器不会保留与客户端交互的任何状态上下文。每个请求都是完全独立的，服务器无法知道两个请求是否来自同一个客户端，也无法知道它们之间的关联。

RFC 7230 对 HTTP 无状态性的定义：

The HTTP protocol is a stateless request/response protocol.

1.2 有状态 vs 无状态的对比#

1.3 HTTP 请求的独立性#

每个 HTTP 请求必须包含服务器处理该请求所需的所有信息：

1
GET /api/user/profile HTTP/1.1
2
Host: example.com
3
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
4
Accept: application/json

服务器不需要记住「这个用户是谁」，因为每个请求都会携带认证信息。

2.1 简单性原则#

1991 年，Tim Berners-Lee 在 CERN 设计 HTTP 时，目标是创建一个极其简单的协议来传输超文本文档。

简单性带来的好处：

2.2 可扩展性考量#

无状态设计天然支持水平扩展：

如果 HTTP 是有状态的，扩展会变得极其困难：

2.3 早期 Web 的需求#

1990 年代的 Web 主要是静态文档的获取：

当时的典型场景：

• 浏览论文和文档
• 获取静态页面
• 没有登录、购物车等交互需求

无状态设计完全满足这些需求，而且实现最简单。

3.1 水平扩展能力#

无状态是微服务架构的基石：

有状态架构的扩展困境：

3.2 缓存友好#

无状态使得缓存策略简单有效：

HTTP 缓存机制依赖于无状态性：

1
HTTP/1.1 200 OK
2
Cache-Control: max-age=3600, public
3
ETag: "abc123"
4
Last-Modified: Sun, 22 Mar 2026 15:00:00 GMT

3.3 可靠性提升#

无状态设计提高了系统的容错能力：

3.4 调试简单#

无状态请求天然可重现：

1
# 无状态请求，任何时间、任何地点都能重现
2
curl -X GET "https://api.example.com/users/123" \
3
  -H "Authorization: Bearer token123"
4

5
# 有状态请求需要重现整个会话上下文（非常困难）

4.1 会话管理的复杂性#

Web 应用需要记住用户状态，但 HTTP 不提供这种能力。开发者必须在应用层实现会话管理：

4.2 每次请求携带完整信息#

无状态意味着每个请求都要携带认证信息：

4.3 服务器端状态存储压力#

虽然协议无状态，但业务需要状态，压力转移到服务器：

5.1 Cookie 的发明#

1994 年，Netscape 的 Lou Montulli 发明了 Cookie，解决了 HTTP 无状态带来的用户识别问题：

5.2 Session 机制#

Session 将状态存储在服务器，Cookie 只存储标识符：

5.3 Cookie 的安全属性#

现代 Cookie 机制提供了多层安全保护：

1
Set-Cookie: session_id=abc123;
2
    HttpOnly;           # JavaScript 无法访问，防 XSS
3
    Secure;             # 仅 HTTPS 传输
4
    SameSite=Strict;    # 防 CSRF 攻击
5
    Path=/;             # 作用路径
6
    Domain=example.com; # 作用域
7
    Max-Age=3600        # 过期时间

5.4 Session 存储的演进#

6.1 JWT 的结构#

JSON Web Token 将状态编码在 Token 本身，实现了「无状态认证」：

1
JWT 结构: Header.Payload.Signature
2

3
Header:    {"alg": "HS256", "typ": "JWT"}
4
Payload:   {"sub": "user123", "name": "张三", "exp": 1711123200}
5
Signature: HMACSHA256(base64(Header) + "." + base64(Payload), secret)

6.2 JWT 的工作流程#

6.3 Session vs JWT 对比#

6.4 JWT 的问题#

JWT 并非完美解决方案：

7.1 FTP 协议#

FTP 是典型的有状态协议，使用独立的控制和数据连接：

FTP 的有状态特性：

7.2 SMTP 协议#

SMTP 同样维护会话状态：

7.3 为什么这些协议需要状态？#

7.4 有状态协议的代价#

8.1 REST 的无状态约束#

REST 架构风格明确要求无状态（Stateless）约束：

Roy Fielding 在论文中强调：

Each request from client to server must contain all of the information necessary to understand the request.

8.2 RESTful API 的无状态设计#

8.3 违反无状态的设计#

常见的反模式：

正确的 RESTful 设计应该让客户端维护状态：

8.4 HATEOAS 与无状态#

HATEOAS（Hypermedia as the Engine of Application State）是 REST 的高级约束：

1
{
2
  "id": 123,
3
  "status": "pending",
4
  "items": [...],
5
  "_links": {
6
    "self": { "href": "/orders/123" },
7
    "cancel": { "href": "/orders/123/cancel", "method": "POST" },
8
    "pay": { "href": "/orders/123/payment", "method": "POST" }
9
  }
10
}

服务器通过响应告诉客户端可以做什么，而不是客户端需要记住状态。

9.1 HTTP/2 的连接复用#

HTTP/2 引入了多路复用，但协议层面仍是无状态的：

9.2 HTTP/2 的状态特性#

虽然 HTTP/2 引入了连接级别的状态（如流量控制窗口），但这些是传输层的优化，不影响应用层的无状态语义：

9.3 HTTP/3 与 QUIC#

HTTP/3 使用 QUIC 传输协议，同样保持无状态语义：

QUIC 的 0-RTT 特性减少了连接建立延迟，但不会改变 HTTP 的无状态本质。

9.4 HTTP/2 头部压缩的状态性#

HPACK 是 HTTP/2 中唯一引入状态的部分：

但这是传输优化，应用层逻辑仍然是无状态的。

10.1 状态分层架构#

现代 Web 应用采用分层的状态管理策略：

10.2 分布式会话方案#

10.3 无状态服务的设计模式#

10.4 实际架构示例#

一个典型的现代 Web 应用状态管理：

11.1 无状态设计的本质#

HTTP 的无状态设计是一个深思熟虑的工程决策：

11.2 设计权衡总结#

11.3 最佳实践#

11.4 最终思考#

HTTP 的无状态设计体现了互联网架构的核心理念：简单性优于完备性。正是因为无状态，HTTP 才能成为支撑全球规模 Web 应用的协议。理解无状态的权衡，才能更好地设计现代 Web 应用。

「无状态」不是缺陷，而是特性。关键在于如何在应用层妥善处理状态管理。