HTTP应用程序层协议是Internet的基础。它于1991年以HTTP / 0.9的形式开始使用，到1999年它变成了Internet工程理事会（IETF）标准化的HTTP / 1.1。

HTTP / 1.1使所有人都满意了很长时间，但是Web增长的需求需要升级-并在2015年采用HTTP / 2。故事还没有结束：就在最近，IETF宣布了新版本的HTTP / 3。对于某些人来说，这是一个惊喜，并引起了一些混乱。如果您不监视IETF，似乎HTTP / 3来自无处。但是，我们可以根据实验的历史和Web协议（尤其是QUIC传输协议）的发展来追溯其起源。

如果您不熟悉QUIC，我的Cloudflare同事将详细介绍各个方面：例如，请参阅有关现代HTTP的真正缺陷的文章以及有关传输层协议的详细信息。我们已经在cloudflare-quic.com上收集了这些和其他材料。并且，如果您有兴趣，请务必查看quiche ：这是我们自己的QUIC的实现，用Rust用开放源代码编写。

HTTP / 3-应用层QUIC传输协议的转换。 HTTP / 3这个名称直到最近才在草案的第17版（ draft-ietf-quic-http-17 ）中被正式批准。该提议于2018年10月底提出，11月在曼谷举行的IETF 103会议上达成了共识。

以前，HTTP / 3在QUIC中被称为HTTP，在此之前-gQUIC被称为HTTP / 2，甚至更早之前-gQUIC被称为SPDY。但最重要的是，HTTP / 3只是在IETF QUIC协议（基于UDP的多路复用和安全传输）上运行的新HTTP语法。

在本文中，我们将介绍一些以前的HTTP / 3名称的历史，并介绍更改姓氏的动机。让我们回到HTTP的第一天以及这段时间内发生的一切。如果您想全面了解，可以立即转到文章末尾或打开此非常详细的SVG版本。

HTTP / 3层蛋糕

摆设

在专注于HTTP之前，值得回顾一下，有两个协议称为QUIC。正如我们已经解释的那样，gQUIC通常被用作Google QUIC（源协议）的缩写，而QUIC被用作不同于gQUIC的IETF版本。

自90年代初以来，互联网的需求发生了变化。我们具有HTTP的新版本和TLS协议（传输层安全性）形式的新安全性。在本文中，我们将仅介绍TLS，在博客的其他文章中，您可以更详细地研究该主题。

HTTP和TLS的历史记录不能用简单的日期列表来表示，因为某些分支并行地演化并且在时间上重叠。当您尝试将近30年的互联网历史中的所有点连接起来时，就离不开可视化。因此，我制定了以下计划：Cloudflare安全Web时间线。（请注意：从技术上讲，这是一个动态图，尽管人们对“图形”一词更加熟悉）。

为了美观，我放弃了一些信息，仅关注IETF空间中成功的分支机构。例如，此处未显示W3联盟的HTTP-NG工作组的工作以及作者仍在尝试解释其发音的某些奇异技术： HMURR （发音为“悍马”）和WAKA （发音为“ wah-kah”）。

在以下各节中，我们将仔细阅读这个分支图，并查看HTTP历史上的一些转折点。我希望这有助于理解为什么标准化对每个人都有利，以及IETF如何解决此问题。因此，在返回时间表本身之前，我们首先对该主题进行简要概述。如果您已经熟悉IETF，请随时跳过下一部分。

互联网标准的类型

通常，标准定义了一般能力，范围，局限性，适用性和其他考虑因素。标准存在多种形状和尺寸。它们可以是非正式的（事实上的标准），也可以是正式的（由IETF，ISO或MPEG等标准制定组织同意/发布）。该标准在许多领域得到使用，甚至还有用于制茶的正式英国标准-BS 6008。

第一个HTTP和SSL协议定义在IETF外部发布：在图中用红线标记。但是，广泛使用已使它们成为事实上的标准。

在某个时候，他们决定将这些协议形式化（一些原因在下面描述）。 Internet标准通常在IETF中定义，该标准遵循基于Internet上实际应用的“示例性共识和当前代码”的非官方原则。当有人试图在真空中开发理想的协议时，这与无尘室方法不同。

IETF标准通常称为RFC。很难简要解释一下，因此，我建议QUIC工作组Mark Nottingham的联合主席推荐“如何阅读RFC”一文。工作组或工作组实质上只是一个邮件列表。

每年，如果愿意，所有工作组成员都会举行三场个人会议。这几周的议程可能很忙，没有足够的时间来深入讨论技术问题。因此，有些人更愿意在IETF大会之间主办更多的中期会议。自2017年以来，QUIC工作组举行了几次临时会议，完整列表可在会议页面上找到。

