HTTP/3 的前世今生

HTTP 是为 Web 提供支持的应用层协议。它始于 1991 年的 HTTP/0.9 协议，到 1999 年已演变为 HTTP/1.1，由 IETF（互联网工程任务组）实现标准化。HTTP/1.1已经使用了很长一段时间，但随着 Web 需求不断变化，所以需要更好的协议，在 2015 年出现了 HTTP/2。最近宣布 IETF 打算提供新的版本 - HTTP/3。对某些人来说，可能不仅感到惊喜，也感到有些困惑。如果你没有密切地追踪 IETF 的工作，似乎 HTTP/3 出乎意料。但是，我们可以通过一系列实验和 Web 协议的演变来追溯它的起源， 特别是 QUIC 传输协议。

如果你不熟悉 QUIC，我的同事已经在相关的方面写了一些文章。 John的博客描述了当今HTTP的一些现实世界的烦恼，Alessandro的博客谈到了一些传输层协议的细节，而Nick的博客介绍了如何开展一些测试。 所有这些文章都可以在 https://cloudflare-quic.com 上找到，如果你感兴趣的话，可以看下我们用 Rust 编写的 QUIC 协议的开源实现 - quiche。

HTTP/3 是映射到 QUIC 传输层的 HTTP 应用程序。这个名称在最近的草案版本17（draft-ietf-quic-http-17）中正式提出，草案于2018年10月底提出，11月在曼谷举行的 IETF 103 会议期间进行了讨论并达成初步共识。 HTTP/3 最初来源于 SPDY over gQUIC，之后是 HTTP/2 over gQUIC，再后来是 HTTP/2 over QUIC， 最后才是HTTP over QUIC，而现在被称为 HTTP/3。其实，HTTP/3 只是一种新的 HTTP 语法，可以在 IETF-QUIC（一种基于UDP的多路传输和安全传输）上工作。

在这篇博客文章中，我们将探讨一些 HTTP/3 之前的名称由来，并介绍最近更改名称的缘由。我们将回到 HTTP 的早期阶段，并且沿路探寻这期间所有的优秀工作。如果您希望全面了解整个过程，可以跳到文章末尾或打开这个非常详细的SVG版本。

HTTP/3 蛋糕图表示

设置场景

在我们关注 HTTP 之前，要注意有两个协议共享了 QUIC 的名称。正如我们前面所解释的，gquic通常用于标识Google-QUIC（原始协议），而 QUIC 通常用于表示与 gQUIC 不同的 IETF 标准进行中的版本。

自 90 年代初期以来，网络的需求已经发生了变化。我们已经有了新版本的 HTTP，并以传输层安全性（TLS）的形式添加了用户安全性。我们只会在这篇文章中涉及到TLS，如果您想更详细地了解这一领域，我们的其他博客文章是一个很好的资源。

为了有助于我解释 HTTP 和 TLS 的历史，我开始整理协议规范和日期的详细信息。这些信息通常以文本形式显示，如按日期排序的项目符号点列表，说明文档标题。然而，存在分支标准，时间上有重叠，并且一个简单的列表有时候并不能表达关系的真正复杂性。在 HTTP 中，有一些并行工作可以重构核心协议定义以便于使用，扩展协议以供新用途，并重新定义协议如何在 Internet 上交换数据以获得性能。当你试图在近 30 年的互联网历史中跨越不同分支的工作流加入这些点时，你需要可视化。所以我做了一个 CloudFlare 安全 Web 时间表。（注：从技术上讲，它是一个进化树，但术语“时间表”更广为人知）。

I have applied some artistic license when creating this, choosing to focus on the successful branches in the IETF space. Some of the things not shown include efforts in the W3 Consortium HTTP-NG working group, along with some exotic ideas that their authors are keen on explaining how to pronounce: HMURR (pronounced 'hammer') and WAKA (pronounced “wah-kah”).

