[译] HTTP/3: 起源

• 原文地址：HTTP/3: From root to tip
• 原文做者：Lucas Pardue
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：Starrier
• 校对者：jerryOnlyZRJ，kasheemlew，Fengziyin1234

HTTP 是确保 Web 应用程序正常运行的应用层协议。1991 年，HTTP/0.9 正式发布，至 1999 年，已经发展为 IETF（国际互联网工程任务组）的标准化协议 HTTP/1.1。在很长的一段时间里，HTTP/1.1 表现得都很是好，但面对现在变化无穷的 Web 需求，显然须要一个更为合适的协议。2015 年，HTTP/2 应运而生。最近，有人披露 IETF 预计发布一个新版本 —— HTTP/3。对有些人来讲，这是惊喜，也引起了业界的激烈探讨。若是你不怎么关注 IETF，可能就会以为 HTTP/3 的出现很是忽然。但事实是，咱们能够透过 HTTP 的一系列实现和 Web 协议发展来追溯它的起源，尤为是 QUIC 传输协议。

若是你不熟悉 QUIC，能够查看我同事的一些高质量博文。John 的博客从不一样的角度讨论了现现在的 HTTP 所存在的一些问题，Alessandro 的博客 阐述了传输层的本质，Nick 的博客 涉及了相关测试的处理方法。咱们对这些相关内容进行了收集整理，若是你想要查看更多内容，能够前往 cloudflare-quic.com。若是你对此感兴趣，记得去查看咱们本身用 Rust 编写的 QUIC 开源实现项目 —— quiche。

HTTP/3 是 QUIC 传输层的 HTTP 应用程序映射。该名称在最近（2018 年 10 月底）草案的第 17 个版本中被正式提出（draft-ietf-quic-http-17），在 11 月举行的 IETF 103 会议中进行了讨论并造成了初步的共识。HTTP/3 之前被称为 QUIC（之前被称为 HTTP/2）。在此以前，咱们已经有了 gQUIC，而在更早以前，咱们还有 SPDY。事实是，HTTP/3 只是一种适用于 IETF QUIC 的新 HTTP 语法 —— 基于 UDP 的多路复用和安全传输。

在本文中，咱们将讨论 HTTP/3 之前一些名称背后的历史故事，以及最近改名的诱因。咱们将回到 HTTP 的早期时代，探寻它一路成长中的美好回忆。若是你已经火烧眉毛了，能够直接查看文末，或打开这个详细的 SVG 版本。

HTTP/3 分层模型（蛋糕模型）

设置背景

在咱们关注 HTTP 以前，值得回忆的是两个共享 QUIC 的名称。就像咱们以前解释得那样，gQUIC 一般是指 Google QUIC（协议起源），QUIC 一般用于表示与 gQUIC 不一样的 IETF 标准（正在开发的版本）。

在 90 年代初期，Web 需求就已经发生了改变。咱们已经有了新的 HTTP 版本，以传输层安全（TLS）的形式增强用户安全性。在本文中，咱们会涉及 TLS。若是你想更详细地了解这个领域，能够参阅咱们其余的高质量博文。

为了帮助咱们了解 HTTP 和 TLS 的历史，我整理了协议规范以及日期的细节内容。这种信息通常以文本形式呈现，好比，按日期排序说明文档标题的符号点列表。不过，由于分支标准的存在，因此重叠的时间和简单的列表并不能正确表达复杂的关系。在 HTTP 中，并行工做致使了核心协议定义的重构，为了更简单的使用，咱们为新行为扩展了协议内容，为了提升性能，咱们甚至还重定义了协议如何在互联网上交换数据。当你尝试了解近 30 年的互联网历史，跨越不一样的分支工做流程时，你须要将其可视化。因此我作了一个 Cloudflare 安全 Web 时间线（注意：从技术上说，它是进化树，但时间线这个术语更广为人知）。

在建立它时，通过深思熟虑后，我选择关注 IETF 中的成功分支。本文未涉及的内容，包括 W3C HTTP-NG 工做组的努力成果，还有些热衷于解释如何发音的做者的奇特想法：HMURR（发音为 'hammer'） 和 WAKA（发音为 “wah-kah”）。

为了让大家更好地把握本文的脉络，下面的一些部分，我会沿着这条时间线来解释 HTTP 历史的重点内容。了解标准化以及 IETF 是如何对待标准化的。所以，在回到时间线以前，咱们首先会对这个主题进行一个简短的概述。若是你已经很是熟悉 IETF 了，能够跳过该内容。

Internet 标准的类型

