HTTP/3的过去、现在和未来

HTTP 协议为 Web 的发展提供了驱动力，它始于 1991 年的 HTTP/0.9，在 1999 年演变为 HTTP/1.1，并由 IETF（互联网工程任务组）负责进行标准化。HTTP/1.1 存在了很长一段时间，但 Web 不断变化的需求要求推出更好的协议，于是 HTTP/2 在 2015 年出现了。去年年底，IETF 又推出新版本 HTTP/3。对于有些人来说，这是一个惊喜，但也会让他们感到有一点点困惑。想要更好地了解 HTTP/3 的前世今生，以及它接下来的规划，来自 Cloudflare 博客的这篇最新文章将为你指点迷津。

在去年的“生日周”期间，我们宣布了对新生Web标准QUIC和HTTP/3（当时称为“ HTTP over QUIC”）的初步支持，从而可以更快、更可靠、更安全地连接到网站和API等Web端点。我们还请客户加入一个等候队列，这样QUIC和HTTP/3可用后他们就能立刻试用。

从那以后，我们一直在通过互联网工程任务组（包括谷歌Chrome和Mozilla Firefox）与业界同行合作，以迭代HTTP/3和QUIC标准文档。在标准日趋完善的同时，我们还致力改善网络的支持能力。

现在我们很高兴地宣布，Cloudflare边缘网络已提供QUIC和HTTP/3支持。我们很高兴能与两家领先的浏览器供应商和合作伙伴谷歌Chrome和Mozilla Firefox共同合作完成这项工作，为所有人打造速度更快、更加可靠的互联网。

用谷歌高级软件工程师Ryan Hamilton的话来说，“HTTP/3会改善所有人使用Web的体验。Chrome和Cloudflare团队密切合作，将HTTP/3和QUIC从新生标准发展为广泛应用的Web技术改进。行业领导者之间的强大合作伙伴关系推动了互联网标准创新，我们期待双方能继续合作。”

这对Cloudflare的客户又意味着什么呢？你们选择我们的服务和边缘网络，是为了让Web更快、更安全。在Cloudflare仪表板为你的域启用HTTP/3支持后，你的客户就可以使用HTTP/3与你的网站和API交互。我们一直在邀请HTTP/3等候队列中的客户启用该功能，在接下来的几周内我们将向所有人开放该功能。

如果你是互联网用户，通过浏览器等客户端与网站和API交互，那么这份公告又意味着什么呢？从今天开始，你可以使用Chrome Canary通过HTTP/3与Cloudflare和其他服务器交互。如果你想用命令行客户端的人，curl也提供了对HTTP/3的支持。后文将介绍如何通过HTTP/3使用Chrome和curl。

母鸡和鸡蛋

互联网的标准创新一直举步维艰，这是一个先有鸡还是先有蛋的问题：是服务器先支持新标准（例如Cloudflare或其大型响应数据源），还是客户端先支持（例如浏览器和操作系统等）呢？连接的两端都需要支持新的通信协议才能正常工作。

Cloudflare推动Web标准发展的历史由来已久，从HTTP/2（HTTP/3之前的HTTP版本）到TLS 1.3，再到加密SNI等等。我们与志同道合的组织合作推动标准进化，这些组织都认同我们"希望帮助建立更好的互联网"的愿望。我们将HTTP/3推向主流的努力也是如此。

在HTTP/3标准的整个开发过程中，我们一直与行业合作伙伴紧密合作，以建立和验证与我们的边缘支持兼容的HTTP/3客户端支持。我们很高兴能与谷歌Chrome和curl合作，今天它们都可以通过HTTP/3向Cloudflare edge发出请求。Mozilla Firefox预计也将为nightly版本提供支持。

总而言之，今天对于互联网用户来说是美好的一天。HTTP/3的广泛普及将为所有人带来更快的Web体验，而今天的支持工作是朝着这一方向迈出的一大步。

更重要的是，今天也是互联网的好日子：Chrome、curl和Cloudflare，以及不久之后的Mozilla迅速推出了实验性但实用化的HTTP/3支持，表明互联网标准创建已经走入正轨。在互联网工程任务组的协调下，行业合作伙伴、竞争对手和其他主要利益相关者可以齐心协力制定让整个互联网，而不仅是少数巨头受益的标准。

Firefox的CTO Eric Rescorla给出了很好的总结：“开发新的网络协议很困难，要使其走入正轨则需要每个人的共同努力。在过去的几年中，我们一直与Cloudflare和其他行业合作伙伴一起测试TLS 1.3到现在的HTTP/3和QUIC。Cloudflare对这些协议的服务端早期支持已帮助我们解决了客户端Firefox实现中的互操作性问题。我们期待这些合作能共同提高互联网的安全性和性能。”

发展历史

在深入探究HTTP/3之前，我们先来快速浏览一下HTTP多年来的发展，从而更好地理解为什么互联网需要HTTP/3。

这一切始于1996年HTTP/1.0规范的发布，该规范定义了我们今天熟知的基本HTTP文本连线格式（为了方便论述，我假装HTTP/0.9不存在）。在HTTP/1.0中，客户端和服务器之间交换的每个请求/响应都会创建一个新的TCP连接，这意味着所有TCP/TLS握手均在每个请求之前完成，因此所有请求都会产生延迟。