这些会议有机会与来自其他组织的专家会面，例如Internet体系结构委员会（IAB）或Internet技术研究组（IRTF）。近年来，传统上是IETF举行IETF hackathon的周末。此处开发了实际代码，并且重要的是，它通过了兼容性测试。这有助于发现规范中的问题，这些问题可以在会议上直接讨论。

重要的是要理解RFC并非一无是处。他们经历了整个过程。它通常以IETF Internet草案（ID）草案开始，然后提交以供审核。在已经发布规范的情况下，准备ID将变得很简单。 ID的发布日期为6个月。要使其保持活动状态，您必须发布新版本。实际上，ID可以过期。这种情况经常发生。文件仍存储在IETF网站上，并向所有人开放。

在分支图上，草稿以紫色显示 。每个人都有其自己的名称，格式为draft- {author}-{working group}-{topic}-{version} 。 WG字段是可选的，它可能指向将来的IETF工作组，有时会更改。如果ID由IETF批准或直接在IETF内部启动，则该草案称为draft-ietf- {workgroup}-{topic}-{version} 。 ID可以分支，合并或淡入淡出。版本从00开始，并随每个新项目增加一个。例如，第四稿将收到版本号03。每次更改ID名称时，其版本都将重置为00。

重要的是要注意，任何人都可以将其草稿提交给IETF：不能将其视为标准。但是，如果标准化过程达成共识，并且最终文件通过了测试，我们将获得RFC。此时，名称再次更改。每个RFC都有一个唯一的编号，例如RFC 7230 。处于此状态的文档显示为蓝线。

RFC禁止更改。也就是说，对RFC的更改要求采用带有新编号的文档。更改仅用于纠正编辑或技术错误或简单的布局优化。新的RFC可以完全替代旧的RFC或对其进行补充。

所有IETF文档均可在http://tools.ietf.org上公开获得。就个人而言，对我来说，它似乎比IETF Datatracker更为方便，因为从ID到RFC的文档路径在此可视地显示。

以下示例显示了RFC 1945标准（即HTTP / 1.0）的开发。

IETF Datatracker界面上RFC 1945的历史

有趣的是，在工作过程中，我发现上述可视化是不正确的。由于某些原因，缺少draft-ietf-http-v10-spec-05 。由于该ID已有6个月的历史，因此它实际上可能在RFC通过之前就已过期，尽管实际上该草案一直有效到1996年8月。

学习一个分支图

在简短的理论介绍之后，我们可以开始研究分支图。本节介绍一些最重要的部分。每个点表示提供文档或功能的日期。为了清楚起见，IETF文档省略了项目编号，但它们均为完整版本。

HTTP于1991年作为HTTP / 0.9协议出现，并在1994年发布了draft-fielding-http-spec-00 。很快，它被IETF接受，结果名称更改为draft-ietf-http-v10-spec-00 。在草案的六个版本之后， RFC 1945标准HTTP / 1.0在1996年被采用。

但是，甚至在HTTP / 1.0上的工作完成之前，就启动了一个单独的HTTP / 1.1项目。草稿-ietf-http-v11-spec-00的草稿版本于1995年11月发布，并于1997年正式通过为RFC 2068 。敏锐的眼睛会注意到，编排图不能完全反映事件的顺序-可视化工具的故障不成功。我试图尽可能减少此类问题。

在1997年中期，HTTP / 1.1的修订版本开始为draft-ietf-http-v11-spec-rev-00 。它在RFC 2616发行后于1999年结束。在2007年之前，IETF HTTP世界中的一切都一片沉寂。我们稍后再讨论。

SSL和TLS历史记录

我们将注意力转向SSL轨迹。我们看到SSL 2.0规范是在1995年左右发布的，而SSL 3.0是在1996年11月发布的。有趣的是，SSL 3.0已在RFC 6101中获得批准，该规范仅在2011年8月出现。它位于历史部分。根据IETF的说法，其创建目的是“记录被考虑和丢弃的想法，或者在决定记录想法时已经存在的协议”。在这种情况下，我需要一个描述SSL 3.0的IETF文档，以便将其用作规范链接。

我们对SSL如何激发工程师开发TLS更加感兴趣，该协议始于1996年11月草案ietf-tls-protocol-00 。它经历了6个草案版本，并于1999年初发布为RFC 2246 -TLS 1.0。

在1995-1999年，SSL和TLS用于保护Internet上的HTTP连接。作为事实上的标准，这非常有用。仅在1998年1月，HTTPS的正式标准化才开始发布草稿草案-ietf-tls-https-00 。这项工作于2000年5月完成，并发布了RFC 2616 -TLS上的HTTP。

TLS从2000年到2007年继续发展，并采用TLS 1.1和1.2。然后有七年的停顿，然后才开始进行下一版TLS协议的工作，该协议将于2014年4月以稿草稿-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 。

