引言
HTTP/3是QUIC传输层的HTTP应用映射。这个名称于2018年10月底在draft-ietf-quic-http-17中正式提出，并在同年11月，在曼谷举行的IETF 103会议中达成了一定的共识。HTTP/3之前被叫做HTTP over QUIC，而其之前又被称为QoS/2，而不是QUIC。在此之前，我们有基于gQUIC的HTTP/2，更早之前，我们有基于gQUIC的SPDY。 然而，其实HTTP/3只是一种适用于IETF QUIC的新的HTTP语法，基于UDP的多路复用和安全传输。
在这篇文章中，我们将探讨一些HTTP/3之前名称背后的历史，并介绍最近更改名称的动机。我们将从HTTP早期阶段开始讲，会提及一些重要的工作。
HTTP/3 分层示意图
入门知识
在我们讨论HTTP之前，值得注意的是，有两个协议都叫做QUIC。正如我们之前解释的那样，gQUIC通常是指Google QUIC（原始协议），而QUIC通常用于表示与gQUIC不同的IETF版本。
从90年代初期开始，网络的需求就发生了变化。我们有了新版本的HTTP，并以安全传输层协议（TLS）的形式增加了用户安全性。为了更好地阐述HTTP和TLS的历史，我开始整理协议规范和日期的细节。此信息通常以文本形式呈现，例如按日期排序的说明文档标题列表。但是，存在分支标准，每个标准都在时间上重叠，简单的列表无法表达真实的复杂的关系。在HTTP中，已经进行了一些并行工作，如重构核心协议定义以便于使用，扩展了协议以用于新的用途，重新定义协议如何通过Internet交换数据以提高性能等。当你试图在近30年的互联网历史中跨越不同分支接触这些工作时，你需要一个可视化的列表。所以我制作了一个Cloudflare Secure Web 时间线. （注意：它其实是一个“进化树”，但“时间线”更通俗易懂）。
我在创建时间线时选择了一些IETF中成功的分支。一些未显示的内容包括W3 Consortium HTTP-NG工作组的工作，以及他们的作者解释如何发音的一些奇特的想法：如HMURR（发音为'hammer'）、WAKA（发音为“wah-kah”）等。
在接下来的几节中，我将按照这个时间表来解释HTTP发展历史中的关键节点。理解为什么标准化是有益的，以及IETF是如何做的，可以帮你更好地读懂这篇文章的内容。因此，在谈时间线之前，我们将简要介绍一下该内容。如果您已熟悉IETF，请跳过下一部分。
互联网标准的类型
通常，标准定义了共同的参考术语，范围，约束，适用性和一些其他考虑因素。标准存在许多形式，可以是非正式（事实上）的或是正式的，正式标准由标准定义组织（例如IETF，ISO或MPEG）同意/发布。标准用于许多领域，甚至有正式的英国制茶标准——BS 6008。
早期的Web使用在IETF外部发布的HTTP和SSL协议定义，这些定义在Secure Web时间线上标记为红线。客户端和服务器对这些协议的采用使它们成为“事实上”的标准。
而在某一时刻，大家决定将这些协议正式化（一些激励原因将在后面的部分中描述）。互联网标准通常在IETF中定义，它遵循“相信共识和运行的代码”的非正式原则。这是基于在Internet上开发和部署内容的经验。这与尝试在真空中开发完美方案的“洁净室”方法形成对比。
IETF Internet标准通常称为RFC，这比较难以解释，因此我建议您阅读由QUIC工作组联合主席Mark Nottingham撰写的博客“如何阅读RFC”（"How to Read an RFC", https://www.ietf.org/blog/how-read-rfc/）。一个工作组（Wrok Group, WG），只是一个邮件列表。
每年IETF举行三次会议，为所有工作组提供时间和设施，如果他们愿意，可以亲自见面。这几周的议程可能变得非常拥挤，只有有限的时间可以深入讨论高度技术性的领域。为了解决这个问题，一些工作组选择在IETF一般会议之间的几个月内举行临时会议。这有助于保持规范开发的势头。自2017年以来，QUIC WG已举行了几次临时会议，会议页面上提供了完整的清单。
这些IETF会议还为其他与IETF相关的人员会议提供了机会，例如互联网架构委员会或互联网研究工作组。近年来，IETF Hackathon在IETF会议之前的周末举行。这为社区提供了开发运行代码的机会，更重要的是，在与他人共用的同一个房间内进行互操作性测试。这有助于查找可在接下来的几天中讨论的规范中的问题。
在本文中，需要理解的是RFC不会忽然出现。相反，它们会经历一个过程，通常从提交供考虑采用的IETF Internet草稿（I-D）格式开始。在已经发布规范的情况下，I-D的准备可能只是一个简单的重新规范化练习。 I-D从发布之日起有6个月的有效期。要使它们保持活动状态，需要发布新版本。在实践中，让I-D过期并没有太多后果，而且经常发生。这些文件继续在IETF文档的网站上托管，供任何想要阅读它们的人使用。
I-D在Secure Web时间线上表示为紫色线条。每个都有一个唯一的名称，其形式为draft- {作者}-{工作组}-{议题}-{版本}。工作组字段是可选的，它可能会预测IETF WG将在该文件上工作，有时这会发生变化。如果IETF采用I-D，或者I-D直接在IETF内启动，则名称为draft-ietf- {工作组}-{议题}-{版本}。I-D可以在分叉，合并或死亡。版本从00开始，每次发布新草稿时增加1。例如，I-D的第4稿将具有版本03。任何时候I-D更改名称，其版本将重置为00。
值得注意的是，任何人都可以向IETF提交I-D。你不应该把它们当作标准。但是，如果I-D的IETF标准化过程确实达成共识，并且最终文档通过审核，我们最终会得到一个RFC。在此阶段，名称再次发生变化。每个RFC都会获得一个唯一的编号（例如RFC 7230）。这些在Secure Web时间线上以蓝线表示。
RFC是不可变的文档。这意味着对RFC的更改需要一个全新的数字。可能会进行更改以便合并勘误表（已发现和报告的编辑或技术错误）或仅重构规范以改进布局。 RFC可能会淘汰旧版本（完全替换），或者只是更新它们（实质性更改）。
所有IETF文档均可在http://tools.ietf.org上公开获取。我个人认为IETF Datatracker（https://datatracker.ietf.org/）更加用户友好，因为它提供了从I-D到RFC的文档进度的可视化。下图是一个显示RFC 1945-HTTP/1.0开发的示例，这是Secure Web时间线的灵感来源。
IETF Datatracker中RFC 1945的发布过程
有趣的是，在我的工作过程中，我发现上面的可视化是不正确的。 由于某种原因，缺少draft-ietf-http-v10-spec-05。由于I-D寿命为6个月，因此与RFC之间存在区别，而实际上草案05在1996年8月之前仍然有效。
探索Secure Web时间线
通过对互联网标准文档如何实现的认识，我们可以开始走向Secure Web时间线。 在本节中，有一些摘录图表显示了时间线的重要部分。 每个点代表文档或功能可用的日期。 对于IETF文档，为清楚起见，这里省略了草稿编号。
HTTP在1991年开始作为所谓的HTTP / 0.9协议开始，并且在1994年发布了I-D draft-fielding-http-spec-00。它很快被IETF采用，导致名称更改为draft-ietf-http-v10-spec-00。I-D在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。敏锐的读者会发现Secure Web时间线并未捕获该事件序列，这是由于用于生成可视化的工具存在一些问题。我们试图尽可能减少这些问题。
1997年中期以draft-ietf-http-v11-spec-rev-00的形式开始了HTTP/1.1修订工作，并这1999年随着RFC 2616的发布完成。在IETF HTTP时间线中，直到2007年之前并没有更多值得关注的大事发生。我们很快就会回到这里。
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的发展。TLS从1996年11月的draft-ietf-tls-protocol-00开，经历了6个草案版本并在1999年作为RFC 2246-TLS 1.0发布。
在1995年和1999年之间，SSL和TLS协议用于保护Internet上的HTTP通信。这作为非正式的标准工作得很好。直到1998年1月，HTTPS的正式标准化过程才开始发布I-D draft-ietf-tls-https-00。该工作于2000年5月RFC 2616-HTTP over TLS的发布结束。
TLS在2000年至2007年间继续发展，标准化为TLS 1.1和1.2，距TLS的下一版本开始工作之前有7年的时间。下一个版本在2014年4月被采纳为draft-ietf-tls-tls13-00，并且在28次草案之后，在2018年8月完成了RFC 8446-TLS 1.3。
互联网标准化进程
在仔细观察时间表后，我希望您能够了解IETF是如何运行的。互联网标准形成方式的一个概括是研究人员或工程师设计适合其特定用例的实验协议。他们在不同规模的水平上试验公共或私人协议。数据有助于识别改进或问题。可以发布这项工作来解释实验，收集更广泛的意见或帮助找到其他实施者。其他人接受这项早期工作可能会成为“事实上”的标准;最终可能有足够的动力使标准正式化。
对于可能正在考虑实施，部署或以某种方式使用协议的组织而言，协议的状态可能是一个重要的考虑因素。正式的标准化过程可以使“事实上”的标准更具吸引力，因为它倾向于提供稳定性。管理和指导由IETF等组织提供，反映了更广泛的经验。但是，值得强调的是，并非所有正式化标准都能成功。
创建最终标准的过程几乎与标准本身一样重要。最初的想法和邀请具有更广泛知识，经验和用例的人的贡献可以帮助产生对更广泛的人群更有用的东西。但是，标准化过程并不总是那么容易。存在陷阱和障碍。有时，该过程太长以至于产出的标准已经无关紧要了。
每个标准定义组织都倾向于拥有自己的流程，围绕其领域和参与者。解释有关IETF如何工作的所有细节远远超出了本文的范围。IETF的“我们如何工作”页面（https://www.ietf.org/how/）是一个很好的起点，涵盖了许多方面。像往常一样，形成理解的最佳方法是亲自参与。这可以像加入电子邮件列表或参加相关GitHub repository上的讨论一样简单。
Cloudflare的运行代码
Cloudflare很自豪能够成为新的和不断发展的协议的早期采用者。我们有早期采用新标准的长期记录，例如HTTP/2。我们还测试了一些实验性的功能，如TLS 1.3和SPDY。
关于IETF标准化过程，在各种网站上的真实网络上部署此运行代码有助于我们了解协议在实践中的运作情况。我们将现有的专业知识与实验信息相结合，以帮助改进运行代码，并在有意义的情况下，反馈问题或改进标准化协议的工作组。
测试新事物不是唯一的优先事项。作为一个创新者的一部分是知道什么时候该向前迈进，并放弃部分旧的创新。有时这与面向安全的协议有关，例如，由于POODLE漏洞，Cloudflare默认禁用SSLv3。在另一些情况下，旧的协议会被技术更先进的新协议取代，例如Cloudflare已经取消使用SPDY，因为支持的HTTP/2中包含了SPDY的思想。
相关协议的引入和弃用在Secure 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）。如果不是特别声明，这些新文件将废弃旧的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发布后不久。
SPDY和HTTP/2协议的Web客户端支持首选使用TLS的安全选项。 2014年9月引入通用SSL有助于确保所有注册到Cloudflare的网站都能够在我们引入这些新协议时利用这些新协议。
gQUIC
谷歌在2012年至2015年期间继续进行实验，他们发布了SPDY v3和v3.1。 他们也开始研究gQUIC（当时发音同quick），最初的公开规范于2012年初推出。
gQUIC的早期版本使用了SPDY v3形式的HTTP语法。这样选择是因为当时HTTP/2还没有完成标准化。SPDY二进制语法被打包成可以在UDP数据报中发送的QUIC数据包。 这与HTTP传统上依赖的TCP传输有所不同。这看起来像：
基于SPDY的gQUIC分层示意图
gQUIC使用巧妙的技巧来实现性能提升。其中之一是打破应用程序和传输之间的明确分层。这在实践中意味着gQUIC只支持HTTP。因此，当时被称为“QUIC”的gQUIC与作为HTTP的下一个候选版本同义。尽管QUIC在过去几年中不断发生变化，直到今天，人们还是将QUIC这个术语理解为最初的仅限HTTP的变体。不幸的是，这在讨论协议时经常引起混淆。
gQUIC继续进行实验并最终切换到更接近HTTP/2的语法，所以，大多数人简称为“HTTP/2 over QUIC”。但是，由于技术限制，存在一些非常微妙的差异。例如如何序列化和交换HTTP头。这是一个微小的差异，但实际上意味着gQUIC上的HTTP/2与IETF的HTTP/2不兼容。
最后，我们始终需要考虑Internet协议的安全性方面。 gQUIC选择不使用TLS来提供安全性。相反，Google开发了一种名为QUIC Crypto的不同方法。其中一个有趣的方面是加速安全握手的新方法。先前与服务器建立安全会话的客户端可以重用信息来执行“零往返时间”（0-RTT握手）。0-RTT后来被纳入TLS 1.3。
所以现在可以告诉我到底什么是HTTP/3了么？
差不多了。
到目前为止，您应该熟悉标准化的工作原理和 gQUIC。人们又足够的兴趣将Google的规范写成I-D。2015年6月，提交了题为“QUIC: A UDP-based Secure and Reliable Transport for HTTP/2”的draft-tsvwg-quic-protocol-00。如刚才提到的，其语法几乎与HTTP/2一致。随后谷歌宣布在布拉格的IETF 93举行Bar BoF（Birds of a Feather）。
简而言之，与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是在改变语法的同时保持语义。此外，如我之前提到，“HTTP/2 ” 也从来不是对语法的准确描述。请保持这个想法。
这个IETF版本的QUIC将是一个全新的传输协议。这是一项艰巨的任务，在投入这类任务之前，IETF喜欢从其成员那里评估实际的利益。为此，在2016年柏林举行的IETF 96会议上，举行了一次正式的BoF会议。我很幸运能亲自参加会议。数百人参加了会议，在会议结束时达成了共识， QUIC将在IETF中采用并标准化。
用于将HTTP映射到QUIC的第一个IETF QUIC I-D，draft-ietf-quic-http-00，采用Ronseal方法并将其名称简化为“HTTP over QUIC”。不幸的是，它没有完全完成工作，并且其中存在许多HTTP/2术语的实例。I-D新编辑Mike Bishop发现了这一点并开始修复HTTP/2的误称。在01草案中，描述改为“基于QUIC的HTTP语义映射”。
随着时间和版本的推移，术语“http/2”的使用逐渐减少，这些实例变成了对RFC7540部分的引用。向前推进两年到2018年10月，I-D现在的版本是16。而HTTP在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 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
我们可能会对这些名称进行过多的解读，并认为基本的HTTP语义是特定于HTTP版本的，即HTTP/1.1。但是，这是HTTP系列树的意外误解。好消息是HTTPbis工作组正试图解决这个问题。一些成员正在进行另一轮文件修订。这项工作现在正在进行中，并被称为HTTP核心活动。这将把六个草案缩减为三个：
HTTP Semantics (draft-ietf-httpbis-semantics)
HTTP Caching (draft-ietf-httpbis-caching)
HTTP/1.1 Message Syntax and Routing (draft-ietf-httpbis-messaging)
在这种新结构下，HTTP/2和HTTP/3显然是通用HTTP语义的语法定义。但这并不意味着它们除了语法之外没有自己的特性，但这应该有助于今后的讨论。
总结
本文对过去三十年来IETF中HTTP的标准化过程进行了简单的介绍。在不涉及很多技术细节的情况下，我试图解释我们今天是如何使用HTTP/3的。如果您跳过中间的部分，并在这里寻找一句话总结，那么它就是：HTTP/3只是一种新的HTTP语法，它用于IETF QUIC，其是一种基于UDP的多路复用和安全传输协议。
本文中，我们探讨了HTTP和TLS开发中的重要节点，但这些节点是独立的。 我们通过将它们全部整合到下面提供的完整Secure Web时间线中来结束本文。您可以使用它来自行调查详细的历史记录。
