HTTP3过去现在和未来译

共计 7039 个字符，预计需要花费 18 分钟才能阅读完成。

在去年的 HTTP3″ 生日周 ” 期间, 我们 Cloudflare 宣布了对 Web 的新标准 QUIC 和 HTTP3(或当时称为 ”HTTP over QUIC”)的初步支持, 从而可以更快,
更可靠, 更安全地 connect 到网站和 API. 我们还让客户加入 wait list, 只要相关应用开发完成他们可用后立即尝试 QUIC 和 HTTP3.

从那时起, 我们一直与业界同行合作通过 Internet Engineering Task Force(IETF.org 包括 Google Chrome 和 Mozilla Firefox),
以迭代 HTTP3 和 QUIC 标准文档.
在标准日趋成熟的同时, 我们还致力于改善对网络的支持.

现在, 我们很高兴地宣布, Cloudflare Edge Network 上已提供 QUIC 和 HTTP3 支持.
我们很高兴能与 Google Chrome 和 Mozilla Firefox(两家领先的浏览器供应商和合作伙伴)一起加入此公告, 以努力使所有人的网络速度更快, 更可靠.

用 Google 的高级软件工程师 Ryan Hamilton 的话来说,
“HTTP3 应该使每个人的网络变得更好.
Chrome 和 Cloudflare 团队密切合作, 将 HTTP3 和 QUIC 从新生标准引入到广泛采用的技术来改进 Web.
行业领导者之间的强大合作伙伴关系使互联网标准创新成为可能, 我们期待我们继续合作.”

这对使用 Cloudflare 的客户, 使用了我们的服务和 Edge Network 使他们的 Web 更快更安全, 来对与客户说这意味着什么?

在 Cloudflare 仪表板中为您的域名启用 HTTP3 支持后, 客户便可以使用 HTTP3 与您的网站和 API 进行交互.
我们一直在稳定地邀请我们的 HTTP3 等待列表中的客户, 启用该功能(请注意我们发来的邀请电子邮件), 并且在接下来的几周内, 我们将向所有人提供该功能.

如果您是互联网用户, 并且通过浏览器和其他客户端与站点和 API 进行交互, 那么此公告意味着什么?
从今天开始, 您可以使用 Chrome Canary 通过 HTTP3 与 Cloudflare 和其他服务器进行交互.
对于那些正在寻找命令行客户端的人,curl 还提供了对 HTTP3 的支持.
本文后面的内容将介绍如何在 Chrome 和 curl 中使用 HTTP3.

一直以来, 由于先有鸡还是现有蛋的问题,Internet 上的标准创新一直很困难：
*首先需要 Server 提供商 (例如 Cloudflare 或其他云服务商) 还是 Client 支持 (例如浏览器, 操作系统等)?
连接的两端都需要支持新的通信协议, 这样它才可以使用.*

Cloudflare 推动 Web 标准发展的历史由来已久, 从 HTTP3(HTTP3 之前的 HTTP 版本)到 TLS 1.3, 再到加密 SNI 之类的东西.
我们与志同道合的组织合作, 从而推动了标准的发展, 这些组织有着共同的愿望, 即帮助我们建立更好的互联网.
我们将 HTTP3 纳入主流的努力没有什么不同.

在整个 HTTP3 标准开发过程中, 我们一直与行业合作伙伴紧密合作, 以建立和验证与我们的 Edge Network 兼容和支持 HTTP3 Client.
我们很高兴能与 Google Chrome 和 curl 结合使用, 今天它们都可以用于通过 HTTP3 向 Cloudflare Edge Network 发出请求.
Mozilla Firefox 预计也将在晚些时候发布的版本中提供支持.

总的来说：2019-09-26 对于互联网用户来说是美好的一天；HTTP3 的广泛推广将为所有人带来更快的 Web 体验, 而今天的支持是朝着这一方向迈出的一大步.

