HTTP 消息

你打开浏览器开发者工具，在 Network 面板里随便点开一条请求，往往会看到一大片内容：Request URL、Request Method、Status Code、几十个请求头和响应头，下面可能还有一段 JSON。第一次看很容易产生一个误会：浏览器是不是把这么多零散信息，一项一项交给了服务器？

真实情况恰好相反。浏览器先把这些信息组织成一条有明确边界的 HTTP 请求，服务器按同一套规则读完，再返回一条 HTTP 响应。Network 面板只是把消息拆开、翻译后展示给你。它像一张整理过的快递面单，不一定等于线路上逐字节传输的样子。

理解 HTTP 消息，最有用的目标不是背下所有头字段，而是能回答四个问题：这条消息想做什么？它在访问谁？对方处理得怎么样？数据从哪里开始，到哪里结束？后端框架替你做了大量封装，但请求解析失败、状态码选错、上传内容被截断、代理与应用理解不一致时，你最终还是要回到这四个问题。

从 Network 面板读懂一轮对话

先看一个很具体的场景：用户在订单页面点击“确认收货”。前端向服务器发送请求，服务器修改订单状态，再把结果返回。用便于人阅读的 HTTP/1.1 形式表示，这轮对话大致如下。

PATCH /api/orders/8042 HTTP/1.1
Host: shop.example
Content-Type: application/json; charset=utf-8
Accept: application/json
Authorization: Bearer <访问令牌>
Content-Length: 21
 
{"status":"received"}

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: no-store
Content-Length: 43
 
{"id":8042,"status":"received","version":7}

你暂时不用管每一行的细节，只看整体分工：请求用 PATCH 表达“修改订单”，用 /api/orders/8042 指向具体目标，用若干头字段补充内容类型、可接受格式和身份凭证，最后用 JSON 消息体携带修改内容。响应先用 200 报告处理结果，再说明返回数据的格式，最后给出更新后的订单表示。

一条请求，一条响应

HTTP 的基本交互是请求与响应。客户端先发请求，服务器针对这个请求给出响应。这里的“客户端”不只指浏览器，也可能是手机应用、命令行程序、反向代理或另一个后端服务；“服务器”也可能是网关、缓存代理或真正执行业务逻辑的应用。

这解释了一个常见现象：应用日志里记录的请求，可能和浏览器最初发出的请求不完全一样。请求经过 CDN、负载均衡器和反向代理时，中间节点可以添加、删除或改写部分字段，也可以把 HTTP/2 转成 HTTP/1.1 再发给上游。HTTP 语义尽量保持不变，线路上的表示方式却可以变化。

开发者工具展示的是“解释结果”

如果连接使用 HTTP/2 或 HTTP/3，你可能在 Network 面板里看到 :method、:path、:authority、:status 这类以冒号开头的名称，也可能看到所有字段名都变成小写。它们不是 HTTP/1.1 文本起始行原样传过来的结果，而是新版协议用来承载控制信息的伪头字段。

所以，排查问题时先确认协议版本。你在面板中看到的“Headers”适合理解语义，但不能据此断定网络上一定存在一段可直接阅读的文本。这个区别等到后面比较 HTTP/1.1、HTTP/2 和 HTTP/3 时会变得很关键。

HTTP/1.1 如何划出消息边界

HTTP/1.1 最反直觉的地方不是字段多，而是它运行在连续的字节流上。TCP 不会替应用标记“这一段是请求行”“这一段是消息体”，更不会保证一次读取恰好得到一条完整请求。接收方可能先读到半行，也可能一次读到一条半消息。HTTP/1.1 必须靠自己的语法把连续字节切成结构。

一条 HTTP/1.1 消息可以概括为：

起始行 + CRLF
零个或多个字段行，每行以 CRLF 结束
一个只包含 CRLF 的空行
可选的消息体

CRLF 是回车符与换行符的组合，通常写成 \r\n。头字段后的空行不是为了美观，它明确宣布“字段区到这里结束”。少了它，接收方就不知道后面的字节究竟是新字段还是消息体。

请求行说清楚“做什么”和“对谁做”

HTTP/1.1 请求行由三部分组成，中间用空格分隔：

方法 请求目标 HTTP版本

最常见的请求目标是路径加可选查询字符串：

GET /products/42?currency=CNY HTTP/1.1