通常而言，标准定义了共同的职责范围、权限、适用性以及其余相关内容。标准有多种形状和大小，能够是非正式的（即事实上的），也能够是正式的（由 IETF、ISO 或 MPEG 等标准定义组织协商/发布的）。标准应用于众多领域，甚至还有一种为制茶而定义的正式标准的 —— BS 6008。

早期 Web 使用在 IETF 以外发布的 HTTP 和 SSL 协议定义，它们在安全的 Web 时间线上被标记为红线。客户端和服务的对这些协议的妥协使它们得以成为事实上的标准。

迫于当时的形式，这些协议最终被肯定为标准化（一些激进的缘由会在以后进行描述）。互联网标准一般在 IETF 中定义，以“多数共识和运行的代码”非正式原则做为指导。这是基于在互联网上开发和部署项目的经验。这与试图在真空中开发完美协议的 "clean room" 方法造成了鲜明对比。

IETF 互联网标准一般被称为 RFCs。这是一个解释起来很复杂的领域，所以我建议阅读 QUIC 工做组主席 Mark Nottingham 的博文 "如何阅读 RFC"。工做组或 WG，或多或少的只是一个邮件列表。

IETF 每一年举行三次会议，为全部工做组提供时间和设施，若是他们愿意的话，能够亲自前来。这几周的行程挤在了一块儿，须要在有限的时间里深刻讨论高级技术领域。为了解决这个问题，一些工做组甚至选择在 IETF 的通常性会议期间举行临时会议。这有助于保持规范开发的信心。自 2017 年以来，QUIC 工做组举行了几回临时会议，能够在其会议网站页面查看完整清单。

这些 IETF 会议也为 IETF 的相关群体提供了机会，好比互联网架构委员会或者互联网研究任务组。最近几年，在 IETF 会议前的几周还举行了 IETF Hackathon。这为社区提供了一个开发运行代码的机会，更重要的是，能够和其余人进行交互操做性测试。这有助于发现规范中的问题，并在接下来的会议中进行讨论。

这个博客最重要的目的是让你们理解 RFCs 并非凭空出世的。很显然，它经历了以 IETF 因特网草案（I-D）格式开始的过程，该格式是为了考虑采用而提交的。在已发布规范的状况下，I-D 的准备可能只是一个简单的重格式化尝试。I-Ds 自发布起，有 6 个月的有效期。为了保证它的活跃，须要发布新的版本。实践中，让 I-D 消逝并不产生严重的后果，并且这一状况时有发生。对于想要了解它们的人，能够在 IETF 文档网站阅览。

I-Ds 在安全 Web 时间线上显示为紫色。每条线都有格式为 draft-{author name}-{working group}-{topic}-{version} 的惟一名称。工做组字段是可选的，它能够预测 IETF 工做组是否在此工做，这是可变的参数，若是选用了 I-D，或者若是 I-D 是直接在 IETF 内启动的，名称为 draft-ietf-{working group}-{topic}-{version}。I-Ds 就可能会产生分支，合并或者死亡。从 00 版本开始，每次发布新草案就 +1。好比，I-D 的第四稿有 03 版本号。不管什么时候，只要 I-D 变动名称，它的版本号就会重置为 00。

须要注意的是，任何人均可以向 IETF 提交一个 I-D；你不该该将这些视为标准。但若是 IETF 的 I-D 标准化过程获得了一致的确定，并且经过了最终的文件审查，咱们就会获得一个 RFC。在此阶段，名称会再次变动。每一个 RFC 都有一个惟一的数字。好比，RFC 7230。他们在安全 Web 时间线上显示为蓝色。

RFC 是不可变文档。这意味着 RFC 的更改会产生一个全新的数字。为了合并修复的错误（发现和报告的编辑或技术错误）或是简单地重构规范来改进布局，能够进行更改。RFC 可能会弃用旧版本，或只是更新它们（实质性改变）。

全部的 IETF 文档都是开源在 tools.ietf.org 上的。由于它提供了从 I-D 到 RFC 的文档进度可视化，因此我的认为 IETF Datatracker 对用户很友好。

如下是显示 RFC 1945 —— HTTP/1.0 开发的示例，它为安全 Web 时间线提供了一个明确灵感来源。

IETF RFC 1945 Datatracker 视图

有意思的是，在个人工做过程当中，我发现上述可视化是不正确的。因为某种缘由，它丢失了 draft-ietf-http-v10-spec-05。因为 I-D 生命周期只有 6 个月，因此在成为 RFC 以前会存在分歧，而实际上草案 05 直到 1996 年 8 月，仍处于活跃状态。

探索安全的 Web 时间线