更重要的是,2019-09-26 对 Internet 来说是美好的一天：Chrome,curl 和 Cloudflare, 很快,Mozilla 迅速推出了实验性但实用的对 HTTP3 的支持,
表明 Internet 标准创建过程可以正常工作.
在 Internet Task Force (ietf.org/)的协调下, 行业合作伙伴, 竞争对手和其他主要利益相关者可以齐心协力制定使整个 Internet 受益的标准, 而不仅仅只有大公司收益.

Firefox 的 CTO Eric Rescorla 很好地总结了这一点：” 开发新的网络协议很困难, 要正确实现它就需要每个人共同努力. 在过去的几年中, 我们一直与 Cloudflare 和其他行业合作伙伴一起测试 TLS 1.3, 现在测试 HTTP3 和 QUIC.
Cloudflare 对这些协议的早期服务器端支持已帮助我们解决了客户端 Firefox 实施中的互操作性问题. 我们期待着共同提高互联网的安全性和性能.”

在深入探究 HTTP3 之前, 让我们快速回顾一下 HTTP 多年来的发展, 以便更好地理解为什么需要 HTTP3.

这一切始于 1996 年 HTTP1.0 规范的发布, 该规范定义了我们今天所知道的基本 HTTP 文本传输格式 (我假装 HTTP0.9 不存在).
在 HTTP1.0 中, 将为客户端和服务器之间的每个请求 / 响应交换创建一个新的 TCP 连接, 这意味着所有 TCP/TLS 握手均在每个请求之前完成, 因此所有请求都会产生延迟. 如下图所示.

更糟糕的是,TCP 建立了称为 ” 慢启动 Slow Start” 的预热时间,” 慢启动 Slow Start” 使 TCP 拥塞控制算法可以确定可以传输的数据量, 而不是在建立连接后尽快发送所有未完成的数据. 在网络路径上发生拥塞之前的任何给定时刻, 并避免将无法处理的数据包泛洪到网络中. 但是由于新连接必须经过缓慢的启动过程, 因此它们无法立即使用所有可用的网络带宽.

几年后,HTTP 规范的 HTTP1.1 修订版试图通过引入 ” 保持连接 keep-alive” 的概念来解决这些问题, 该概念允许客户端重用 TCP 连接,
从而分摊了初始连接建立和缓慢连接的成本.
面对多个请求 Request, 但这不是灵丹妙药：
尽管多个请求可以共享同一个连接, 但是仍然必须一个接一个地序列化它们, 因此客户端和服务器只能在任意给定时间为每个连接执行一次 Request/Response 传输.

随着网络的发展, 随着多年来每个网站所需资源 (CSS,JavaScript, 图像等) 的增加, 浏览器在获取和呈现网页时需要越来越多的并发性.
但是, 由于 HTTP1.1 只允许客户端一次进行一次 HTTP 请求 / 响应传输, 因此在网络层上获得并发性的唯一方法是并行使用多个 TCP 连接到同一源,
从而失去了大多数 Keep alive 的好处. 尽管连接仍会在一定程度上 (但较小程度) 被重用, 但我们还是回到了 HTTP1.0 那个局面.

最终, 十多年后, 出现了 SPDY, 然后是 HTTP2, 它首先引入了 HTTP” 流 streams” 的概念：
一种抽象, 允许 HTTP 实现将不同的 HTTP 交换并发地复用到同一 TCP 连接上, 浏览器以更有效地重用 TCP 连接.

再一次,SPDY/HTTP2 这又不是灵丹妙药！HTTP2 解决了最初的问题 - 单个 TCP 连接的使用效率低 - 因为现在可以通过同一连接同时传输多个请求 / 响应.
但是, 即使丢失的数据仅涉及单个请求, 所有请求和响应也同样会受到数据包丢失的影响 (例如, 由于网络拥塞).
这是因为尽管 HTTP2 层可以在不同的流上隔离不同的 HTTP 交换, 但是 TCP 不了解这种抽象, 并且 TCP 所看到的只是字节流, 没有特殊含义.