完整 URL 通常不会出现在发往源站的请求行里，因为方案和主机信息可以由连接上下文与 Host 字段补全。还有三种不那么常见但很有用的形式：代理可以接收包含完整 URL 的目标；CONNECT 建立隧道时使用 主机:端口；针对服务器整体发送 OPTIONS 时可以使用 *。

GET https://shop.example/products/42 HTTP/1.1
CONNECT service.example:443 HTTP/1.1
OPTIONS * HTTP/1.1

这里的请求目标与浏览器地址栏也不是一回事。URL 中的片段，也就是 # 后面的部分，只供客户端定位页面内部位置，不会随 HTTP 请求发送给服务器。

状态行只给出协议层结果

响应的第一行叫状态行：

HTTP版本 状态码 原因短语

例如：

HTTP/1.1 404 Not Found

真正供程序判断的是三位状态码。Not Found 这样的原因短语主要方便人阅读，可以为空，也可能被服务器换成别的文字。客户端不应该通过匹配原因短语来决定逻辑。

更重要的是，状态码描述的是这次 HTTP 请求的处理结果，不足以承载全部业务含义。同样是 409 Conflict，可能表示库存版本冲突，也可能表示用户名已被占用。具体业务信息仍应放进结构稳定的响应体。

字段行看似宽松，解析必须一致

HTTP 字段通常写成 字段名: 字段值。字段名不区分大小写，因此 Content-Type 与 content-type 表达同一个名称。冒号前不能有空白；旧式的“下一行缩进表示续行”已经废弃，不应该再生成。字段值能否用逗号合并，取决于这个字段自己的定义，不能一概而论。尤其是多个 Set-Cookie，必须保留为独立字段行，不能随手拼成一行。

为什么这些细节会和安全有关？因为一条请求经常经过多个解析器。假设前置代理把某种空白当作合法分隔，后端服务器却按另一套规则解析，双方就可能对“第一条请求在哪里结束”得出不同结论。攻击者利用这种分歧，就可能把隐藏请求夹进连接中。实际开发应使用成熟的 HTTP 实现，并让网关、代理与应用对边界规则保持一致，不要自己用字符串切割来解析原始消息。

请求方法表达的是意图

后端路由里的 GET、POST、PUT、DELETE 不是为了让 URL 看起来更像英语。它们向浏览器、缓存、代理和重试组件声明：客户端希望发生什么。组件会依据这些语义决定能否预取、能否缓存、失败后是否可以自动重试。

常见方法各自解决什么问题

“安全”不是指加密，也不是指绝对不写日志。它指客户端没有请求服务器改变资源状态。服务器处理 GET 时记录访问次数、更新监控指标，并不违背这个语义；但把“确认付款”做成一个 GET /pay 就有问题，因为浏览器预取、爬虫访问或用户刷新都可能意外触发付款。

“幂等”也不等于每次响应完全相同。它看的是多次发送相同请求后，客户端所要求的最终效果是否和发送一次相同。第一次 DELETE /files/9 可能返回 204，第二次返回 404，响应不同，但资源最终都处于“不再存在”的状态，所以 DELETE 仍是幂等方法。

幂等决定了重试的风险

想象客户端发送“创建订单”的 POST，服务器已经创建成功，但响应在网络中丢失。客户端只知道自己没收到响应，不知道服务器到底做没做。如果它直接重试，可能创建两份订单。这不是网络库能凭空判断的问题。

常见解决办法是让业务请求带上由客户端生成的唯一操作标识。服务器第一次处理后保存该标识与结果，收到同一标识时返回原结果，而不是再执行一次。这样可以给原本不保证幂等的业务操作补上一层去重能力。代价是服务端要保存去重记录、规定有效期，并处理同一标识却携带不同内容的冲突。

反过来看，PUT 的目标通常由客户端明确指定。连续两次把 /profiles/27 替换为同一份内容，预期最终状态不再继续变化，所以在响应丢失时更容易安全重试。但如果服务端把每次 PUT 都实现成“余额再加 10 元”，那只是路由名字叫 PUT，实际行为已经破坏了方法语义。

方法不单独决定消息体是否存在

初学者常记成“GET 没有请求体，POST 才有请求体”。工程实践里可以把它当作接口设计习惯，却不能当成 HTTP/1.1 的消息边界规则。请求体是否存在由消息的长度或传输编码信号决定，而不是解析器看到 GET 就直接跳过后续字节。

不过，GET 请求内容没有通用语义，很多客户端、代理和服务器也不会支持或会直接拒绝它。需要提交筛选条件时，可以使用查询参数；条件很大或结构复杂时，通常设计一个语义明确的 POST 查询端点。能在协议层发送，不代表整个链路都能可靠理解。

