摘要

  • Mark Nottingham 提议使用“HTTP/3”，让人看出这是把 HTTP 语义映射到 QUIC 之上的 HTTP 协议，而不是 QUIC 传输本身。
  • 他把名称与维护安排连在一起：发布后，HTTP/3 和 QPACK 应转由 HTTP 工作组维护。IETF 后来的工作组章程记录了这项分工。
  • 这条边界说明由谁作决定、谁维护文本；它不保证代码兼容或实际部署，也不意味着 Nottingham 一个人决定了名称或标准。

到 2018 年末，“QUIC”这个词承载着两个不同对象：一是传输协议，二是运行在该传输之上的 HTTP 映射。对没有持续跟进项目的人而言，两者容易被混为一谈。问题不只是名称不够清楚；如果传输与应用协议看起来像同一个交付物，未来的规范、维护和责任也会落到哪个工作组，就更难判断。

10 月 28 日，Mark Nottingham 向 QUIC 工作组邮件列表提出，把 HTTP 文档称为“HTTP/3”，并把 h3 作为最终 ALPN 标识。他解释说，这个名称可以表明 HTTP 语义通过一种线路协议绑定方式运行，类似 HTTP/2；这样便能看出它与 QUIC 传输不是同一层。这个理由直接保存在他发给工作组的邮件中。

邮件中还有第二项建议：HTTP 映射发布后，HTTP/3 和 QPACK 的维护应转交 HTTP 工作组。文档在哪个小组内编写，与由哪个小组长期维护，并不是同一个问题。QUIC 工作组有理由先完成依赖 QUIC 设计的 HTTP 映射；之后，涉及 HTTP 核心语义和扩展的决定，应由负责 HTTP 的社区承接。名称解决的是“这份文档是什么”，维护转交解决的是“以后谁对它负责”。

会议记录把支持与决定权分开

在 IETF 103 会议上，QUIC 工作组讨论了这个名称。纪要呈现了不同判断：有人认为 HTTP/3 表示 HTTP/2 的后继版本，也有人担心新名称暗示协议发生分叉。Nottingham 提醒，与 HTTP/1.1 相比，HTTP/2 并没有将其废弃或取代。他强调的区别是语义与线路协议之间的区别。

纪要记录的是一次非正式的“哼声”征询，并非正式表决。支持更名的比例约为 70 比 30；几乎所有与会者都支持让 HTTPbis 决定名称。后一项信号更能说明职责边界：工作虽然产生于 QUIC 组的工作中，但 HTTP 版本如何命名应由 HTTP 社区决定。Nottingham 在会议上明确表示，HTTP 的命名应留在 HTTP 社区内。

他在 10 月的邮件中还标注了“Chair hat”，提出只为此留出有限讨论时间。他希望开发者和使用者能听懂新协议的定位，同时避免命名争论挤占技术议程。主席可以限定议题、安排时间，却不能以个人意见代替工作组共识。把这两个角色分开，是理解邮件分量的关键。

名称只有在层次清楚时才有意义

后来发布的规范保留了这一层次关系。RFC 9114 将 HTTP/3 定义为 HTTP 语义在 QUIC 上的映射；RFC 9110 描述 HTTP 语义，RFC 9000 定义 QUIC 传输。HTTP/3 使用 QUIC 每条流的可靠、有序交付以及传输安全能力，同时保留 HTTP 消息和应用层含义。HTTP/3 的名称标识映射关系，并没有把两层合成一种协议。

ALPN 中的 h3 也不等于公开名称 HTTP/3。它是连接协商期间在线路上使用的标识；HTTP/3 是便于人们识别规范与工作范围的名称。Nottingham 的邮件说，名称在 RFC 发布前不会正式确定，也不会在线路上使用。这给了工作组在标识被实现依赖之前修改方案的余地。

维护转交后来也出现在治理文件里。2018 年的 HTTPbis 章程写明，QUIC 工作组发布 HTTP/3 后，HTTPbis 将按需要维护 HTTP/3 并制定扩展，其中包括 QPACK。现行 HTTP 章程把 HTTP/3 与 QPACK 列为 HTTP 核心规范。现行 QUIC 章程也说明，QUIC 工作组最初提出了 HTTP/3 映射和 QPACK，但这些规范现在由 HTTP 工作组维护。

这种分工不是一道不能跨越的墙。QUIC 工作组当前仍列有 HTTP/3 qlog 事件定义工作，因为观测传输与应用行为时，两层会交会。更准确的说法是：HTTP 工作组维护 HTTP 的核心映射和扩展，QUIC 工作组继续处理传输机制相关的工作。真实系统中的依赖关系要求两个社区保持协作。

发布规范不等于部署

HTTP/3 这个名称不会自动让客户端发起连接，也不能保证服务器接受协议，更不能证明某条网络路径运行顺利。RFC 发布和 ALPN 标识提供了共同参照；实现者仍须协商、互通、处理回退并自行决定部署。名称可以减少概念混淆，但不能代表采用率或性能。

这也限定了 Nottingham 提案的作用。共同规范可以规定 HTTP 消息语义和它在 QUIC 上的映射；传输规范可以规定交付、拥塞控制和安全机制；工作组章程可以标明谁负责后续维护。最终，部署者和实现者仍要决定是否以及如何采用。每份记录回答的问题都不同。

Nottingham 的贡献不是他一个人给 HTTP/3 命名或完成维护转交。他把一个更清楚的名称与未来的维护责任联系起来，并主张由 HTTP 社区决定名称。会议纪要和工作组章程记录了后续处理。对于任何跨层规范，更有用的检验是：读者能否辨别哪些语义保持共用、哪一层发生变化、谁维护每一部分，以及实现还要证明什么？

资料来源