更糟糕的是，TCP不是在建立连接后尽快发送所有未完成的数据，而需要“慢启动”的预热时间，这使TCP拥塞控制算法能够随时确定可以传输的数据量，防止网络路径发生拥塞，并避免将无法处理的数据包都堆到网络中。但是，由于新连接必须经过缓慢的启动过程，因此它们无法立即使用所有可用的网络带宽。

几年后，HTTP规范的HTTP/1.1修订版试图引入“保持活动”连接的概念来解决这些问题，它允许客户端复用TCP连接，从而分摊了建立初始连接和针对多个请求缓慢启动的成本。但这不是灵丹妙药，尽管多个请求可以共享同一个连接，但它们仍需逐个序列化它们，因此任意时点上客户端和服务器只能为每个连接执行一次请求/响应交换。

随着网络的发展，多年来网站所需资源（CSS、JavaScript和图像等）不断增长，浏览器在获取和呈现网页时需要越来越多的并发性。但由于HTTP/1.1只允许客户端同时进行一次HTTP请求/响应交换，因此在网络层上获得并发能力的唯一方法是并行使用多个TCP连接到同一来源，代价就是牺牲了活动连接的大多数好处。尽管连接仍会在一定程度上（但程度不大）被复用，但我们又回到了起点。

十多年过去了，SPDY和HTTP/2终于相继诞生；后者率先引入了HTTP“流”的概念：这是一种抽象概念，允许HTTP实现将不同的HTTP交换并发地复用到同一TCP连接上， 使浏览器更高效地复用TCP连接。

但这也不是灵丹妙药！HTTP/2解决了最初的问题——单个TCP连接的使用效率低——因为现在可以通过同一连接同时传输多个请求/响应。但是，即使只有单个请求丢失数据，所有请求和响应也会同样受到数据包丢失（比如因为网络拥塞）的影响。这是因为尽管HTTP/2层可以在不同的流上隔离不同的HTTP交换，但是TCP不了解这种抽象，并且后者所看到的只是字节流，没有特殊含义。

TCP的作用是以正确的顺序从一个端点到另一端点传递整个字节流。当承载某些字节的TCP数据包在网络路径上丢失时将在流中造成间隙，并且TCP需要在检测到丢失时重新发送受影响的数据包来弥补这一间隙。这样做时，即使丢失数据之后的数据属于完全不同的HTTP请求，自己也根本没有丢失，也能正常传递成功，它们还是不能正常传递给应用程序。因此它们只能毫无必要地产生延迟，因为TCP无法知道应用程序缺少了丢失的数据包时能否处理后面的数据。这个问题称为“行首阻塞”。

了解HTTP/3

这就是HTTP/3的用武之地：它不是使用TCP作为会话的传输层，而是使用QUIC（一种新的互联网传输协议）。该协议率先在传输层将流作为一等公民引入。多个QUIC流共享相同的QUIC连接，因此不需要额外的握手和慢启动来创建新的QUIC流。但QUIC流是独立交付的，因此在大多数情况下，只影响一个流的丢包不会影响其他流。这是因为QUIC数据包封装在UDP数据报的顶部。

与TCP相比，使用UDP可以提供更大的灵活性，并且可以使QUIC实现完全存在于用户空间中——协议实现的更新不像TCP那样依赖操作系统的更新。借助QUIC，可以将HTTP级别的流简单地映射到QUIC流的顶部，从而在享受HTTP/2所有好处的同时避免了行首阻塞。

QUIC还结合了典型的3向TCP握手和TLS 1.3的握手。结合这些步骤意味着加密和身份验证能够默认提供，并且还可以更快地建立连接。换句话说，即使HTTP会话中的初始请求需要新的QUIC连接，在数据开始流动之前的等候延迟也比使用TLS的TCP要低。

但为什么不在QUIC上使用HTTP/2，而要创建一个全新的HTTP版本呢？毕竟HTTP/2还提供了流多路复用功能。事实证明这样做比想象的复杂许多。

确实可以轻松地将某些HTTP/2功能映射到QUIC上，但并非所有功能都能如此。特别是一种称为HPACK的HTTP/2标头压缩方案，在很大程度上取决于将不同的HTTP请求和响应传递到端点的顺序。QUIC强制执行单个流中字节的传递顺序，但不保证不同流之间的顺序。

此行为需要创建一个称为QPACK的新HTTP标头压缩方案，它可以解决问题，但需要更改HTTP映射。另外，QUIC本身已经提供了HTTP/2的某些功能（例如按流区分的流控制），因此我们从HTTP/3中删除了这些功能，从而消除了协议中不必要的复杂性。

HTTP/3，由美味的蛋饼（quiche）驱动

QUIC和HTTP/3是非常令人兴奋的标准，有望解决以前标准的诸多缺点，并开创了网络性能的新纪元。那么我们是如何从令人兴奋的标准文档发展出可行的实现的呢？