状态码告诉客户端下一步怎么做

状态码最省力的记法不是背数字，而是先看第一位。它把响应分成五类：1xx 表示过程中的临时信息，2xx 表示请求已经按相应语义成功处理，3xx 要求客户端结合其他字段继续行动，4xx 表示请求一侧存在问题或当前不允许处理，5xx 表示服务器一侧没能完成一个看起来可处理的请求。

成功不只一种样子

200 OK 很常见，但并不适合包办所有成功：

• 201 Created 表示新资源已经创建，通常配合 Location 告诉客户端新资源的位置。
• 202 Accepted 只表示请求已接收、准备异步处理，不表示任务最终成功。响应最好提供任务标识或查询进度的方式。
• 204 No Content 表示成功且没有响应内容，响应在字段区结束后就结束。

如果异步导出接口收到任务后立刻返回 200 和“导出成功”，用户随后却发现任务失败，问题不只是文案不准，而是协议层提前承诺了不存在的结果。换成 202，客户端就知道接下来要查询任务状态，而不是把当前响应当成最终文件。

4xx 与 5xx 的边界影响重试

下面几组状态码很容易混淆：

• 400 Bad Request：消息语法错误或请求整体无法被理解。
• 401 Unauthorized：实际意思更接近“尚未通过身份认证”，通常还要告诉客户端可用的认证方式。
• 403 Forbidden：服务器理解身份与请求，但拒绝授权。
• 404 Not Found：目标不存在，或者服务器不愿暴露它是否存在。
• 409 Conflict：请求与资源当前状态冲突，例如基于旧版本覆盖新数据。
• 422 Unprocessable Content：内容类型和语法能理解，但业务语义无法处理，例如结束日期早于开始日期。
• 429 Too Many Requests：请求频率超过限制，客户端应降低速率，并在服务端给出等待提示时遵守它。
• 500 Internal Server Error：未被更具体状态覆盖的服务器内部异常。
• 502 Bad Gateway：网关从上游拿到了无效响应。
• 503 Service Unavailable：服务暂时过载或维护，适合提示稍后再试。
• 504 Gateway Timeout：网关等待上游响应超时。

把数据库断开造成的失败返回成 400，客户端会误以为改请求就能解决；把用户参数校验失败返回成 500，重试组件又可能不断重复一个永远不会成功的请求。状态码会影响监控归因、告警、缓存与重试策略，所以它不是给前端看的装饰数字。

重定向还涉及方法是否保留

Location 告诉客户端下一站在哪里，但不同 3xx 对后续方法的处理不同。303 See Other 明确让客户端用 GET 获取另一个资源，适合表单提交后跳到结果页。307 Temporary Redirect 和 308 Permanent Redirect 要求保留原方法与请求内容，适合 API 迁移但也意味着敏感内容会被再次发送到新目标。

301 和 302 在历史实现中可能把 POST 改成 GET。如果你的接口不能接受这种不确定性，就不要只凭“永久”或“临时”挑状态码，还要明确是否允许方法变化。

头字段是沿途可读的元数据

如果说方法和状态码是对话主干，头字段就是对这次对话的补充条件。它们可以描述目标主机、身份凭证、客户端偏好、内容格式、缓存策略和连接处理方式。不要按“请求头、响应头、实体头”死背一长串名字；遇到一个字段时，先问它描述的是谁、由谁使用、能否穿过中间节点。

Host 让同一个地址托管多个站点

HTTP/1.1 请求通常只在请求行里发送路径，因此还需要 Host 指明目标主机和可选端口：

GET /docs HTTP/1.1
Host: learn.example

同一台服务器、同一个 IP 地址可以托管多个域名。服务器根据 Host 把请求路由到正确站点。缺失或无效的 Host 会让服务器无法可靠重建目标地址，正常实现应拒绝这类请求。到了 HTTP/2 和 HTTP/3，这个控制信息通常由 :authority 承担。

Accept 与 Content-Type 回答不同问题

这两个字段名字看起来像一对，方向却不同：

• Accept 表示发送方希望收到哪些媒体类型。
• Content-Type 描述本条消息实际携带内容的媒体类型。