运行真实代码可以帮助您了解协议在实际中的工作情况。我们将专业知识与实验信息相结合，以帮助改进代码，并在有意义的情况下，将问题或改进报告给标准化协议的工作组。

测试创新并不是唯一的重点。真正的创新者总是知道何时将创新推迟到更好的时机。有时这适用于面向安全的协议：例如，由于POODLE漏洞，Cloudflare 默认情况下禁用SSLv3 。在其他情况下，这些协议会被技术更先进的协议所替代：例如，我们将SPDY替换为HTTP / 2 。

在Cloudflare上启用和禁用协议由橙色线表示。垂直地标有助于将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”来自拉丁语单词“ two”，“ twice”或“ repeat”）。新工作组的初始章程很好地描述了它试图解决的问题。

通常，HTTPbis已开始重构RFC 2616 。它包括错误修复以及同时发布的其他规范中某些方面的实现。决定将文件分成几部分。结果，2007年12月发布了六份草案：

draft-ietf-httpbis-p1-messaging
draft-ietf-httpbis-p2-语义
草案-ietf-httpbis-p4-条件
draft-ietf-httpbis-p5范围
draft-ietf-httpbis-p6-cache
draft-ietf-httpbis-p7-auth

该图显示了在长达七年的漫长开发过程中工作的进展情况。在最终标准化之前，通过了27份草案。 2014年6月，发布了所谓的RFC 723x系列（其中x的范围为0到5）。 HTTPbis工作组主席用“ RFC2616已死”这一短语指出了这一成就。如果有人不理解，则将新文档发送到旧RFC 2616的存档中。

这与HTTP / 3有什么关系？

当IETF正在完成RFC 723x的定稿时，世界并没有停滞不前。人们继续扩展和补充HTTP。其中包括Google工程师，他们开始尝试使用自己的协议SPDY（发音为“快速”）。他们说，该协议加快了网页的加载，这是HTTP的一项基本功能。 2009年底，第一个版本发布了，2010年SPDY v2迅速出现。

我不想讨论SPDY的技术细节，但重要的是要了解SPDY采用了基本的HTTP范例并略微更改了交换格式以进行优化。回顾过去，我们发现HTTP在语义和语法之间有明显的区别。语义描述交换请求和响应的概念，包括方法，状态代码，标头字段（元数据）和主体（有用数据）。语法描述了如何将语义映射到网络上的字节。

HTTP / 0.9、1.0和1.1具有许多常见的语义。它们还使用通过TCP连接发送的字符串形式的通用语法。 SPDY采用了HTTP / 1.1的语义，并将语法更改为二进制。这是一个非常有趣的话题，但是今天我们不会钻研这个兔子洞。

使用SPDY进行的实验表明，更改HTTP语法确实可以带来效果。同时，保持现有语义很重要。例如，保存URL格式以使用https://避免了许多可能影响HTTPS实施的问题。

在看到一些积极成果之后，IETF决定是时候考虑HTTP / 2.0的选项了。在2012年3月的IETF 83会议期间，来自HTTPbis会话的幻灯片显示了开发人员为自己设定的要求和目标。它明确指出：“ HTTP / 2.0仅表示传输协议（有线格式）与HTTP / 1.x不兼容”

在这次会议期间，邀请了社区表达他们的想法。提交的草案包括草稿-mbelshe-httpbis-spdy-00 ，草稿黑山-httpbis-speed-mobility-00和草稿-tarreau-httpbis-network-friendly-00 。最后，SPDY草案被接受，并且在2012年11月开始了关于draft-ietf-httpbis-http2-00的工作。经过18项草案， RFC 7540 -HTTP / 2在两年多的时间内出现了。到2015年，HTTP / 2语法已经完全足够使HTTP / 2和SPDY不兼容。

对于那些同时重构HTTP / 1.1和采用HTTP / 2的工作组来说，这些年已经成为一个非常压力的时期。这与2000年代初的多年平静形成鲜明对比。请务必查看完整的图，以真正欣赏完成的工作量。

尽管HTTP / 2标准化，使用SPDY进行实验仍然有用。 Cloudflare于2012年8月引入了SPDY支持，直到2018年2月才删除了SPDY支持，当时我们的统计数据表明，不到4％的Web客户端要求它。同时，在RFC于2015年12月发布后不久，我们引入了HTTP / 2支持，当时分析显示对Web客户端提供了显着支持。

默认情况下，SPDY和HTTP / 2协议使用TLS。 2014年9月，通用SSL的引入使我们能够保证所有Cloudflare用户在引入新协议时都将使用它们。

gQUIC

