HTTP 协议核心知识点整理

本文整理了关于 HTTP 协议演进、连接复用、队头阻塞、HTTP/3 与 QUIC、WebSocket 握手以及 Postman 工具的核心知识点，适合开发者作为技术博客阅读。

目录

1. HTTP 的每一次请求都要 TCP 握手/挥手吗？
2. HTTP/1.1 与 HTTP/2 的区别
3. HTTP 层面的队头阻塞是什么？
4. HTTP/3 彻底抛弃 TCP —— QUIC 协议详解
   • 4.1 为什么需要 HTTP/3？
   • 4.2 1‑RTT 与 0‑RTT 握手
   • 4.3 连接迁移：Connection ID
   • 4.4 QUIC 建立连接的过程
5. HTTP 状态码速查
6. WebSocket 连接建立过程

---

1. HTTP 的每一次请求都要 TCP 握手/挥手吗？

答案：不一定，取决于 HTTP 版本和连接复用策略。

• HTTP/1.0（默认短连接）：每次请求之前需要三次握手，每次响应之后需要四次挥手。
• HTTP/1.1（默认持久连接）：第一次请求前握手，之后复用同一 TCP 连接发送多个请求/响应，连接空闲超时后再关闭（挥手）。
• HTTP/2：进一步强化多路复用，通常一个 TCP 连接处理所有请求，只需一次握手和一次挥手。
• HTTP/3：底层使用 QUIC（基于 UDP），不再有 TCP 的握手/挥手过程。

现代浏览器和服务器默认都启用了连接复用，所以「每个请求都握手」已经是历史了。

2. HTTP/1.1 与 HTTP/2 的区别

以下从几个关键维度对比两个版本：

协议格式

• HTTP/1.1：基于文本（ASCII），人类可读，但解析效率较低。
• HTTP/2：采用二进制分帧，将请求/响应拆分为帧，解析更快、更精确。

多路复用

• HTTP/1.1：串行处理，一个连接同一时刻只能处理一个请求-响应（虽然支持管道，但实际禁用）。浏览器通常为每个域名建立 6～8 个并行 TCP 连接来缓解。
• HTTP/2：真正的多路复用，一个 TCP 连接内可以交错发送任意多个请求和响应，互不阻塞。

队头阻塞（HTTP 层）

• HTTP/1.1：存在。前一个响应慢会阻塞后续所有响应。
• HTTP/2：已消除。多路复用允许响应乱序返回。

头部压缩

• HTTP/1.1：无压缩，每次请求都重复发送完整头部（如 Cookie、User-Agent），冗余浪费带宽。
• HTTP/2：使用 HPACK 压缩算法，维护静态/动态字典，将常见头部编码为索引，压缩率可达 60%～90%。

服务器推送

• HTTP/1.1：不支持。客户端必须主动请求每个资源。
• HTTP/2：支持 Server Push，服务器可在响应 HTML 时主动推送相关 CSS、JS 等资源。

优先级与流量控制

• HTTP/1.1：无原生优先级机制，只能靠改变请求顺序或开多连接近似控制。
• HTTP/2：支持流的优先级（权重 1～256）和依赖关系，调度器可优先传输关键资源。

典型连接数

• HTTP/1.1：每个域名通常使用 6～8 个 TCP 连接。
• HTTP/2：一个 TCP 连接是最佳实践（多路复用减少连接开销）。

是否强制 TLS

• HTTP/1.1：不必须，但 HTTPS 常见。
• HTTP/2：规范不强制，但主流浏览器仅支持基于 TLS 的 HTTP/2（即 h2）。

核心提升总结：HTTP/2 通过多路复用、头部压缩和服务器推送，显著提升了高延迟、多资源场景下的性能，并解决了 HTTP/1.1 的队头阻塞问题。

3. HTTP 层面的队头阻塞是什么？

定义：在 HTTP/1.1 中，同一个 TCP 连接上的请求必须串行处理——前一个响应未完全返回，后一个响应就不能开始。如果第一个响应很慢，后面所有请求都被「堵住」。

类比：你点了一份需要烤 30 分钟的披萨（请求 A），随后立刻点了一杯可乐（请求 B）。服务员说：「必须等披萨做好，才能给你可乐。」这就是 HTTP/1.1 的行为。

与 TCP 队头阻塞的区别

• HTTP 队头阻塞（应用层）：由请求/响应顺序处理引起，HTTP/2 的多路复用解决了它。
• TCP 队头阻塞（传输层）：由 TCP 的有序交付特性引起（丢包后需重传），HTTP/2 依然受限于此，这也是 HTTP/3 改用 UDP 的原因。

4. HTTP/3 彻底抛弃 TCP —— QUIC 协议详解

4.1 为什么需要 HTTP/3？

• HTTP/2 仍基于 TCP，存在 TCP 队头阻塞：一个丢包会阻塞所有流。
• TCP 握手 + TLS 握手至少 2 RTT 才能发数据。
• 网络切换（如 Wi‑Fi 切 5G）会导致 TCP 连接中断。

HTTP/3 将传输层换为 QUIC（基于 UDP），解决了上述问题。