客户端发送 Accept: application/json，服务器仍可能因为无法提供 JSON 而返回错误，也可能按接口约定返回另一种格式。服务器如果根据 Accept-Language、Accept-Encoding 等字段选择了不同表示，还要考虑用 Vary 告诉缓存：哪些请求字段会改变响应。否则缓存可能把中文版响应发给需要英文版的用户。

Content-Encoding: gzip 表示内容经过 gzip 编码，接收方需要解码后才能得到原始表示；它不等于 Transfer-Encoding。前者描述内容如何编码，通常贯穿端到端，后者描述 HTTP/1.1 某一段传输如何划分消息，代理可以在相邻连接间改变它。

缓存与条件请求是一场对账

服务器可以用 Cache-Control 说明响应能否保存、多久后需要重新确认。过期不代表缓存副本必须立刻删除，而是下次使用前通常要重新验证。no-cache 也不是“不许存”，它强调复用前要验证；真正禁止保存通常使用 no-store。

重新验证时，客户端可以带上先前收到的实体标签：

GET /assets/app.css HTTP/1.1
Host: static.example
If-None-Match: "build-9f31"

如果资源没变，服务器返回 304 Not Modified，不再传一遍内容。这样做省带宽，但多了一次往返和验证开销。对带内容哈希、文件名一变就代表内容变化的静态资源，长时间缓存更合适；对频繁变化的用户数据，短缓存或每次验证更稳妥。

逐跳字段不能原样转发到底

有些字段描述端到端语义，例如 Content-Type；有些只对当前这一段连接有效，例如由 Connection 指定的连接选项。代理在转发消息前必须识别并移除逐跳信息，再为下一段连接生成适合的新信息。

这也是为什么应用不应把任意客户端字段都当成可信事实。Authorization、Cookie 可能包含凭证；Forwarded 或某些代理添加的客户端地址字段可能影响安全判断。只有在明确的可信代理链里，应用才能接受由代理写入的身份与连接信息。使用 HTTPS 可以保护传输中的机密性和完整性，但不会自动让字段值变得可信，权限检查仍要由应用完成。

消息体的关键是类型、编码与长度

消息体本质上只是一串字节。JSON、表单、图片和压缩文件之所以能被正确解释，是因为双方事先约定了格式，并通过字段把必要信息说清楚。最常见的三个问题是：这些字节是什么类型，是否经过内容编码，以及接收方读多少字节才算结束。

Content-Length 数的是字节，不是字符

POST /api/notes HTTP/1.1
Host: api.example
Content-Type: text/plain; charset=utf-8
Content-Length: 6
 
你好

UTF-8 编码下，“你好”占 6 个字节，所以这里的长度是 6，不是字符数 2。如果程序先按字符计数再手写 Content-Length，接收方可能少读或多等。正常情况下应把长度计算交给 HTTP 库。

提前知道完整长度的好处是接收方容易分配和校验；代价是动态生成或持续流式输出时，发送方未必一开始就知道总长度。HTTP/1.1 可以用分块传输解决这个问题。

分块传输把结束位置写进数据流

下面为了看清边界，把不可见的 CRLF 明确写了出来：

HTTP/1.1 200 OK\r\n
Content-Type: text/plain\r\n
Transfer-Encoding: chunked\r\n
\r\n
5\r\n
hello\r\n
6\r\n
 world\r\n
0\r\n
\r\n

每一块前面的数字是该块字节数的十六进制表示，长度为 0 的块宣告结束。接收方去掉这些分块标记后，得到的内容仍是 hello world。分块编码解决的是 HTTP/1.1 传输边界，不是把业务数据切成数组，也不是内容压缩。

正常发送方不应同时用互相冲突的 Content-Length 与 Transfer-Encoding 描述边界。因为前置代理若相信其中一个，后端应用相信另一个，两者就会把同一串字节切成不同消息，这正是请求走私的典型根源。边界冲突不能靠“选一个看起来合理的”来修复，应直接拒绝或按协议要求规范化。

有些响应按语义就不能带内容

不能只看到 Content-Length 才判断响应体。响应是否允许有内容，还取决于请求方法和状态码：

• 对 HEAD 的响应不发送消息体，但字段可以描述对应 GET 响应原本会有的内容。
• 1xx 临时响应、204 和 304 不携带消息体。
• CONNECT 成功后的字节属于建立起来的隧道，不再是普通 HTTP 响应体。

这能解释一个看似奇怪的抓包：HEAD 响应里可能出现非零 Content-Length，连接上却没有随后到来的内容。这不是截断，它表达的是“如果你用 GET，内容原本会有多长”。