稍微了解因特网标准文档是如何实现后，咱们就能够着手安全网络时间线了。在本节中，有许多摘选图显示了时间轴的重要部分。每一个点对应着文档或功能的可用日期。对于 IETF 文档，为了清晰可见，省略了草案编号。但若是你想查看全部细节，能够查看完整的时间线。

HTTP 在 1991 年以 HTTP/0.9 协议开始，在 1994 年 I-D draft-fielding-http-spec-00 发布。它很快就被 IETF 采用，致使 draft-ietf-http-v10-spec-00 的名称被修改。在 RFC 1945 —— HTTP/1.0 于 1996 年发布以前，I-D 已经已经了 6 个草案版本的修改。

甚至在 HTTP/1.0 尚未完成以前，HTTP/1.1 就已经开始了一个独立的分支。I-D draft-ietf-http-v11-spec-00 于 1995 年 11 月发布，1997 年正式以 RFC 2068 形式出版。敏锐的洞察力会让你发现安全 Web 时间线并不能捕捉到事件顺序，这是用于生成可视化工具的一个不幸的反作用。我会尽量的减小这样的问题。

HTTP/1.1 修订工做在 1997 年年中以 draft-ietf-http-v11-spec-rev-00 形式开始。1999 年出版的 RFC 2616 标志着这一计划的完成。直到 2007 年，IETF HTTP 世界才得到平静。咱们很快会再说起此事。

SSL 和 TLS 的历史

如今咱们开始研究 SSL。咱们能够看到 SSL 2.0 规范是在 1995 年先后发布的，SSL 3.0 是在 1996 年 11 月发布的。有趣的是，在 2011 年 8 月发布的 SSL 3.0 RFC 6101 是里程碑版本，一般是为了“记录被考虑和丢弃的想法，或者是在决定记录他们时已经具备历史意义的协议”。参照 IETF。在这种状况下，拥有描述 SSL 3.0 的 IETF 文档是有利的，由于它能够做为其余地方的规范引用。

咱们更感兴趣的是 SSL 如何促进 TLS 发展的，TLS 的生命在 1996 年 11 月开始于 draft-ietf-tls-protocol-00。它经过了 6 个草案版本，发布时为 RFC 2246 —— TLS 1.0 起始于 1999。

在 1995 年和 1999 年，SSL 和 TLS 协议被用于保护因特网上的 HTTP 通讯。做为一个事实上的标准，它并无太大的问题。直到 1998 年 1 月，HTTPS 的正式标准化进程才随着 I-D draft-ietf-tls-https-00 的出版而开始。这项工做结束于 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 份草案以后，RFC 8446 —— TLS 1.3 于 2018 年 8 月完成。

因特网标准化过程

在看了下时间线以后，我但愿你能对 IETF 的工做方式有大概的了解。互联网标准造成方式的概况是，研究人员或工程师和他们具体用例的实验协议。他们在不一样规模的公共或私有协议中进行试验。这些数据有助于发现能够优化的地方或问题。这项工做多是为了解释试验，收集更普遍的投入，或帮组寻找其余实验者。其余对早期工做的参与者可能会使其成为事实上的标准；可能最后会有足够的缘由使其成为正式标准化的一种选择。

对于正在考虑实施、部署或以某种范式使用协议的组织来讲，协议的状态多是一个重要的因素。一个正式的标准化过程能够促使事实上的标准更具吸引力，由于标准化倾向于提供稳定性。管理和指导由 IETF 这类组织提供，它反映了更普遍的经验。然而，须要强调的是，并不是全部的正式标准都是成功的。

建立最终标准的过程与标准自己同等重要。从具备更普遍知识、经验和用例的人那里获取初步的想法和贡献，能够帮助产生对更普遍人群有用的产物。但标准化的过程并不容易。存在陷阱和障碍，有时，须要花费很长的时间过程，才能排除不相关的内容。

每一个标准定义组织都存在本身的标准化过程，主要围绕其对应领域和参与者。解释 IETF 如何运转的全部工做细节，远远超过了这个博客的涵盖范围。IETF 的“咱们的运行原理”是很好的起点，涵盖了不少内容。是的，理解的最好途径就是本身参与其中。就像加入电子邮件列表或添加相关 GitHub 仓库的讨论同样容易。

Cloudflare 的运行代码

Cloudflare 为成为新的、不断发展的协议的早期采用者而感到自豪。咱们很早就采用了新标准，好比 HTTP/2。咱们还测试了一些实验性或还没有最终肯定的特性，好比 TLS 1.3 和 SPDY。