我在创建时申请了创作者授权，选择专注于 IETF 空间中成功的分支。一些未显示的内容包括 W3 联盟 HTTP-NG工作组的努力，以及他们的作者热衷于解释如何发音的一些奇特的想法：HMURR（发音为'hammer'）和WAKA（发音为“wah-kah”）。

在接下来的几节中，我将按照这个时间表来解释 HTTP 历史中的关键章节。当你理解为什么标准化是有益的，以及 IETF 是如何处理它的之后，你会更好地享受这篇文章的内容。因此，在回到时间轴之前，首先简要介绍该主题。如果您已熟悉 IETF，可以直接跳过下一部分。

互联网标准的类型

通常，标准定义了共同的参考术语，范围，约束，适用性和其他考虑因素。标准形态各异，可以是非正式的（也就是事实上的）或正式的（由标准定义组织（例如 IETF，ISO 或 MPEG）同意/发布）。许多领域都存在标准，甚至有一个正式的英国制茶标准 - BS 6008。

早期 Web 使用在 IETF 外部发布的 HTTP 和 SSL 协议定义，这些定义在安全Web时间表上标记为红线。客户端和服务器采用这些协议，从而使它们成为事实上的标准。

在某些时候，决定将这些协议正式化（一些激励性的原因将在后面的部分中描述）。互联网标准通常在 IETF 中定义，它遵循“粗略共识和运行代码”的非正式原则。这是基于在互联网上开发和部署内容的经验，而这恰恰与尝试在纯理论中开发完美方案的方法形成了对比。

IETF 互联网标准通常称为 RFC。这个区域解释起来很复杂，因此我建议您阅读由 QUIC 工作组联合主席Mark Nottingham 撰写的博客文章“如何阅读RFC”。工作组，或者说 WG 就是一个邮件列表。

IETF 每年举行三次会议，为所有工作组提供必要的时间和设施，如果他们愿意，可以亲自见面讨论。这几周的议程可能会非常繁忙，没有充足的时间可以深入讨论这些高度技术性的领域。为了解决这个问题，一些工作组选择在 IETF 全体会议之间的几个月内举行临时会议，这有助于保持规范开发的势头。自2017年以来，QUIC WG 已举行了几次临时会议，会议页面上提供了完整的列表。

这些 IETF 会议还为其他与 IETF 相关的人员会议提供了机会，例如互联网架构委员会或互联网研究工作组。近年来，在 IETF 会议之前的周末会举办一场IETF 黑客大会 。这为社区提供了开发运行代码的机会，更重要的是，可以和其他人在一起进行互操作性测试。这有助于在接下来的几天中找到可以讨论的规范中的问题。

这篇博客的目的是要让你要理解重要的是 RFC 不是突然出现的。相反，他们通常会经历一个以 IETF 互联网草案（I-D）格式开始的过程。在已经发布了规范的情况下，准备 I-D 可能只是一个简单的重新格式化操作。自发布之日起，I-D 的有效期为 6 个月。 为了保持活跃状态，需要持续发布新版本。在实践中，让一个I-D消失并没有什么后果，因为它经常发生。这些文档将继续托管在 IETF文档 的网站上，供任何想要阅读它们的人使用。

I-D 在 安全 Web 时间表上表示为紫色线条。每一个都有一个唯一的名称，格式为草案- {作者姓名} - {工作组} - {主题} - {版本}。工作组字段是可选的，它可能会预测 IETF WG 将在该文件上工作，有时这会发生变化。如果 IETF 采用 I-D，或者 I-D 直接在IETF内启动，则名称为草案- ietf- {工作组} - {主题} - {版本}。 I-Ds 可能会分支，合并或消亡。版本从 00 开始，每次发布新草案时增加 1。例如，I-D 的第4个草案版本号为 03。每当 I-D 更改名称，其版本将重置为 00。

值得注意的是，任何人都可以向 IETF 提交 I-D，而你不应该把它们当作标准。但是，如果 I-D 的 IETF 标准化过程确实达成共识，并且最终文档通过审核，我们最终会得到一个 RFC。在此阶段，名称再次发生变化。每个RFC都会获得一个唯一的编号，例如 RFC 7230。这些在安全 Web 时间表上以蓝线表示。