TCP 的作用是以正确的顺序从一个端点到另一端点传递整个字节流 (stream).
当承载某些字节的 TCP 数据包在网络路径上丢失时, 它将在流中造成间隙, 并且 TCP 需要在检测到丢失时通过重新发送受影响的数据包来填充它.
这样做时, 即使丢失的字节本身并没有丢失并且属于完全独立的 HTTP 请求, 也不能将丢失的字节之后的已成功交付的字节都传递到应用程序.
因此, 它们最终会不必要地延迟, 因为 TCP 无法知道应用程序是否能够在没有丢失字节的情况下对其进行处理. 此问题称为 ” 首行阻塞 head-of-line blocking”.

这就是 HTTP3 发挥作用的地方：它不是使用 TCP 作为会话的传输层, 而是使用 QUIC(一种新的 Internet 传输协议),
QUIC 协议引入了传输层将流 (stream) 作为一流公民.
QUIC 流共享相同的 QUIC 连接, 因此不需要额外的握手和慢启动来创建新的 QUIC 流, 但是 QUIC 流是独立交付的, 因此在大多数情况下, 影响一个流的丢包不会影响其他流.
这是可能的, 因为 QUIC 数据包封装在 UDP 数据报的顶部.

与 TCP 相比, 使用 UDP 可以提供更大的灵活性, 并且可以使 QUIC 实现完全依赖于客户这边 (客户端), 与 TCP 一样, 协议实现的更新不依赖于操作系统更新.
借助 QUIC, 可以将 HTTP 级别的流简单地映射到 QUIC 流的顶部, 从而获得 HTTP2 的所有好处, 而消除 ” 首行阻塞 head-of-line blocking”.

QUIC 还将典型的 3 次 TCP 握手与 TLS 1.3 的握手相结合.
组合这些步骤意味着默认情况下提供加密和身份验证, 并且还可以更快地建立连接.
换句话说, 即使对于 HTTP 会话中的初始请求需要新的 QUIC 连接, 在数据开始流动之前所引起的等待时间也比具有 TLS 的 TCP 的等待时间低.

但是, 为什么不只在 QUIC 上使用 HTTP2, 而不是创建一个全新的 HTTP 版本呢?
毕竟 HTTP2 还提供了流多路复用功能. 事实证明, 在 QUIC 上使用 HTTP2 要复杂得多.

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

此行为需要创建一个称为 QPACK 的新 HTTP 标头压缩方案, 该方案可以解决问题, 但需要更改 HTTP 映射.
另外,QUIC 本身已经提供了 HTTP2 提供的某些功能(例如每流流控制), 因此从 HTTP3 中删除了这些功能是为了消除协议中不必要的复杂性.

QUIC 和 HTTP3 是非常令人兴奋的标准, 有望解决以前标准的许多缺点, 并开创了网络性能的新纪元.
那么, 我们如何从令人兴奋的标准文档过渡到可行的实施?

Cloudflare 的 QUIC 和 HTTP3 支持由 quiche(我们自己的用 Rust 编写的开源实现)提供支持).

您可以在 GitHub 上找到它, 网址为 github.com/cloudflare/quiche.

我们在几个月前发布了 quiche, 此后在现有 QUIC 支持的基础上增加了对 HTTP3 协议的支持.
我们已经开发设计了 quiche, 现在可以将其用于实现 HTTP3 客户端和服务器或仅用于普通 QUIC 的服务器.

如上所述, 我们已经开始为注册等待名单的客户提供服务.
如果您在候补名单上, 并且已经收到我们的来信, 通知您现在可以为您的网站启用该功能, 则只需转到 Cloudflare 仪表板, 然后手动从 ” 网络 ” 选项卡切换此开关：

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

为了使用 Chrome 浏览器通过 HTTP3 连接到您的网站，您首先需要下载并安装最新的 Canary 版本.
然后，启用 HTTP3 支持所需要做的就是使用 ”–enable-quic” 和 ”–quic-version = h3-23″ 命令行参数启动 Chrome Canary.

