前置阅读：网络-07 TCP 连接管理 本文讲 HTTP 协议本身的构成，版本演进（0.9→1.1→2）见 网络-15。

HTTP（HyperText Transfer Protocol，超文本传输协议）是一个应用层、无状态、基于请求-响应的协议。它本身不关心底层用什么传输——HTTP/1.1 和 HTTP/2 跑在 TCP 上，HTTP/3 跑在 QUIC 上，但报文的语义始终一致。

1. URL 的构成

https://user:pass@www.example.com:443/path/to/page?id=1&sort=asc#section2
└─┬─┘   └───┬───┘ └──────┬───────┘ └┬┘└─────┬────┘ └──────┬─────┘ └───┬──┘
scheme   userinfo      host        port    path         query      fragment

最后一点值得注意：#section2 这部分永远不会出现在 HTTP 请求里，它由浏览器自己处理（定位页面位置）。这也是早期单页应用用 # 做路由的原因——改变它不会触发页面请求。

2. 报文结构

HTTP 报文是纯文本的（HTTP/2 起改为二进制，但语义不变），由四部分组成：

起始行
头部字段
空行            ← 关键：这个空行标记头部结束
消息体（可选）

请求报文：

POST /api/login HTTP/1.1          ← 请求行：方法 + 路径 + 版本
Host: www.example.com             ← 头部开始
Content-Type: application/json
Content-Length: 43
User-Agent: curl/8.4.0
                                  ← 空行
{"username":"admin","password":"123"}    ← 消息体

响应报文：

HTTP/1.1 200 OK                   ← 状态行：版本 + 状态码 + 原因短语
Content-Type: application/json
Content-Length: 27
Date: Wed, 29 Jul 2026 05:00:00 GMT
                                  ← 空行
{"code":0,"msg":"success"}        ← 消息体

那个空行至关重要：HTTP 头部长度不固定，接收方靠 \r\n\r\n（连续两个换行）判断"头部到这里结束了"。这也解释了 网络-08 里提到的消息边界问题——HTTP 就是用"分隔符 + Content-Length"这套组合，在面向字节流的 TCP 上划出消息边界的。

消息体长度怎么确定？ 两种方式：

• Content-Length: 43 —— 明确告知字节数，接收方读够就停；
• Transfer-Encoding: chunked —— 分块传输，长度未知时用（如动态生成的内容、流式输出）。每块前面标注自己的长度，以一个长度为 0 的块表示结束：

HTTP/1.1 200 OK
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
0\r\n            ← 长度 0，传输结束
\r\n

两者不能同时使用。服务端在生成内容前就知道大小时用 Content-Length，否则用 chunked——大文件流式下载、SSE 流式输出都属于后者。

3. 请求方法

HTTP 定义了若干方法，核心区别在三个属性：安全性、幂等性、可缓存性。

三个概念必须分清，这是面试必考：

• 安全（Safe）：不会修改服务器状态，纯读取。注意"安全"在这里和加密、防攻击毫无关系。
• 幂等（Idempotent）：执行一次和执行 N 次的效果相同。DELETE /user/1 删一次和删十次，最终状态都是"用户 1 不存在"，所以幂等；POST /user 调用十次会创建十个用户，所以不幂等。
• 可缓存：响应能否被缓存复用。

为什么 PATCH 不幂等？ 因为它的语义是"局部更新"，而更新操作可能依赖当前值。比如 PATCH {"op":"increment","field":"count"} 每次执行都会让 count 加一。如果 PATCH 的内容是"把 name 设为 xxx"这种绝对赋值，那实际上是幂等的——但协议不保证，所以规范上归为不幂等。

幂等性的工程意义：它直接决定能不能安全重试。网络超时后，客户端不知道请求到底有没有到达服务端。GET/PUT/DELETE 可以放心重发，POST 不行——这就是为什么支付、下单这类接口需要幂等键（Idempotency-Key）：客户端生成一个唯一 ID，服务端据此去重，把不幂等的 POST 人为变成幂等的。

这也和 网络-17 的 0-RTT 重放风险呼应：TLS 1.3 的 early data 只允许用于幂等请求，原因完全一样。