RFC是不可变的文档。这意味着对 RFC 的更改需要一个全新的数字。可能会进行更改以便合并勘误表（已发现的和报告的编辑或技术错误）或仅仅重构规范以改进布局。 RFC 可能会淘汰旧版本（完全替换），或者只是更新它们（实质性更改）。

所有 IETF 文档均可在 http://tools.ietf.org 上公开获取。我个人认为IETF Datatracker 对用户更加友好，因为它提供了从 I-D 到 RFC 的文档进度的可视化。

下面是是 RFC 1945 - HTTP/1.0 的开发过程，它是 安全 Web 时间表的一个明确的灵感来源。

IETF Datatracker view of RFC 1945

有趣的是，在我的工作过程中，我发现上面的可视化是不正确的。 由于某种原因，缺少 draft-ietf-http-v10-spec-05。 由于 I-D 生命周期为6个月，因此在成为 RFC 之前似乎存在一个间隙，而实际上 05 草案在 1996 年 8 月之前仍然有效。

探索安全 Web 时间表

认识了一下互联网标准文档如何实现的，我们就可以开始看看 Web 安全时间表了。 在本节中，有一些摘录图表显示了时间轴的重要部分。 每个点代表文档或功能可用的日期。 对于 IETF 文档，为清楚起见，省略了草案编号。 但是，如果您想查看所有细节，请查看完整的时间表。

HTTP 在 1991 年开始使用，那时称作 HTTP/0.9 协议，并且在 1994 年发布了 I-D draft-fielding-http-spec-00。 IETF 很快就采用了，导致名称更改为draft-ietf-http-v10-spec-00。 在1996年作为 RFC 1945- HTTP/1.0发布之前，经历了6个草案版本。

但是，即使在HTTP/1.0工作完成之前，在HTTP/1.1上已经启动了一个单独的活动。 ID draft-ietf-http-v11-spec-00 于1995年11月发布，并于1997年正式发布为 RFC 2068。如果你目光敏锐，就会发现 Web 安全时间表上并未完全捕获该事件序列，这是 用于生成可视化的工具的一个不幸的副作用。 我试图尽可能减少这些问题。

HTTP/1.1修订工作于1997年年中开始，形式为 draft-ietf-http-v11-spec-rev-00。 这项工作于1999年完成，并出版了 RFC2616。在IETF HTTP世界中，事情一直平静到 2007 年。我们很快就会回到这一部分。

SSL 和 TLS 的 历史

把视角转向 SSL，可以看到 SSL 2.0 规范是在 1995 年左右发布的，而 SSL 3.0 是在 1996 年 11 月发布的。有趣的是，2011 年 8 月发布的 RFC6101 描述了SSL 3.0。根据 IETF 的说法，这属于历史范畴，“通常是用来记录被考虑和抛弃的想法，或者是在决定记录这些想法时已经具有历史意义的协议。”在这种情况下，拥有一个描述SSL 3.0的IETF拥有的文档是有利的，因为它可以在其他地方用作规范参考。

我们更感兴趣的是 SSL 如何激发了 TLS 的发展，TLS于 1996 年 11 月作为draft-ietf-tls-protocol-00 开始使用。它经历了6个草案版本,并在 1999 年初作为 RFC 2246-TLS 1.0发布。

在1995年和1999年之间，SSL 和 TLS 协议用于保护互联网上的 HTTP 通信。作为事实上的标准，这是可行的。直到1998年1月，I-D draft-ietf-tls-https-00 的发布才开始了 HTTPS 的正式标准化过程。这项工作于 2000 年 5 月完成，并且发布了 RFC 2616-HTTP over TLS。

随着 TLS 1.1 和 1.2 的标准化，TLS在 2000 年至 2007 年期间持续发展。而这距离在 TLS 的下一版本开始工作前还有 7 年的间隔，该版本在 2014 年 4 月被采纳为draft-ietf-tls-tls13-00，历经28次草案后，于 2018 年 8 月发布了RFC 8446-TLS 1.3。

