曾长期被称作 HTTP-over-QUIC 的协议现在更名啦，它将正式更名为 HTTP/3 协议，互联网工程任务组（IETF）官员透露，HTTP-over-QUIC实验协议将重命名为HTTP/3，并有望成为HTTP协议的第三个正式版本，这一决定最初由 Mark Nottingham 提议。

　　IETF 中的 QUIC 工作组致力于创建 QUIC 传输协议。 QUIC 是基于 UDP 实现的协议，是用来替换 TCP 的。QUIC 协议最初是由Google发起的项目，后面慢慢成为了 HTTP/2-encrypted-over-UDP 协议。

　　当 IETF 开始进行协议标准化工作时，协议被分为两层：传输部分和 HTTP 部分。这个想法的初衷是考虑到该传输协议也可用于传输其他数据，而不仅仅用于 HTTP 或类 HTTP 协议，但名字仍然为 QUIC。

　　社区中大家使用 iQUIC 和 gQUIC 这样的非正式名称来引用这些不同版本的协议，以便将IETF 和 Google提出的QUIC 协议分开（因为它们在细节上有很多不同）。在过去很长一段时间，通过 iQUIC 发送 HTTP 请求的协议被称为 hq（HTTP-over-QUIC）。

　　2018 年 11 月 7 日，Litespeed 的 Dmitri 宣布，他们和 Facebook 已成功完成了两个 HTTP/3 实现的互操作性测试。

　　HTTP是为Web提供支持的应用程序协议，它始于1991年的所谓HTTP/0.9协议，该协议到1999年已迭代为HTTP/1.1，并被IETF（互联网工程任务组）标准化。 HTTP/1.1在很长一段时间里满足了Web的需要，但随着互联网的快速发展，Web不断变化的需求需要更合适的协议，这也是HTTP/2在2015年出现的原因。不过就像我在开头提到的那样，最近有消息称IETF打算发布一个新版本——HTTP/3。对某些人来说，这既让人惊喜，又让人困惑。如果你不密切跟踪IETF的工作，那HTTP/3的突然出现的确会有些意外。这些正是我写本文的原因，在本文，我会通过一系列的测试案例和对Web协议的演变来追溯HTTP/3的起源，特别是QUIC传输协议。

　　如果你不熟悉QUIC，我先对它做个简要的介绍。

　　QUIC

　　QUIC（Quick UDP 互联网 Connection）是谷歌制定的一种基于UDP的低时延的互联网传输层协议。我们知道，TCP/IP协议族是互联网的基础。其中传输层协议包括TCP和UDP协议。与TCP协议相比，UDP更为轻量，但是错误校验也要少得多。这意味着UDP往往效率更高（不经常跟服务器端通信查看数据包是否送达或者按序），但是可靠性比不上TCP。通常游戏、流媒体以及VoIP等应用均采用UDP，而网页、邮件、远程登录等大部分的应用均采用TCP。

　　QUIC很好地解决了当今传输层和应用层面临的各种需求，包括处理更多的连接，安全性，和低延迟。QUIC融合了包括TCP，TLS，HTTP/2等协议的特性，但基于UDP传输。QUIC的一个主要目标就是减少连接延迟，当客户端第一次连接服务器时，QUIC只需要1RTT（Round-Trip Time）的延迟就可以建立可靠安全的连接,相对于TCP+TLS的1-3次RTT要更加快捷。之后客户端可以在本地缓存加密的认证信息，在再次与服务器建立连接时可以实现0-RTT的连接建立延迟。QUIC同时复用了HTTP/2协议的多路复用功能（Multiplexing），但由于QUIC基于UDP所以避免了HTTP/2的线头阻塞（Head-of-Line Blocking）问题。因为QUIC基于UDP，运行在用户域而不是系统内核，使得QUIC协议可以快速的更新和部署，从而很好地解决了TCP协议部署及更新的困难 。

　　HTTP/3就是映射到QUIC传输层的HTTP应用程序，HTTP/3这个名称是在2018年10月下旬提出的第17版草案(draft- IETF -quic-http-17) 中正式出现的，11月在曼谷举行的IETF 103会议上也对这个提法形成了讨论和初步共识。 HTTP/3之前称为HTTP over QUIC，而HTTP over QUIC之前的版本是又被称为HTTP/2 over QUIC。HTTP/2 over QUIC之前的版本是HTTP/2 over gQUIC，HTTP/2 over gQUIC之前的版本是SPDY over gQUIC。然而，事实是，HTTP/3只是一种新的HTTP语法，适用于IETF QUIC，这是一种基于UDP的多路复用和安全传输。

　　在这篇文章中，我们将探讨一些HTTP/3之前各个版本名称背后的历史，并介绍最近更改名称背后的动机。首先我们将介绍HTTP的早期发展阶段，并介绍在此过程中所做的所有前期工作。

把HTTP/3结构比喻为夹心蛋糕的模式

　　在关注HTTP之前，有必要提醒一下大家目前有两个协议都被叫为QUIC。正如我之前解释的那样，gQUIC通常用于识别Google QUIC（原始协议），而QUIC通常用于表示与gQUIC不同的IETF标准。

　　自90年代初以来，网络的需求就发生了剧烈的变化。我们已经有了新版本的HTTP，并以传输层安全性（TLS）的形式增加了用户安全性。不过我们只会在这篇文章中提到TLS，如果你想更详细地探索该领域，请点此链接。