4.2 1‑RTT 与 0‑RTT 握手

• 首次访问（1‑RTT）：客户端发送第一个 Initial 包同时包含连接请求和加密参数（TLS 1.3 集成），服务器响应 Handshake 包，一次往返后即可发送应用数据。
• 再次访问（0‑RTT）：客户端缓存在之前连接中获得的 PSK（预共享密钥），在第一个数据包中直接携带加密的 HTTP 请求。服务器一边验证一边处理请求，实现「零等待」。
• ⚠️ 0‑RTT 存在重放攻击风险，因此只适用于查询等幂等操作，不应使用于支付、下单等场景。

4.3 连接迁移：Connection ID

QUIC 使用独立的 Connection ID 标识连接，而不依赖（IP + 端口）。因此当你的设备从 Wi‑Fi 切换到 5G 时，连接不会断开，视频通话不会卡顿。

4.4 QUIC 建立连接的过程

首次访问（1‑RTT 握手）

客户端                                                                      服务器
  |                                                                                    |
  | (Initial) 连接ID + TLS ClientHello                               |
  |-------------------------------------------------------------------->|
  |                                                                                    | 生成 ServerHello、证书
  | (Initial + Handshake) 连接确认 + TLS ServerHello    |
  |<---------------------------------------------------------------------|
  |                                                                                     |
  | (Handshake) 完成确认 + (1‑RTT) 应用数据                |
  |--------------------------------------------------------------------->|
  | (1‑RTT) 应用数据                                                        |
  |<---------------------------------------------------------------------|

再次访问（0‑RTT 握手）

客户端                                                                      服务器
  |                                                                                    |
  | (0‑RTT) 缓存的PSK + 加密后的HTTP请求                |
  |-------------------------------------------------------------------->|
  | 服务器一边验证 PSK，一边处理请求并返回数据      |
  |<--------------------------------------------------------------------|

关键设计：集成 TLS 1.3、专用加密帧、并行处理数据，彻底告别 TCP 的握手/挥手。

5. HTTP 状态码速查

HTTP 状态码分为五大类，每类的第一位数字表示类别。

1xx（信息性响应）

• 100 Continue：客户端可以继续发送请求体（常用于上传大文件前的确认）。
• 101 Switching Protocols：服务器同意切换协议（如 WebSocket 升级）。

2xx（成功）

• 200 OK：标准成功响应。GET 返回数据，POST 返回结果。
• 201 Created：请求成功且服务器创建了新资源（常见于 POST 提交后）。
• 202 Accepted：请求已接受，但尚未处理完成（用于异步任务）。
• 204 No Content：请求成功，但响应主体中没有内容（如 DELETE 操作成功）。

3xx（重定向）

• 301 Moved Permanently：永久重定向。资源已移动到新 URL，搜索引擎会更新索引。
• 302 Found（及 307）：临时重定向，资源暂时在另一个 URL，下次还请求原地址。
• 304 Not Modified：缓存重定向。资源未修改，请直接使用本地缓存（不返回实际内容，节省带宽）。
• 307 Temporary Redirect：与 302 类似，但明确禁止将 POST 请求改为 GET。
• 308 Permanent Redirect：与 301 类似，但保持请求方法不变。

4xx（客户端错误）

• 400 Bad Request：请求语法错误或参数格式不对，服务器无法解析。
• 401 Unauthorized：未认证，需要提供用户名/密码或 token。
• 403 Forbidden：已认证但权限不足（如普通用户访问管理员页面）。
• 404 Not Found：服务器上找不到请求的资源（最著名的状态码）。
• 405 Method Not Allowed：HTTP 方法不允许（如对只读接口使用 POST）。
• 408 Request Timeout：客户端发送请求太慢，服务器超时断开。
• 409 Conflict：请求与当前资源状态冲突（如编辑时数据已被他人修改）。
• 429 Too Many Requests：请求过于频繁，触发了限流。

5xx（服务器错误）

• 500 Internal Server Error：通用服务器内部错误，通常是代码抛出未处理的异常。
• 501 Not Implemented：服务器不支持请求的功能（如老旧服务器遇到新 HTTP 方法）。
• 502 Bad Gateway：网关或代理从上游服务器收到无效响应（常见于 Nginx 转发后端服务宕机）。
• 503 Service Unavailable：服务器暂时过载或维护中，无法处理请求。
• 504 Gateway Timeout：网关等待上游服务器响应超时（后端处理太慢）。

记忆口诀：2xx 开心，3xx 指路，4xx 你错，5xx 我错。

6. WebSocket 连接建立过程

WebSocket 通过在 HTTP 连接上进行协议升级建立长连接，流程如下：

客户端发送升级请求（HTTP GET）：

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: http://example.com

服务器响应 101 Switching Protocols：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

连接升级完成，后续通信采用 WebSocket 帧（文本/二进制/Ping/Pong）。

关闭连接：任意一方发送关闭帧（opcode=0x8），对方回复后 TCP 关闭。

安全版本 wss 先进行 TLS 握手，再在加密通道内完成上述升级过程。