媒体类型决定怎么解析，不负责替你校验业务

Content-Type: application/json 只告诉接收方按 JSON 语法解释字节，不保证字段完整、金额合法或用户有权限。解析通常分层进行：先依据消息边界读取字节，再处理内容编码，然后按媒体类型反序列化，最后进入业务校验。把这些失败混成一个模糊的“参数错误”，会让客户端很难知道应该修语法、修字段还是重新登录。

文件上传常用 multipart/form-data。它在一个消息体中用边界字符串分隔多个部分，每个部分还可以有自己的字段和内容。好处是文本字段与文件可以一次提交；代价是解析和大小限制更复杂。服务器应限制总大小、单文件大小和部分数量，并流式写入受控位置，避免先把未知大小的上传全部塞进内存。

HTTP/2 和 HTTP/3 改了包装，没有改语义

学完 HTTP/1.1 文本格式后，很多人会担心这些知识到了 HTTP/2 就过时了。其实方法、状态码、字段和内容的语义都还在，变化主要发生在线路表示与并发传输上。

起始行变成伪头字段

HTTP/2 请求不再发送一行文本形式的请求行，而是把控制信息表示为伪头字段：

:method: GET
:scheme: https
:authority: shop.example
:path: /products/42?currency=CNY
accept: application/json

响应用 :status: 200 表达状态码，不发送 HTTP/1.1 的原因短语。伪头字段必须出现在普通字段之前，字段名在线路表示中使用小写。它们看起来像头字段，却是协议控制数据，不能随意自定义，也不能出现在尾字段中。

文本消息变成带编号的帧

HTTP/2 把字段区压缩后放进 HEADERS 等帧，把内容放进一个或多个 DATA 帧。每个帧带有流标识，同一条连接可以交错传输多个请求与响应。于是一个体积很大的图片响应不必在应用层排队挡住后面的 CSS 请求。

这不意味着“二进制天然比文本快”。真正重要的是明确的帧边界、多路复用、流量控制和字段压缩。代价是不能再用肉眼直接读取线路字节，排查问题需要理解流、帧和压缩上下文。HTTP/2 仍运行在 TCP 上；一旦 TCP 丢包，连接中的多个流可能一起等待缺失字节恢复。

HTTP/3 保留类似的 HTTP 帧和伪头字段语义，但运行在 QUIC 之上。一轮请求与响应使用自己的 QUIC 流，一个流丢包时，其他流通常还能继续推进。它使用不同的字段压缩机制来适应流之间相对独立的传输。改善延迟的同时，部署也需要服务器、网络设施与观测工具支持 QUIC，不能只改一个应用配置就假定所有链路都生效。

新版协议不再使用 HTTP/1.1 分块编码

HTTP/2 和 HTTP/3 已经有 DATA 帧长度与流结束信号，因此不使用 Transfer-Encoding: chunked。Content-Length 仍可出现，用来声明预期内容长度并帮助检查完整性，但它不再承担唯一的线路分帧职责。如果声明的长度与实际 DATA 内容总长度不一致，消息就是有问题的。

这也是理解协议版本的现实价值：同一个应用接口，在开发者工具里都显示为“请求头 + 响应头 + 内容”，底层可能分别依靠空行与长度、HTTP/2 帧或 QUIC 流来确认边界。语义相同，不代表排错方法完全相同。

用一条检查链定位消息问题

遇到接口异常时，按下面的顺序检查，通常比盯着响应体猜原因更快：

1. 确认协议版本与经过的节点。 浏览器到 CDN 可能是 HTTP/3，CDN 到源站可能是 HTTP/1.1。
2. 看控制信息。 请求方法、目标、状态码是否符合实际意图，重定向后方法有没有变化。
3. 看身份与协商字段。 凭证是否发送，Host 或 :authority 是否正确，客户端要的格式和服务器给的格式是否一致。
4. 看消息边界。 Content-Length 是否按字节计算，是否出现冲突的长度信号，响应是否属于本来就没有内容的类型。
5. 再解析内容。 先处理内容编码和字符集，再解析 JSON、表单或多部分数据，最后做业务校验。
6. 判断能否重试。 不要只看网络错误，要结合方法幂等性和业务去重设计。

把这条链走完，你看到的就不再是一堆散乱字段，而是一段有语法、有意图、有结果、有边界的对话。下一次接口明明“发出去了”却没有得到预期结果时，我们就可以继续追问：问题发生在消息本身，还是发生在承载消息的连接上？