使用必需的参数启动 Chrome 后，您只需在地址栏中输入您的域名，然后查看它是否已通过 HTTP3 加载（您可以使用 Chrome 开发人员工具中的“网络 ” 标签来检查使用的协议版本）.
请注意，由于浏览器和服务器之间协商 HTTP3 的机制，因此 HTTP3 可能不会在前几个域名连接使用，因此您应该尝试重新加载页面几次.

如果这看起来太复杂，请放心，因为随着时间的流逝，Chrome 对 HTTP3 的支持将变得更加稳定，启用 HTTP3 将变得更加容易.

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

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

curl 命令行工具还支持 HTTP3 作为实验功能. 您需要从 git 下载最新版本，并按照有关如何启用 HTTP3 支持的说明进行操作.

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

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

为了执行 HTTP3 请求，您所需要做的就是将 ”–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

最后，我们还提供了一个基于乳蛋饼构建的示例 HTTP3 命令行客户端（以及命令行服务器），您可以使用它来试用 HTTP3.

为了使其运行，首先克隆乳蛋饼的 GitHub 存储库：

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

然后建立它. 您需要一个可运行的 Rust 和 Cargo 安装程序才能工作（我们建议使用 rustup 轻松设置一个有效的 Rust 开发环境）.

$ cargo build --examples

最后，您可以执行一个 HTTP3 请求：

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

在接下来的几个月中，我们将致力于改进和优化 QUIC 和 HTTP3 程序，最终将使每个人都能够启用此新功能，而无需等待列表.
随着标准的发展，我们将继续更新程序，这可能会导致标准草案版本之间的变更中断.

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

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

此功能将需要对我们的基础架构进行一些其他更改，但是我们很高兴将来能够为我们的客户提供服务.

与 TLS 1.3 一样，QUIC 支持一种操作模式，该模式允许客户端在连接握手完成之前开始发送 HTTP 请求.
我们尚未在 QUIC 部署中支持此功能，但我们将努力使其可用，就像我们已经为 TLS 1.3 支持所做的那样.

我们很高兴能够支持 HTTP3，并允许我们的客户在仍致力于标准化 QUIC 和 HTTP3 的同时进行尝试.
我们将继续与其他组织（包括 Google 和 Mozilla）合作，以最终确定 QUIC 和 HTTP3 标准并鼓励广泛采用.
这是为所有人提供更快，更可靠，更安全的 Web 体验.

翻译原文地址
Internet Task Force
Wikipedia HTTP 3
QUIC Library Is Now Open-Source
github.com/cloudflare/quiche
原文地址 https://mojotv.cn/cloudflare-http3-pass-present-future

以上就是这篇文章的全部内容了, 希望本文的内容对大家的学习或者工作能带来一定的帮助, 如果有疑问大家可以留言交流，谢谢大家对 mojotv.cn 的支持. 喜欢这个网站麻烦帮忙添加到收藏夹, 添加我的微信好友: felixarebest 微博账号: MojoTech 向我提问.

1. 先有鸡还是先有蛋的问题

2. HTTP3 进化史

2.1 HTTP1.0

2.2 HTTP1.1 引入 keep alive 解决 http1.0 Slow Start 问题

2.3 HTTP2 引入 SPDY 解决 TCP 复用问题

2.4 引入 HTTP3 和 QUIC

2.5 为什么不在 QUIC 上使用 HTTP2

3. HTTP3 由 QUIC(quiche QUIC 美味的蛋饼)驱动

3.1 如何为 Cloudflare 的域名启用 HTTP3?

3.2 使用 Google Chrome 作为 HTTP3 客户端

3.3 使用 curl

3.4 使用 quiche 的 http3-client

4. 下一步是什么?

4.1 connection 迁移

4.2 零往返时间恢复

5. HTTP3 上线了

6. 参考资料

Just My Socks（注册教程内含优惠码）