在 IETF 标准化过程当中，将运行中的代码部署到多个不一样网站的真实网络上，能够帮助咱们理解协议在实践中的工做效果。咱们将现有的专业知识与实现信息进行结合，来改进运行中的代码，并在有意义的地方，对工做组的反馈问题或改进进行修正，来促使协议标准化。

测试新特性并非惟一的优先级。做为改革者，须要知道何时推动进度，抛弃旧的创新。有时，这会涉及到面向安全的协议，好比 Cloudflare 由于 POODLE 的漏洞而默认禁用 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。它将归入勘误修订，合并在此期间发布的其余规范的一些内容。文件将被分为几个部分，这致使 2017 年 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 工做组的主席以 "RFC2616 is Dead" 来庆祝这一成果。若是它不够清楚，这些新文档就会弃用旧的 RFC 2616。

这和 HTTP/3 有什么联系？

尽管 IETF 的 RFC 723x 系列的工做繁忙，可是技术的进步并未中止。人们继续增强、扩展和测试因特网上的 HTTP。而 Google 已率先开始尝试名为 SPDY（发音同 Speedy）的技术。该协议宣称能够提升 Web 浏览性能，一个使用 HTTP 原则的用例。2009 年末，SPDY v1 发布，2010 年 SPDY v2 紧随其后。

我想避免深刻 SPDY 的技术细节。由于这又是另外一个话题。重要的是理解 SPDY 采用的是 HTTP 核心范例，经过对交换格式的修改来改进技术。咱们能够看到 HTTP 清楚地划分了语义和语法。语义描述了请求和响应的概念，包括：方法，状态码，头字段（元数据）和主体部分（有效载荷）。语法描述如何将语义映射到 wire 字节上。

HTTP/0.九、1.0 和 1.1 有不少相同的语义。它们还以经过 TCP 链接发送字符串的形式共享语法。SPDY 采用 HTTP/1.1 语义，语法修改是，将字符串改成二进制。这是一个很是有趣的话题，但今天并不会深刻涉及这些问题。

Google 对 SPDY 实验代表，改变 HTTP 语法是有但愿的，维持现有 HTTP 语义是有意义的。好比，保留 URL 的使用格式 —— https://，能够避免许多可能影响采用的问题。

看到一些积极的结果后，IETF 决定考虑 HTTP/2.0。2012 年 3 月 IETF 83 期间举行的 HTTPbis 会议的 slides显示了请求、目标和成功标准。它还明确指出 "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。在超过 2 年的时间里完成了 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 之间，Google 继续进行试验，他们发布了 SPDY v3 和 v3.1。他们还开始研究 gQUIC(当时的发音相似于 quick），在 2012 年年初，发布了初始的公共规范。

gQUIC 的早期版本使用 SPDY v3 形式的 HTTP 语法。这个选择是有意义的，由于 HTTP/2 还没有完成。SPDY 二进制语法被打包到能够用 UDP 数据报发送数据的 QUIC 包中。这与 HTTP 传统上依赖的 TCP 传输不一样。当全部的东西堆叠在一块儿时，就会像这样：

SPDY 式 gQUIC 分层模型（蛋糕模型）

gQUIC 使用巧妙的设计来实现性能优化。其中一个是破坏应用程序与传输层之间清晰的分层。这也意味着 gQUIC 只支持 HTTP。所以，gQUIC 最后被称为 "QUIC"。它是 HTTP 下一个候选版本的同义词。QUIC 从过去的几年到如今，一直在持续更新，但咱们并不会涉及过多的讨论，QUIC 也被人们理解为是初始 HTTP 的变体。不幸的是，这正是咱们在讨论协议时，常常出现混乱的缘由。

gQUIC 继续在实验中摸索，最后选择了更接近 HTTP/2 的语法。也正由于如此，它才被称为 "HTTP/2 over QUIC"。但由于技术上的限制，全部存在一些很是微妙的差异。一个示例是，HTTP 头是如何序列化并交换的。这是一个细微的差异，但实际上，这意味着 HTTP/2 式 gQUIC 与 IETF's HTTP/2 并不兼容。

最后，一样重要的是，咱们老是须要考虑互联网协议的安全方面。gQUIC 选择不使用 TLS 来提供安全性。转而使用 Google 开发的另外一种称为 QUIC Crypto 的方法。其中一个有趣的方面是有一种加速安全握手的新方法。之前与服务器创建了安全会话的客户端能够重用信息来进行“零延迟往返握手”或 0-RTT 握手。0-RTT 后来被归入 TLS 1.3。

如今能够告诉你什么是 HTTP/3 了么？

固然。