4. GET 和 POST 的区别

这是最高频的面试题，也是错误说法最多的一题。先说流传很广但不准确的几种：

真正的核心区别是语义，以及由语义派生出的行为差异：

所以该用哪个的判断标准是语义，不是数据量或安全性：只要这个请求会改变服务器状态，就该用 POST（或 PUT/PATCH/DELETE），哪怕参数只有一个字节；只要是纯读取，就该用 GET，哪怕参数很长（真的超限了，可以改用 POST 传查询条件，这是工程妥协而非语义正确）。

一个经典的反面案例：把删除操作写成 GET /deleteUser?id=1。后果是——搜索引擎爬虫爬一遍你的页面，用户数据就被删光了。因为爬虫认为 GET 是安全的，可以随便访问。

5. 状态码

状态码由三位数字组成，首位决定类别：

记住 4xx 和 5xx 的分界（谁的锅）在排障时最实用。

5.1 常考的具体状态码

2xx 成功

3xx 重定向 —— 这组最容易混

301/302 与 307/308 的区别是重点：历史上很多浏览器在处理 301/302 时，会把原本的 POST 请求改成 GET 并丢弃 body（虽然违反规范，但已成事实标准）。这在重定向一个表单提交时会导致数据丢失。307/308 就是为了修正这个歧义而定义的——它们严格要求保留原方法和 body。

304 严格来说不是"重定向"，它属于缓存机制，只是被归在 3xx 里。它的响应没有 body，告诉浏览器"你缓存的版本还能用"。

4xx 客户端错误

401 vs 403 是高频考点：401 是"没带身份"或"身份无效"（该返回 WWW-Authenticate 头引导认证），403 是"身份有效但权限不够"。搞反了会让客户端做出错误的重试决策——遇到 401 应该去刷新 token 重试，遇到 403 重试多少次都没用。

5xx 服务端错误

502 / 503 / 504 的区分是运维排障基本功：

• 502 → 后端没有正常应答（进程崩溃、端口没监听、返回了非法响应）。查后端进程是否存活、Nginx 的 upstream 配置是否指对。
• 504 → 后端活着但没在超时时间内答完。查慢查询、慢接口，或调 proxy_read_timeout。
• 503 → 通常是服务自己主动拒绝（限流、熔断、健康检查失败、优雅关闭中）。

一个记忆方式：502 是"上游给了我垃圾"，504 是"上游让我等太久"，503 是"我自己现在不干活"。

6. 常见头部字段

头部字段按作用可分四类：

通用头（请求响应都可用）

请求头

响应头

Host 头为什么是 HTTP/1.1 的重大改进？ 因为 TCP 连接只知道 IP 和端口，一台服务器上如果用同一个 IP 托管多个域名，服务端无法判断请求要访问哪个站点。有了 Host 头，虚拟主机（Virtual Host）才成为可能——这是共享主机和现代反向代理的基础。HTTP/1.0 没有它，所以一个 IP 只能放一个站点。

7. 用 curl 观察

# -v 看完整的请求和响应头（> 是发出的，< 是收到的）
curl -v https://example.com

# -I 只发 HEAD 请求，只看响应头
curl -I https://example.com

# 看重定向链路：-L 跟随跳转，观察每一跳的状态码
curl -sIL http://github.com | grep -E "^HTTP|^location"

# 自定义方法和头部
curl -X PATCH -H "Content-Type: application/json" \
     -d '{"name":"new"}' https://api.example.com/user/1

# 只输出状态码，适合写健康检查脚本
curl -s -o /dev/null -w "%{http_code}\n" https://example.com

# 看各阶段耗时，排查慢请求到底慢在哪
curl -s -o /dev/null -w "DNS:%{time_namelookup}s 连接:%{time_connect}s TLS:%{time_appconnect}s 首字节:%{time_starttransfer}s 总计:%{time_total}s\n" https://example.com

最后那条在排查性能问题时特别有用——它能直接告诉你时间花在 DNS、TCP 握手、TLS 握手还是服务端处理上。

8. 本章面试题