　　为了帮助大家理解HTTP和TLS的历史，我会详细叙述各个版本之前的协议规范和日期的细节。这些信息通常以文本形式显示，例如按日期排序的说明文档标题的项目符号进行列表。但是，存在分支标准，每个标准在时间上都有重叠，一个简单的列表无法表达真实关系的复杂性。在HTTP中，有一些并行的工作，它们重构了核心协议定义以便于简化使用，比如扩展协议以实现新的用途，另外，还有组织试着重新定义协议以通过互联网交换数据进而提高性能。本文的历史讲解试图跨越近30年的互联网历史，其中跨越了不同的分支工作，为了便于讲解，我对所涉及的知识点进行了一个可视化编辑。

　　这可以让大家方便理解这篇文章的内容，理解为什么标准化是有益的，以及IETF是如何实现这一点的。

　　互联网标准的类型

　　通常，标准定义了共同的参考术语、范围、约束、适用性和其他考虑因素。标准有多种形式和大小，可以是非正式的，即实际在使用的或正式的，即由标准定义组织（例如IETF，ISO或MPEG）同意或发布。早期的Web使用的是非IETF发布的HTTP和SSL协议定义，这些定义在安全Web时间轴上被标记为红线。而客户端和服务器对这些协议的接受，则使它们成为事实上的标准。

　　互联网标准通常在IETF中定义，它遵循“大致共识和运行代码”的非正式原则。这是基于在互联网上开发和部署内容的经验。IETF 互联网标准通常被称为Request For Comments（RFC），RFC是一个复杂的概念，因此我建议你阅读QUIC联合主席Mark Nottingham撰写的博客文章“如何阅读RFC”。

　　IETF每年举行三次会议，这几周的议程可能非常拥挤，只有有限的时间深入讨论高技术领域。为了解决这个问题，一些工作组还选择在IETF常规会议之间的几个月内召开临时会议。这有助于追踪规范的发展势头。自2017年以来，QUIC工作组已经召开了几次临时会议，会议列表请点此。

　　这些IETF会议还为其他与IETF相关的话题的探讨提供了机会，例如互联网架构或互联网研究工作。近年来，“IETF黑客松（IETF Hackathon）”会在IETF会议之前的周末举行。IETF制定标准和可运行的代码，可运行代码对校验标准有效性、发现错误与差距，获得经验非常重要。通过Hakathon的开发活动产生的可运行代码，可以促进对标准的改进，这有助于查找可在接下来的几天中讨论的规范中的问题。

　　你要明白，RFC不是突然之间蹦出来的。相反，它们通常要经历一个漫长的演化流程，该流程通常从提交考虑采用的IETF 互联网 Draft (I-D)格式开始。在已经发布规范的情况下，准备I-D可能只是一个简单的格式化过程。I-D从发布之日起有6个月的有效期，要使它们保持活跃状态，则需要发布新版本。在实践中，让I-D消失则是经常发生的事情。不过这些相关文档会继续驻留在IETF文档的网站上，供任何想阅读它们的人使用。

　　在安全Web时间轴上，I-D用紫色线表示。每一个都有一个惟一的名称，其形式为draft-{author name}-{working group}-{topic}-{version}。工作组字段是可选的，这代表IETF WG将在该文件上工作，有时这会发生变化。如果IETF采用I-D，或者I-D是直接在IETF中启动的，则名称为draft-ietf-{working group}-{topic}-{version}。I-D可能会不断进行分支、合并或停止演化。一个新的版本会从00开始标记，每次发布一个新草案时增加1。例如，I-D的第四稿的第3个版本就标记为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视图的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。在以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的形式被命名下来。随着随着RFC 2616 的发布，修订工作作于1999年正式完成，而下一次修订就要等到2007年了。

　　现在我们将话题切换到SSL，我们看到SSL 2.0规范是在1995年前后发布的，而SSL 3.0是在1996年11月发布的。有趣的是，RFC 6101在2011年8月发布了SSL 3.0。根据IETF的说法，SSL 3.0能够近路历史操作，比如记录那些曾经被考虑和抛弃的想法，或者当决定记录它们时已经是历史性的协议。在这种情况下，拥有描述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 https://tools.ietf.org/html/rfc2616。

　　2000年至2007年期间，TLS继续发展，标准先后经历了TLS 1.1和TLS 1.2。2007年以后，TLS的最新版本将于2014年4月被统一为draft-ietf-tls-tls13-00 ，在经历了28个草案之后，于2018年8月正式发布了RFC 8446-TLS 1.3 。

　　互联网标准化流程

　　在查看了时间轴之后，我希望你能够了解IETF的工作原理。概括起来就是，互联网标准形成的过程就是研究人员或工程师设计适合他们特定用例的实验协议。他们在不同规模的公共或私有协议上进行试验，而数据有助于识别改进或总结问题。标准化工作可能是为了解释实验，收集更广泛的意见或帮助找到其他实施者。以便使早期的协议成为事实上的工作标准，进而上升为一种正是发布的标准。

　　对于正在考虑实施、部署或以某种方式使用协议的组织来说，协议的标准化状态可能是一个重要的考虑因素。正式的标准化过程可以使事实上的标准更具吸引力，因为它往往能够提供稳定地使用保障。管理和指导之所以由IETF等机构负责，主要是由于他们能吸取更广泛的经验。然而，值得强调的是，并不是所有的正式标准都能成功。

　　创建最终标准的过程几乎和标准本身一样重要，一般的过程都是按着最初的想法，在创建过程中邀请具有知识、经验和实际工作经验的人加入进来，这样可以保证所制定的标准可以对更广泛人群有用。然而，标准化的过程并不总是那么容易，存在许多陷阱和障碍。有时，这个过程花费的时间太长，以至于最后发布的标准和最初的想法大相径庭。

　　每个标准定义组织都拥有自己的制定和发布流程，而这些流程又是围绕其领域内的参与者。有关IETF如何工作的所有细节请点此。　　

责任编辑：韩希宇