故小里HTTP/3正式成为IETF RFC 9114标准已经有一段时间了，但直到今天，我身边能把Headers（请求头和响应头）在HTTP/3里的变化讲清楚的人依然不多。很多人一听HTTP/3，第一反应就是“比HTTP/2快一点”，再问就说不清到底哪里变了。但只要你打开RFC 9114，或者用Wireshark抓一个QUIC流上的HEADERS帧，你会发现事情远没有这么简单：头部压缩协议从HPACK换成了QPACK，请求行被拆散成伪头字段，Connection这类连接级字段被彻底禁用，甚至头部数据的抵达顺序都变得“不可预测”。
这篇文章我会围绕HTTP/3协议里的Headers体系展开，把RFC 9114规定的帧结构、伪头字段、QPACK压缩机制逐层拆开讲，顺手把日常调试中几个和请求头、响应头强相关的经典问题——比如Docker拉镜像时的awaiting headers超时、Chrome里provisional headers are shown的困惑、Apifox怎么设置全局请求头——一并梳理清楚。不管你是后端开发、运维、测试，还是需要排查接口问题的前端，只要工作里离不开HTTP，这篇都值得花十分钟看完。
1. HTTP/3不是换了一层连接层：RFC 9114到底改了什么
1.1 TCP的队头阻塞，是HTTP/3出现的直接导火索
要理解HTTP/3里的Headers为什么长得和之前不一样，得先理解HTTP/3为什么存在。HTTP/1.1时代，一条TCP连接同一时间只能处理一个请求，一个慢接口能堵住后面所有请求，所以才有了HTTP/2的多路复用——把多个请求并发塞进同一条TCP连接。
但HTTP/2只解决了HTTP层的并发，没解决TCP层的老毛病。TCP为了保证数据完整，会给每个包编号并要求按序交付。一旦某个包丢失，接收方必须等待重传，哪怕后面所有的包都已经到了，也得在缓冲区里排队干等。这就是TCP层的队头阻塞（Head-of-Line Blocking）。在弱网、高丢包的移动网络环境下，这个问题的杀伤力非常大：某个Stream丢一个包，同一条连接上的其他Stream全部遭殃，延迟可能直接从几十毫秒飙升到几秒。
QUIC就是冲着这个痛点来的。它把传输层整个换掉，基于UDP重新实现了可靠传输、拥塞控制和多路复用。每个Stream独立编号、独立重传、独立排序，一个Stream丢包不会影响其他Stream。HTTP/3则是跑在QUIC之上的HTTP语义层。换句话说，HTTP/3不是“HTTP/2加个协议头”，而是整条技术栈里传输层发生了根本性变化，HTTP层所有依赖传输层顺序性的机制，都必须重新设计。
1.2 RFC 9114到底管了什么
RFC 9114是IETF在2022年6月正式发布的HTTP/3标准，它的角色非常明确：描述HTTP语义如何通过QUIC传输。这里有两个容易混淆的点。
第一，RFC 9114不负责QUIC传输层本身，那是RFC 9000系列的范围。你去看RFC 9114的正文，里面几乎不讨论拥塞控制、丢包重传、连接迁移这些底层细节，它讨论的是HTTP这一层怎么在QUIC的流（Stream）上组织数据。
第二，HTTP语义本身也不是RFC 9114定义的，而是RFC 9110（HTTP Semantics）定义的。RFC 9114要做的事情，是把HTTP/1.1里通过请求行、响应行、请求头、响应头表达的信息，重新映射到QUIC流上的帧结构里。
这个分层关系很重要。我见过不少人在排查HTTP/3问题时，拿着HTTP/1.1时代的请求头、响应头经验硬套，结果越查越糊涂。正确的姿势是时刻记住：HTTP语义是“干什么”，QUIC是“怎么传”，RFC 9114夹在中间，负责把语义翻译成帧和流。
1.3 HTTP/3对Headers的影响，集中在这三块
具体到请求头和响应头，RFC 9114带来的变化可以归纳为三个层面。
第一个层面是头部压缩协议换血。HTTP/2用的HPACK依赖TCP的有序传输，HTTP/3的QUIC流会乱序到达，HPACK没法直接用，于是有了QPACK。这是对Headers影响最深远的一项变化，后面的章节会展开讲。
第二个层面是请求行和状态行被拆成了伪头字段。HTTP/1.1里GET /index.html HTTP/1.1是一行独立的文本，HTTP/2和HTTP/3里它被拆成:method、:scheme、:path、:authority四个伪头字段，响应行的状态码变成:status伪头字段。
第三个层面是帧承载方式变了。HTTP/3里所有数据都装在帧（Frame）里，请求头只能作为HEADERS帧出现在客户端发起的双向流上，不能再像HTTP/1.1那样随意换行发文本。字段的顺序、是否允许分片、伪头字段的位置，都有严格的协议要求。
这三点加起来，意味着“Headers”在HTTP/3里不再是我们熟悉的键值对文本堆叠，而是一套有严格规则的二进制帧结构。理解了这一点，后面看QPACK、看伪头字段、看抓包结果，就不会懵了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. QPACK：因为乱序，头部压缩协议被迫整个重写
2.1 HPACK为什么不能直接搬到HTTP/3
HTTP/2的头部压缩协议HPACK（RFC 7541）核心有三张表：静态表、动态表、Huffman编码。静态表里放了61个高频字段，比如:method: GET、:scheme: https、content-type: application/json这类，发送方只要发一个数字索引就能代表一整个字段。动态表记录的是连接建立后出现过的自定义字段，后续报文可以引用之前的索引，起到增量压缩的作用。
这套机制本身很高效，但它有一个隐含前提：双方必须严格按照顺序处理头部块。动态表