HTTP 报文的结构是怎样的？

简化版

HTTP 报文分请求报文和响应报文，结构都是三部分：起始行 + 首部（headers）+ 空行 + 消息体（body）。请求报文起始行是「方法 + URL + 版本」（如 GET /index HTTP/1.1）；响应报文起始行是「版本 + 状态码 + 短语」（如 HTTP/1.1 200 OK）。首部和消息体之间用一个空行分隔——这是解析报文的关键分界。

详细版

请求报文结构：

GET /api/user?id=1 HTTP/1.1        ← 请求行：方法 + 路径 + 版本
Host: example.com                  ← 请求头（键值对，多行）
User-Agent: Mozilla/5.0
Accept: application/json
Content-Type: application/json
                                   ← 空行（分隔头和体）
{"name": "Tom"}                    ← 请求体（GET 通常无，POST/PUT 有）

响应报文结构：

HTTP/1.1 200 OK                    ← 状态行：版本 + 状态码 + 原因短语
Content-Type: application/json     ← 响应头
Content-Length: 27
Set-Cookie: session=abc
                                   ← 空行
{"code": 0, "data": {...}}         ← 响应体

三部分：

起始行：请求行（方法/URL/版本）或状态行（版本/状态码/短语）；
首部 headers：一堆 Key: Value，描述元信息（内容类型、长度、缓存、Cookie 等）；
空行 + 消息体：空行标志首部结束，之后是实际数据（JSON、HTML、文件等）。

完整版教学

一、三段式结构：起始行、首部、消息体

无论请求还是响应，HTTP 报文都是同一个三段式骨架：

起始行：一行，说明「这是什么请求/响应」——请求方是「要对谁做什么」（方法+URL），响应方是「结果如何」（状态码）；
首部：任意多行键值对，是报文的「元信息」——告诉对方内容类型、长度、编码、缓存策略、Cookie 等；
消息体：真正要传的数据。

抓住这个骨架，看任何 HTTP 报文都不会乱。

二、那个「空行」为什么至关重要

首部和消息体之间的空行（\r\n\r\n） 是解析报文的关键分界：

HTTP 首部行数不固定，接收方怎么知道首部到哪结束、body 从哪开始？——就靠这个空行；
读到一个空行，就意味着「首部结束了，后面全是消息体」。

所以 HTTP 报文用「空行」划分头和体。而 body 有多长，则由 Content-Length（明确长度）或 Transfer-Encoding: chunked（分块传输，边生成边发）来告诉接收方——这也和 TCP 粘包问题相关：HTTP 正是用「首部里的长度信息 + 空行分界」在字节流上划出一条条完整报文的（详见「TCP 粘包和拆包」那道题）。

三、常见的请求头

Host：目标主机（HTTP/1.1 必带，支持一台服务器托管多域名）；
User-Agent：客户端标识（浏览器/App 类型）；
Accept / Accept-Encoding / Accept-Language：客户端能接受的内容类型、压缩方式、语言；
Content-Type：请求体的格式（application/json、application/x-www-form-urlencoded、multipart/form-data）；
Content-Length：请求体字节数；
Cookie：带上服务器之前种下的 Cookie；
Authorization：认证凭证（如 Bearer <token>）。

四、常见的响应头

Content-Type：响应体格式；
Content-Length / Transfer-Encoding：响应体长度 / 分块传输；
Content-Encoding：响应体的压缩方式（gzip、br）；
Cache-Control / ETag / Last-Modified：缓存策略（详见「HTTP 缓存」那道题）；
Set-Cookie：让浏览器保存 Cookie；
Location：重定向的目标地址（配合 3xx）；
Access-Control-Allow-Origin：CORS 允许的源（详见「同源策略与跨域」那道题）。

五、常见误区

❌ 以为请求行是「请求头」的一部分——起始行（请求行/状态行）是独立的第一行，和首部分开。
❌ 忽略空行的作用——空行是首部与消息体的分界，解析报文靠它。
❌ 以为 GET 不能有 body——协议不禁止，但语义上不推荐，多数服务器会忽略 GET 的 body。
❌ 把 Content-Type 和 Accept 搞混——Content-Type 描述「我发的是什么格式」，Accept 声明「我能接收什么格式」。

六、常见误区与追问

考点	正确口径
请求报文	请求行、请求头、空行、请求体
响应报文	状态行、响应头、空行、响应体
空行	分隔头部和 body 的边界

GET /index.html HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html

<html>...</html>

HTTP 报文的空行不是装饰，它告诉解析器头部到此结束。

误区：HTTP 报文只有 header 和 body。 请求/状态起始行也很关键，包含方法、路径、版本或状态码。
误区：GET 请求一定没有 body。 语义上不推荐，但报文结构允许消息体，实际兼容性不佳。
误区：Content-Length 可有可无。 对于带 body 的非 chunked 报文，长度信息决定接收端如何判断 body 边界。
追问：Host 头为什么重要？ 同一 IP 可承载多个域名，HTTP/1.1 要靠 Host 区分虚拟主机。
追问：chunked 解决什么？ 响应长度事先未知时，可分块发送并用块结束标记表示 body 完结。
追问：HTTP/2 还有文本报文吗？ HTTP/2 改为二进制帧，但语义上的方法、头部、状态码仍存在。

七、加强记忆

HTTP 报文三段式：起始行（请求行：方法+URL+版本 / 状态行：版本+状态码+短语）+ 首部（键值对元信息）+ 空行 + 消息体。空行是首部与消息体的关键分界，body 长度由 Content-Length 或 chunked 说明。常见头：请求侧 Host/User-Agent/Content-Type/Cookie/Authorization，响应侧 Content-Type/Set-Cookie/Location/Cache-Control。

简化版

详细版