到目前为止，你应该已经了解了标准化的工做原理，gQUIC 并不是不同凡响。或许你也对 Google 用 I-D 格式编写的规范感兴趣。在2015 年 6 月的 draft-tsvwg-quic-protocol-00 中，写有 "QUIC：基于 UDP 的安全可靠的 HTTP/2 传输" 已经提交。请记住我以前提过的，几乎都是 HTTP/2 的语法。

Google 宣布将在布拉格举行一次 Bar BoF IETF 93 会议。若有疑问，请参阅 RFC 6771。提示：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 题为 "HTTP/2 使用 QUIC 传输协议的语义"，对于本身的描述是 "HTTP/2 式 QUIC 的另外一种语义映射"。但这个解释并不正确。HTTP/2 在维护语义的同时，改变了语法。并且，我很早以前就说过了，"HTTP/2 式 gQUIC" 从未对语法进行确切的描述，记住这个概念。

这个 QUIC 的 IETF 版本即将成为新的传输层协议。由于任务艰巨，因此 IETF 会在首次确认以前，评估测评人员对其的实际兴趣程度。所以，2016 年在柏林举行 IETF 96 会议期间，举行了一次正式的 Birds of a Feather 会议。我很荣幸地参加了此次会议，幻灯片并未给出公正的评价。就像 Adam Roach 的图片所示，有数百人参加了此次会议。会议结束时，达成了一致的共识：QUIC 将被 IETF 采用并标准化。

将 HTTP 映射到 QUIC 的第一个 IETF QUIC I-D —— draft-ietf-quic-http-00，采用了 Ronseal 方法来简化命名 —— "HTTP over QUIC"。不幸的是，它并无达到预期效果，整个内容中都残留有 HTTP/2 术语的实例。Mike Bishop —— I-D 的新编辑，发现并修复了 HTTP/2 的错误名称。在 01 草案中，将描述修改成 "a mapping of HTTP semantics over QUIC"。

随着时间和版本的推动，"HTTP/2" 的使用逐渐减小，实例部分仅仅是对 RFC 7540 部分的引用。从 2018 年 10 月开始向前回退两年的时间开始计算，I-D 现在已是第 16 版本。虽然 HTTP over QUIC 与 HTTP/2 有类似内容，但始终是独立的（非向后兼容的 HTTP 语法）。然而，对那些不密切关注 IETF 发展的人来讲（人数众多），他们并不能从名称中发现一些细微的差别。标准化的重点之一是帮助通讯和互操做性。但像命名这样的简单事件，才是致使社区相对混乱的主要缘由。

回顾 2012 年的内容，"HTTP/2.0 意味着 wire 格式与 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/1.1。但这是 HTTP 家族树的反作用。好消息是 HTTPbis 工做组正在尝试解决这个问题。一些勇敢的成员正在进行文档的另外一轮修订，就像 Roy Fielding 说的 "one more time!"。这项工做目前正做为 HTTP 核心任务进行（你可能也听过 moniker HTTPtre 或 HTTPter；命名工做很艰难）。这将把六个草案压缩成三个：

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

在这种新结构之下，对于常见的 HTTP 定义来讲，HTTP/2 和 HTTP/3 的语法定义会更清晰。这并不意味着它拥有超出语法之外的特性，但这在将来是否有变数仍可商榷。

总结

本文对过去三十年 IETF 如何标准化 HTTP 作了大概的简介。在不涉及技术细节的状况下，我尽可能解释 HTTP/3 的历史发展进程。若是你跳过了中间的 good bits 部分却又想归纳地了解它，概况来讲就是：HTTP/3 只是一种适用于 IETF QUIC 的新 HTTP 语法 —— 一种基于 UDP 多路复用的安全传输层。仍有许多有趣的领域须要深刻探索，但须要等下次有机会再作介绍。

本文的叙述过程当中，咱们探究了 HTTP 和 TLS 开发中的重要章节，但它们都是单独阐述的。在文章即将结束时，咱们会将它们所有总结到下面介绍的完整安全 Web 时间线。你能够用它来调查详细的历史记录。对于 super sleuths，请务必查看包括草案编号的完整版本。

本文部份内容语句的顺序对部分读者可能会引发不适，或者因为部分译文致使的逻辑不符，能够查看这个连接进行翻译过程查看，如若还不行，可阅读原版英文，或是经过下述方法进行反馈，也可在本文下方进行评论和反馈，感谢你的关注和支持，谢谢。同时，还要感谢本文的第三个校对者：Fengziyin1234 的努力付出，让本文的质量水平进行了提高。

若是发现译文存在错误或其余须要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。