互联网标准化进程

在仔细观察时间表后，我希望你能够了解 IETF 的工作原理。一种形成互联网标准的方式是研究人员或工程师设计适合其特定用例的实验协议。他们广泛地在各种（公共或私人）层面上对协议进行实验。这些数据有助于改进或发现协议中的问题。这项工作可以用来解释实验，用来收集更广泛的意见或帮助找到其他实现者。早期接收这些工作的人可能会成为事实上的标准，因而最终可能有足够的动力来使其正式标准化。

对于可能正在考虑实施，部署或以某种方式使用协议的组织而言，协议的状态可能是一个重要的考虑因素。正式的标准化过程可以使事实上的标准更具吸引力，因为它往往提供了稳定性。IETF（或其他组织） 提供管理和指导，反映了更广泛的经验。但是，值得强调的是，并非所有正式标准都能成功。

创建最终标准的过程几乎和标准本身一样重要。从具有更广泛知识、经验和用例的人那里获得一个初步的想法，然后邀请他们来做出贡献，可以帮助他们创造出对更广泛人群更有用的东西。但是，标准化过程并不总是那么容易，期间会有很多陷阱和障碍，可能会很长时间没有一点相关的进展。

每个标准定义组织都倾向于拥有自己的流程，围绕其领域和参与者。解释有关 IETF 如何工作的所有细节远远超出了本篇博客的范围。 IETF 的 “我们是如何工作的” 页面就是一个很好的学习起点，涵盖了许多方面。其实一直以来，对一件事形成理解的最好的方法就是亲自参与实践，知行合一，就像加入一个电子邮件列表或讨论一个 GitHub 上的仓库一样简单。

Cloudflare 的运行代码

Cloudflare 很自豪能够成为新的和不断发展的协议的早期采用者。我们有早期采用新标准的长期记录，例如 HTTP/2。我们还测试了一些实验性的或最终尚未完成的特性，如 TLS 1.3 和 SPDY。

在 IETF 标准化过程中，在各种不同网站上的真实网络上部署此运行代码有助于我们了解协议在实践中的运作情况。我们将现有的专业知识与实验信息相结合，以帮助改进正在运行中的代码。不仅如此，向标准化协议工作组反馈问题和改进也很有意义。

测试新事物不是唯一的优先事项。作为一个创新者，应当知道何时大胆尝试新鲜事物，何时将原有的事物扔进垃圾堆。有时这与面向安全的协议有关，例如，由于 POODLE 漏洞，Cloudflare 默认禁用SSLv3。在其他情况下，协议会被更先进的技术所取代，比如 Cloudflare 弃用掉 SPDY 转而支持 HTTP/2。

相关协议的引入和弃用在 安全 Web 时间轴上以橙色线表示。虚垂直线有助于将 Cloudflare 事件与相关的 IETF 文档关联起来。例如，Cloudflare 在 2016 年 9 月引入了对 TLS 1.3 支持，最终文档 RFC 8446 将在两年后的 2018 年 8 月发布。

在 HTTPbis 中重构

HTTP/1.1 是一个非常成功的协议，时间表显示 1999 年之后 IETF 没有太多的活动。然而，真实的反映是多年使用后得出了一些实验性的经验，发现了 RFC 2616 中潜在的 问题，这导致了一些 互操作性问题。 此外，该协议还被其他 RFC（如2817和2818）扩展。2007 年决定启动一项新活动以改进 HTTP 协议规范。 这被称为 HTTPbis（其中“bis”源于拉丁语，意为“两个”，“两次”或“重复”），它采取了新工作组的形式。 原始 章程 很好地描述了工作试图解决的问题。

简而言之，HTTPbis 决定重构 RFC 2616。它包含勘误表的修订，并接受在此期间发布的其他规范的某些方面。 他们决定将文档分成几部分，这导致 2007 年 12 月发布了 6 个 I-D：