Google继续进行试验，直到2015年发布了SPDY v3和v3.1的另一个版本。他们还开始研究gQUIC协议，该协议的初稿于2012年初发布。

gQUIC的早期版本使用HTTP SPDY v3语法。因为HTTP / 2尚未被批准，所以此选择很有意义。 SPDY二进制语法打包在以UDP数据报发送的QUIC数据包中。这与HTTP传统上依赖的TCP传输有所不同。整个组装系统如下所示：

SPDY分层馅饼通过gQUIC

GQUIC使用技巧来提高性能。其中之一是模糊应用程序和传输之间的界限。实际上，这意味着gQUIC仅支持HTTP。这种连接是如此牢固，以至于当时被称为QUIC的gQUIC被视为下一版HTTP的候选者。尽管将来对QUIC进行了许多更改，但直到今天，许多人仍然认为它仅支持HTTP。不幸的是，这在讨论协议时会引起混乱。

gQUIC不断发展，最终转换为更接近HTTP / 2的语法。如此接近以至于大多数人开始将其称为“ QUIC的HTTP / 2”。但是由于技术限制，出现了一些非常细微的差异。一个示例是HTTP标头的序列化和交换。这是一个很小的差异，但实际上这意味着gQUIC HTTP / 2与IETF HTTP / 2不兼容。

最后但并非最不重要的一点是，您应始终考虑Internet协议的安全性。而且，gQUIC的开发人员决定放弃TLS，转而采用另一种称为QUIC Crypto的方法。有趣的创新之一是加速握手的新方法。与服务器建立安全会话后，客户端可以重用信息并固定握手的“零”时间，即0-RTT。此技巧后来包含在TLS 1.3协议中。

我终于可以找出HTTP / 3是什么吗？

差不多了

现在我们了解了标准化的工作原理。因此，gQUIC的考虑是根据相同的情况进行的。 2015年6月，引入了第一份草案-tsvwg-quic-protocol-00草案，标题为“ QUIC：HTTP / 2的基于安全和可靠的UDP的传输”。但不要忘记，最终协议语法几乎与HTTP / 2兼容。

谷歌宣布 “ BoF将在布拉格举行的IETF 93会议上举行。” 如果您对BoF是什么感兴趣，请参阅RFC 6771 。简而言之，BoF（羽毛之鸟）是一次非正式会议。

与IETF进行讨论的结果是，确定QUIC在传输级别具有许多优势，您应该将此协议与HTTP分开，并在各层之间重新引入清晰的分隔。此外，对于该协议，他们决定返回基于TLS的握手（这还不错，因为到那时为止，已经开发了使用0-RTT方案的TLS 1.3）。

大约一年后的2016年，发布了一组新的草稿：

这是再次引起混乱的地方： draft-shade-quic-http2-mapping-00被称为“使用QUIC传输协议的HTTP / 2语义”，并描述了“使用QUIC的HTTP / 2语义映射”。但是，这是错误的名称。 HTTP / 2的本质是在保留语义的同时更改语法。另外，由于我之前已经概述了原因，“ gQUIC的HTTP / 2”从来都不是该语法的准确描述。熟悉未来事件时，请记住这一点。

IETF的QUIC版本应成为全新的传输协议。这是一家认真的企业，因此IETF试图评估其成员对该项目的兴趣。为此，在2016年于柏林举行的IETF 96会议上，举行了BoF会议（幻灯片）。我很幸运地亲自参加了会议，吸引了数百名与会者，这在Adam Roach的照片中得到了证明。结果，达成了共识：IETF将采用QUIC并将其标准化。

用于将HTTP转换为QUIC传输的IETF QUIC draft-ietf-quic-http-00初稿在逻辑上将协议名称简化为“ HTTP over QUIC”（HTTP over QUIC）。不幸的是，这项工作尚未完成，因此在整个组织中使用了不同的HTTP / 2术语。新的标准草案存储库编辑者Mike Bishop看到了问题，并开始更正不正确的HTTP / 2引用。在该协议的下一版本中，描述更改为“在QUIC上映射HTTP语义”。

逐渐地，随着时间的推移和更新的版本，术语“ HTTP / 2”开始不再频繁使用，如果有必要，仅指向RFC 7540 。两年后，即2018年10月，发布了草案的第17版（第16号）。尽管HTTP over QUIC协议类似于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 Core工作（您可能已经以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上使用，IETF QUIC是基于UDP的多路复用且安全的传输 。有许多有趣的技术细微差别，但您必须将它们再推迟一次。

我们研究了开发HTTP和TLS的重要步骤，但彼此分开。现在，在文章结尾，我们将再次发布完整的枝形图。您可以在舒适的环境中从容地仔细研究它。对于监督员：这是一个绝对完整的版本，包括草稿。

HTTP / 3：从根到提示

摆设