Cloudflare的QUIC和HTTP/3支持由quiche提供支持，这是我们自己用Rust编写的开源实现。

你可以在GitHub上找到它。

我们在几个月前发布了quiche，此后在已有的QUIC支持基础上增加了对HTTP/3协议的支持。我们的设计使quiche可以用于实现HTTP/3客户端和服务器，或仅用于普通的QUIC服务器实现。

如何为我的域启用HTTP/3？

如上所述，我们已经开始为注册了等候名单的客户提供服务。如果你在名单上，并且已经收到邮件通知，表示现在可以为你的网站启用该功能，则只需转到Cloudflare仪表板，然后手动从“Network”选项卡启用此开关：

我们希望在不久的将来向所有客户提供HTTP/3功能。启用后，你可以通过多种方式尝试HTTP/3：

使用谷歌Chrome作为HTTP/3客户端

为了使用Chrome浏览器通过HTTP/3连接到你的网站，你首先需要下载并安装最新的Canary版本。然后使用“–enable-quic”和“–quic-version=h3-23”命令行参数启动Chrome Canary。

使用必需的参数启动Chrome后，你只需在地址栏中输入你的域，然后查看它是否已通过HTTP/3加载（你可以使用Chrome开发人员工具中的“Network”选项卡来检查所使用的协议版本）。请注意，由于浏览器和服务器之间协商HTTP/3的方式，HTTP/3可能不会用于到域的前几个连接，因此你应该尝试重新加载几次页面。

如果这看起来太复杂了，但也请放心，因为随着时间的流逝，Chrome对HTTP/3的支持将变得更加稳定，启用HTTP/3将会变得更加容易。

这是通过HTTP/3浏览此博客时，开发人员工具中的“Network”选项卡显示的内容：

请注意，由于Chrome对HTTP/3支持的实验性质，该协议在开发人员工具中实际上被标识为“ http2+quic/99”，但请不要误解，它就是HTTP/3。

使用curl

curl命令行工具也支持HTTP/3实验功能。你需要从git下载最新版本，并按照启用HTTP/3支持的说明操作。

如果你运行的是macOS，我们还可以通过Homebrew轻松安装带有HTTP/3的curl版本：

 % brew install --HEAD -s https://raw.githubusercontent.com/cloudflare/homebrew-cloudflare/master/curl.rb

为了执行HTTP/3请求，你需要做的就是将“–http3”命令行标志添加到普通curl命令中：

 % ./curl -I https://blog.cloudflare.com/ --http3
HTTP/3 200
date: Tue, 17 Sep 2019 12:27:07 GMT
content-type: text/html; charset=utf-8
set-cookie: __cfduid=d3fc7b95edd40bc69c7d894d296564df31568723227; expires=Wed, 16-Sep-20 12:27:07 GMT; path=/; domain=.blog.cloudflare.com; HttpOnly; Secure
x-powered-by: Express
cache-control: public, max-age=60
vary: Accept-Encoding
cf-cache-status: HIT
age: 57
expires: Tue, 17 Sep 2019 12:28:07 GMT
alt-svc: h3-23=":443"; ma=86400
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 517b128df871bfe3-MAN

使用quiche的http3-client

最后，我们还提供了一个基于quiche构建的HTTP/3命令行客户端示例（也有命令行服务器），你可以用它来试用HTTP/3。

要运行它，请首先克隆quiche的GitHub存储库：

$ git clone --recursive https://github.com/cloudflare/quiche

然后构建它。首先你需要一个正常工作的Rust和Cargo环境（我们建议使用rustup轻松设置一个正常的Rust开发环境。

$ cargo build --examples

最后你就可以执行HTTP/3请求了：

$ RUST_LOG=info target/debug/examples/http3-client https://blog.cloudflare.com/

接下来有什么安排？

在接下来的几个月中，我们将致力于改进和优化QUIC和HTTP/3实现，最终将使所有人都可以启用这一新功能，不用再排队等候。随着标准的发展，我们也将继续更新实现，可能会在草案进化为标准之外引入重大更新。

以下是我们路线图上一些特别令人兴奋的功能：

连接迁移

QUIC带来的一项重要功能是在不同的网络（例如你早上上班时在家中的WiFi网络和运营商移动网络）之间进行无缝、透明的连接迁移，而无需创建全新的连接。

此功能需要对我们的基础架构进行一些额外更改，但是我们非常期待将来向客户提供这项改进。

零往返时间恢复

与TLS 1.3一样，QUIC支持一种操作模式，允许客户端在连接握手完成之前开始发送HTTP请求。我们尚未在QUIC部署中支持此功能，但就像我们在TLS 1.3支持中做到的那样，我们也将努力实现此项改进。

HTTP/3：它面世了！

我们很高兴能够为HTTP/3提供支持，并让客户在QUIC和HTTP/3的标准化推进阶段进行尝试。我们将继续与其他组织（包括谷歌和Mozilla）合作，以最终确定QUIC和HTTP/3标准并鼓励业界广泛应用。

HTTP/3将为所有人提供更快、更可靠并更安全的Web体验。

英文原文： https://blog.cloudflare.com/http3-the-past-present-and-future/