• draft-ietf-httpbis-p1-messaging
• draft-ietf-httpbis-p2-semantics
• draft-ietf-httpbis-p4-conditional
• draft-ietf-httpbis-p5-range
• draft-ietf-httpbis-p6-cache
• draft-ietf-httpbis-p7-auth

该图显示了这项工作如何通过长达 7 年的一个起草过程，发布 27 个草案版本,最终标准化。 2014 年 6月，发布了所谓的 RFC 723x 系列（其中 x 的范围从 0 到 5）。 HTTPbis WG的主席通过宣布“RFC2616 已死”来庆祝这一成就。 如果还不清楚的话，这些新文件将废弃旧的 RFC 2616。

这与 HTTP/3 有什么关系？

虽然 IETF 正忙着研究 RFC 723x 系列，但世界并未停止。人们继续在互联网上增强，扩展和试验 HTTP。其中包括谷歌，谷歌已经开始尝试一种名为 SPDY （发音为speedy）的东西。该协议被吹捧为提高 Web 浏览器的性能，这是 HTTP 的一个主要用例。在 2009 年底，SPDY v1 问世，2010 年 SPDY v2 很快被推出。

我尽量避免涉及 SPDY 的技术细节，当然这是另一个话题了。重要的是，要了解 SPDY 采用了 HTTP 的核心范例，为了提升稍微修改了交换格式。事后看来，我们可以看到 HTTP 明确划分了语义和语法。语义描述了请求和响应交换的概念，包括：方法，状态代码，头字段（元数据）和主体（有效负载）。语法描述了如何将语义映射到线路上的字节。

HTTP/0.9，1.0 和 1.1 共享许多语义。它们还共享通过TCP连接发送的字符串形式的语法。 SPDY 采用 HTTP/1.1语义并将语法从字符串更改为二进制。这是一个非常有趣的话题，但今天我们不再深入探讨。

Google 对 SPDY 的实验表明，在改变 HTTP 语法方面有希望，在保留现有的 HTTP 语义方面也有价值。例如，保持使用 https://的 URL 格式可以避免许多可能影响采用的问题。

看到一些积极的结果后，IETF决定是时候考虑一下 HTTP/2.0 了。 2012 年 3 月 IETF 83 期间举行的 HTTPbis 会议的幻灯片显示了规定的成功的要求，目标和措施。它还明确指出“ HTTP / 2.0仅表示线上与HTTP / 1.x 不兼容的那部分”。

在那次会议期间，社区被邀请分享提案。提交审议的 I-D 包括 draft-mbelshe-httpbis-spdy-00，draft-montenegro-httpbis-speed-mobility-00 和 draft-tarreau-httpbis-network-friendly-00。最终，通过了 SPDY 草案，并于 2012 年 11 月开始起草 draft-ietf-httpbis-http2-00。经过两年多的18次起草，RFC 7540-HTTP/2 于2015 年发布。在此规范期间，HTTP/2 的精确语法发生了分歧，刚好使 HTTP/2 和 SPDY 不兼容。

这些年是 IETF 与 HTTP 相关工作的一个非常繁忙的时期，HTTP/1.1重构 和 HTTP/2 标准化并行进行。这与21世纪初多年的平静形成了鲜明对比。请务必查看完整的时间表，以真正了解所发生的工作量。

尽管 HTTP/2 正处于标准化阶段，但使用和试验 SPDY 仍然有好处。 Cloudflare 在 2012 年 8 月引入了对 SPDY 的支持，并且在 2018 年 2 月弃用它，当时我们的统计数据显示不到 4％ 的 Web 客户继续想要使用 SPDY。同时，我们在2015年12月 开始支持 HTTP/2，在 RFC 发布后不久，我们的分析表明相当一部分 Web 客户端已经支持它。

SPDY 和 HTTP/2 协议的Web客户端支持首选使用 TLS 的安全选项。 2014年9月，Universal SSL 的推出有助于确保所有注册到CloudFlare的网站能够在我们推出这些新协议时支持这些新协议。

gQUIC

谷歌在 2012 年至 2015 年期间继续进行实验，他们发布了 SPDY v3 和 v3.1。 他们也开始研究gQUIC（当时发音为quick），最初的公开规范于 2012 年初推出。

gQUIC的早期版本使用了 SPDY v3 形式的 HTTP 语法。 这个选择很有意义，因为HTTP/2还没有完成。 SPDY二进制语法被打包成可以在 UDP 数据报中发送的 QUIC 数据包。 这与 HTTP 传统上依赖的TCP传输有所不同。把所有东西组合起来，就像下面这张图：

SPDY over gQUIC layer cake

gQUIC使用巧妙的技巧来实现性能，其中之一是打破应用层和传输层之间的明确分层。这在实践中意味着 gQUIC只支持 HTTP。因此，当时被称为 “QUIC” 的 gQUIC 与作为 HTTP 的下一个候选版本同义。尽管 QUIC 在过去几年中不断发生变化，我们会稍作介绍，直到今天，人们还是将 QUIC 这个术语理解为最初的仅限 HTTP 的变体。不幸的是，这在讨论协议时经常引起混淆。

gQUIC 继续进行实验并最终切换到更接近 HTTP/2 的语法。实际上，大多数人都简单地称之为“ HTTP/2 over QUIC”。然而，由于技术限制，存在一些非常微妙的差异。比如说，涉及如何序列化和交换HTTP头。这是一个微小的差异，但实际上意味着 gQUIC 上的 HTTP/2 与 IETF 的 HTTP/2 不兼容。

最后但同样重要的是，我们始终需要考虑 互联网协议的安全性方面。 gQUIC 选择不使用 TLS 来提供安全性。相反，Google开发了一种名为 QUIC Crypto 的方法。其中一个有趣的方面是加速安全握手的新方法。先前与服务器建立安全会话的客户端可以重用信息来执行“零往返时间”或 0-RTT 握手。 0-RTT 后来被纳入 TLS 1.3。

现在可以说HTTP/3 是什么了吗？

到目前为止，您应该熟悉标准化的工作原理，而 gQUIC 也没有太大的不同，谷歌的规范也是以I-D格式编写的。 2015年6月，提交了题为“QUIC：基于 UDP 的 HTTP/2 安全可靠传输”的 草案 draft-tsvwg-quic-protocol-00。 记住我前面的话，语法几乎是 HTTP/2。

谷歌宣布将在布拉格的 IETF 93 举行 Bar BoF。 对于那些 好奇 “Bar BoF”是什么的人，请参阅 RFC 6771。提示：BoF代表物以类聚（Birds of a Feature）。

简而言之，与IETF合作的结果是，QUIC 似乎在传输层提供了许多优势，并且它应该与 HTTP 分离。应重新引入层之间的明确分离。此外，有人倾向于返回基于TLS的握手（由于 TLS 1.3 在此阶段正在进行，并且正在整合 0-RTT握手，因此并没有那么糟糕）。

大约一年后，在2016年，提交了一套新的I-D：

• draft-hamilton-quic-transport-protocol-00
• draft-thomson-quic-tls-00
• draft-iyengar-quic-loss-recovery-00
• draft-shade-quic-http2-mapping-00

这里是另一个关于 http 和 quic 的困惑来源。draft-shade-quic-http2-mapping-00 的标题是“使用QUIC传输协议的HTTP/2语义”，它将自己描述为“ QUIC 上 HTTP/2语义的映射”。然而，这是用词不当。 HTTP/2是关于在保持语义的同时改变语法。此外，由于我之前概述的原因，“基于 gQUIC 的 HTTP/2 ”从未对语法进行过准确描述。记住这些想法。

这个 IETF 版本的 QUIC 是一个全新的传输协议。这是一项艰巨的任务，在首先投入这些承诺之前，IETF 喜欢衡量其成员的实际利益。为此，2016年在柏林举行的IETF 96会议上举行了正式的 “物以类聚”会议。我很幸运能够亲自参加会议而幻灯片并不能证明这一点。。如Adam Roach的照片所示，数百人参加了会议。在会议结束时达成了共识; QUIC 将被 IETF 采用并标准化。

第一个用于将HTTP映射到QUIC的 IETF QUIC I-D是draft-ietf-quic-http-00，采用 Ronseal 方法并将其名称简化为“HTTP over QUIC”。不幸的是，它没有完全完成工作，并且在整个机构中存在许多HTTP/2术语的实例。 I-Ds新编辑Mike Bishop发现了这一点，并开始修复 HTTP/2 的误称。在01草案中，描述改为“ HTTP 语义在 QUIC 上的映射”。

随着时间和版本的推移，术语“http/2”的使用逐渐减少，这些实例变成了对 RFC7540 部分的引用。向前推进两年到2018年10月，ID 版本 是16。尽管quic上的HTTP与HTTP/2存在相似之处，但它最终是一种独立的、不向后兼容的HTTP语法。然而，对于那些不密切跟踪IETF发展的人（地球人口的很大一部分），文档名称并没有捕捉到这种差异。标准化的一个要点是帮助沟通和互操作。然而，像命名这样简单的事情是社区混乱的主要原因。

回想一下2012年所说的“HTTP / 2.0仅表示线上与HTTP / 1.x 不兼容的那部分”。 IETF 遵循现有的提示。在 IETF 103 之前和期间经过深思熟虑后，达成了共识，将“HTTP over QUIC”重命名为 HTTP/3。世界现在处于一个更好的地方，我们可以继续进行更重要的辩论。

但是，RFC 7230 和 7231 与 您对语义和语法的定义不一致！

有时文档标题可能会令人困惑。目前描述语法和语义的HTTP文档有：

• RFC 7230 - 超文本传输​协议（HTTP / 1.1）：消息语法和路由
• RFC 7231 - 超文本传输​协议（HTTP / 1.1）：语义和内容

太多地阅读这些名称，就会认为基本的HTTP语义特定于HTTP的版本，即HTTP / 1.1。但是，这是HTTP系列树的意外副作用。好消息是 HTTPbis 工作组正试图解决这个问题。一些勇敢的成员正在进行另一轮的文件修订，正如罗伊菲尔丁所说，“再来一次！”。这项工作正在进行中，被称为HTTP核心活动（您可能也在名称HTTPtre或HTTPter下听说过这个，命名很难）。这将把六个草案缩减为三个：

• HTTP语义（draft-ietf-httpbis-semantics）
• HTTP缓存（draft-ietf-httpbis-caching）
• HTTP / 1.1消息语法和路由（draft-ietf-httpbis-messaging）

在这种新结构下，HTTP/2 和 HTTP/3 显然是通用HTTP语义的语法定义。这并不意味着它们除了语法之外没有自己的特性，但它应该有助于框架讨论的进行。

总结一下

这篇文章简要介绍了在过去的三十年时间中 IETF 中 HTTP 的标准化过程。 在没有触及许多技术细节的情况下，我试图解释我们今天如何是到达 HTTP/3 的。 如果您跳过中间的某些细节部分来寻找总结性的话语，那么它是：HTTP/3 只是一种新的HTTP语法，在 IETF-QUIC（一种基于UDP的多路传输和安全传输）上工作。我们下次可以进一步探索一些许多其他有趣的技术领域。

在这篇文章中，我们探讨了HTTP和TLS开发中的重要章节，但这些章节是孤立的。 我们通过将它们全部整合到下面提供的完整安全 Web 时间表中来结束这篇博客。 您可以使用它来自行调查详细的历史记录。 对于那些喜欢刨根问底的人，请务必查看完整版本，包括草稿编号。

原文链接：https://blog.cloudflare.com/http-3-from-root-to-tip/

编译： 看雪翻译小组 fyb 波

校对： 看雪翻译小组 欢歌笑语

[CTF入门培训]顶尖高校博士及硕士团队亲授《30小时教你玩转CTF》，视频+靶场+题目！助力进入CTF世界