什么是 HTTP/3 – 快速新的基于 UDP 协议的内幕

TL;博士

2018 年 11 月，互联网工程任务组 (IETF) 在曼谷召开会议，通过了新的互联网草案。 HTTP/2 的继承者 QUIC 传输协议已重命名为 HTTP/3。

HTTP/3 建立在用户数据报协议 (UDP) 之上，并且已经被谷歌和 Facebook 等知名互联网公司使用。 如果您使用 Chrome 并连接到 Google 服务，那么您可能已经在使用 QUIC。

新版本的 HTTP 协议受益于裸机、低级 UDP 协议，并在 TCP 层定义了许多以前版本的 HTTP 中的新特性。 这提供了一种解决现有互联网基础设施内限制的方法。

第一个结果是有希望的，当 IETF 的 Internet 草案在 2021 年 8 月到期时，我们可以期待 HTTP/3 被推广为新的第三代 HTTP 标准。

2022 年 HTTP/3 进展

有人说，网络行业对更快速度和更低延迟的渴望与谷歌浏览器对更多 RAM 的渴望相匹配。

几年前，我们发表了一篇关于 HTTP/2 的文章，据 W3Techs 称，该标准现已达到 45% 的全球采用率。 根据 Can I Use 的说法，所有现代网络浏览器也都支持它。 然而，我们在这里，正在写一篇关于协议的下一个版本 HTTP/3 的文章。

在撰写本文时，HTTP/3 是 IETF Internet-Draft 或 ID，这意味着 Internet 工程任务组（一个国际互联网标准机构，负责定义推广商定的互联网协议标准，如 TCP、IPv6、VoIP、物联网等。

它是一个开放的机构，它联合了网络行业并促进了关于互联网方向的讨论。 目前，HTTP/3 的“互联网草案”阶段是提案被提升到请求评论（或 RFC）级别之前的最后一个阶段，出于所有意图和目的，我们可以考虑官方互联网协议定义。

尽管 HTTP/3 还不是官方的 Internet 协议，但许多公司和项目已经开始将 HTTP/3 支持添加到他们的产品中。

对 HTTP/3 的 Web 浏览器支持

在 Web 浏览器前端，Chrome v87、Firefox v88 和 Edge v87 都默认启用了 HTTP/3。 对于 Safari 用户，启用 HTTP/3 的选项已添加到 Safari Technology Preview v104。 但是，Safari 的稳定版本目前不支持 HTTP/3。

对 HTTP/3 的库支持

对于希望利用 HTTP/3 技术的开发人员，许多流行的库已经添加了对 HTTP/3 的支持。 由于 HTTP/3 仍处于 Internet 草案阶段，因此在使用以下库之一时，您需要确保已调整到最新更新。

• Python – http3 和 aioquic
• Rust – 乳蛋饼、neqo 和 quinn
• C – nghttp3 和 lsquic
• 走——quicgo
• JavaScript – Node.js

HTTP/3 的基础架构支持

在基础架构方面，Cloudflare 在其整个边缘网络中支持 HTTP/3 一直处于领先地位。 这意味着启用 Cloudflare 的站点无需任何额外工作即可利用 HTTP/3 的安全性和性能增强。

在 Kinsta，我们托管的所有网站都受到我们免费的 Cloudflare 集成的保护。 除了企业级防火墙和 DDoS 保护，Kinsta 客户还可以访问 HTTP/3！

要测试您的站点是否支持 HTTP/3，您可以使用 Geekflare 的 HTTP/3 测试工具。 只需输入您的域并按“检查 HTTP/3”按钮，该工具就会让您知道您的网站是否启用了 HTTP/3。

如果您的站点支持 HTTP/3，您应该会看到如下所示的消息。 由于 kinstalife.com 托管在 Kinsta 上，因此我们的 Cloudflare 集成完全支持 HTTP/3。

您还可以使用浏览器的检查器来检查 HTTP/3 支持。 对于本示例，我们将使用支持 HTTP/3 的最新版本的 Google Chrome。

要打开检查器，请右键单击页面并单击“检查”并导航到“网络”选项卡。 在“协议”列中，您可以看到用于连接的 HTTP 协议。 HTTP/2 连接显示为“h2”，而 HTTP/3 连接显示为“h3-XX”（XX 指的是特定的 HTTP/3 草案）。 如下图所示，kinstalife.com 支持通过“h3-29”进行连接，即“HTTP/3 Draft 29”。

现在我们已经了解了 HTTP/3 的当前状态，让我们深入了解 HTTP/2 与 HTTP/3 之间的一些差异！

一点背景知识——从 HTTP/2 开始

HTTP/2 在非阻塞下载、流水线和服务器推送方面带来了一些重大改进，帮助我们克服了底层 TCP 协议的一些限制。 它使我们能够最大限度地减少请求-响应周期和握手的次数。

HTTP/2 使得在单个 TCP 连接中推送多个资源成为可能——多路复用。 我们在静态下载的顺序上也获得了更大的灵活性，我们的页面现在不再受到下载线性进展的限制。

实际上，这意味着现在一个大型 javascript 资源不一定等于所有其他等待轮到它们的静态资源的阻塞点。

再加上 HTTP/2 的标头 HPACK 压缩和数据传输的默认二进制格式，在许多情况下，我们拥有一个明显更高效的协议。

主要的浏览器实现要求网站实现加密 - SSL - 才能获得 HTTP/2 的好处 - 有时这会产生计算开销，导致速度提升不明显。 甚至在某些情况下，用户在过渡到 HTTP/2 后报告速度变慢。

让我们说，采用此版本的早期并不是为了弱者。

Nginx 实现也缺少 server-push 特性，依赖于一个模块。 Nginx 模块不是你通常可以复制的 Apache 插件模块——NGINX 必须用这些重新编译。

虽然其中一些问题现在已经解决，但如果我们查看整个协议栈，我们会发现主要约束位于比 HTTP/2 敢于冒险的更低级别。

为了详细说明这一点，我们将从底层到顶层剖析当今的互联网协议栈。 如果您想了解更多关于 HTTP/2 的背景知识，请务必查看我们的终极 HTTP/2 指南。

互联网协议 (IP)

互联网协议 (IP) 定义了整个互联网拓扑的底部。 它是互联网堆栈的一部分，我们可以肯定地说，如果不改变一切，包括更换整个硬件基础设施，从路由器到服务器，甚至是最终用户的机器，它确实是不可协商的。

因此，虽然协议大修可能到期，但目前还没有出现如此深远的努力，主要是因为我们还没有提出一个可行的、开创性的、但向后兼容的替代方案。

我们可以将 IP 协议的起源追溯到 1974 年，由电气和电子工程师协会发表并由 Vint Cerf 和 Bob Cahn 撰写的一篇论文。 它详细说明了通过网络发送的数据包，跨 IP 地址路由它们，以及网络/网络中节点的数字定义地址。 该协议定义了这些数据包或数据报的格式——它的标头和有效负载。

在 1980 年的 RFC 760 定义之后，IETF 在其 Request For Comments 791 中采用了至今广泛使用的定义。这是该协议的第四个版本，但我们可以说它是第一个生产版本。

它使用 32 位地址，将地址数量限制在 40 亿左右。 这个限制解释了为什么非商业互联网用户从他们的 ISP 那里获得“动态 IP 地址”，而静态 IP 被认为是“附加值”并且经常需要额外收费。

他们正在配给。

不久之后，人们意识到 32 位地址是不够的，而且短缺迫在眉睫，因此发布了许多 RFC 试图解决这个问题。 尽管这些解决方案在今天被广泛使用，并且是我们日常生活的一部分，但可以肯定地说这些相当于黑客。

Internet 协议版本 6 或 IPv6 是解决这些限制的一种方式，包括逐渐被以前的版本采用。 它于 1998 年成为 IETF 的标准草案文件，并于 2017 年提升为互联网标准。

虽然 IPv4 地址空间受到其 32 位地址长度的限制，但 IPv6 标准被赋予 128 位，即 3.4 * 10 ^ 38 个可能的地址。 这应该足以维持我们相当长的一段时间。

根据谷歌和用户之间的 IPv6 连接，截至 2021 年 6 月，IPv6 的采用率刚刚超过 35%。

IP 是互联网堆栈的基本层，定义了最基本的东西，但不保证交付、数据完整性或传输数据包的顺序。 就其本身而言，它是不可靠的。 IPv4 的报头格式提供了报头校验和，传输节点使用它来验证报头的完整性。 这使得它与 IPv6 版本不同，后者依赖于下面的链路层，使其速度更快。

了解 TCP 和 UDP 的作用

现在是时候探索 HTTP/3 与 TCP 和 UDP 的匹配度了。

TCP

虽然 IP 是当今我们所有在线通信的底层，但 TCP（传输控制协议）是 Internet 协议套件的更高级别部分，提供 Web、邮件、文件传输 (FTP) 所需的可靠性 -用于互联网的应用层/协议。

这包括多步连接建立、握手、确保数据包顺序和丢失数据包的重传。 它向发件人提供交付的反馈（Acks）等。 还有校验和计算来检测错误。

所有这些都表明了使 TCP 成为可靠协议的许多步骤，使其成为我们今天使用的最臭名昭著的互联网服务的基础。

其可追溯到 1974 年 (RFC 675) 和 1981 年 (RFC 793) 的规范至今未发生重大变化。

然而，TCP 提供的可靠性并非没有代价。 握手、交付反馈、订购保证和校验和所需的所有往返开销，这些开销可能被认为是弱且冗余的。 它使 TCP 成为现代协议栈的瓶颈。 HTTP/2 已经达到了可以在 TCP 之上实现的速度提升的平稳期。

UDP

用户数据报协议 (UDP) 也是 Internet 协议套件的组成部分之一，其规范可以追溯到 1980 年 (RFC 768)。

顾名思义，它是一种基于数据报的无连接协议。 这意味着没有握手，也没有订购或交付的保证。 这意味着确保交付、数据完整性和其他事情的任何可能步骤都留给了应用程序层。 这意味着构建在 UDP 之上的应用程序可以根据具体情况选择将采用的策略，或者它可以利用链路层的元素（如校验和）来避免开销。

由于 UDP 与 TCP 一样广泛传播，因此无需在连接到 Internet 的各种设备上进行固件更新或对操作系统进行重大更改即可实现改进。

许多防火墙、NAT、路由器和其他只允许在用户和他们需要到达的服务器之间部署 TCP 或 UDP 的中间设备阻碍了新协议的部署。 – HTTP/3 解释

Hacker News 上的这个帖子可以帮助我们开始理解在现有网络堆栈之上构建新 HTTP 版本背后的原因，而不是重新发明它（尽管还有更多内容）。

UDP数据包格式规范比较少，它的包头由包头和包数据的源端口、目的端口、长度（以字节为单位）和校验和组成。 校验和可用于验证数据包标头和数据部分的数据完整性。

当底层协议层是 IPv4 时，校验和是可选的，对于 IPv6 是强制性的。 到目前为止，UDP 已被用于计算机系统时钟同步 (NTP)、VoIP 应用程序、视频流、DNS 系统和 DHCP 协议等。

QUIC 和 HTTP/3

QUIC（Quick UDP Internet Connections）由谷歌于2012年首次部署。它重新定义了网络层的边界，依赖于较低级别的UDP协议，重新定义了“用户空间”中的握手、可靠性特性和安全特性，避免了需要升级互联网系统的内核。

就像 HTTP/2（由 Google 的 SPDY 或 speedy 率先推动的进步）一样，HTTP/3 将再次建立在这些成就的基础上。

虽然 HTTP/2 确实为我们提供了多路复用，并减轻了线头阻塞，但它受到 TCP 的限制。 您可以将单个 TCP 连接用于多路复用在一起的多个流以传输数据，但是当其中一个流遭受数据包丢失时，整个连接（及其所有流）都被扣为人质，也就是说，直到 TCP 完成它的事情（重新传输丢失的数据包）。

这意味着所有数据包，即使它们已经被传输并在目标节点的缓冲区中等待，也会被阻塞，直到丢失的数据包被重新传输。 Daniel Stenberg 在他关于 http/3 的书中称其为“基于 TCP 的行头块”。 他声称，如果丢包率为 2%，用户使用 HTTP/1 会做得更好，使用六个连接来规避这种风险。

QUIC 不受此限制。 QUIC 建立在无连接的 UDP 协议上，连接的概念没有 TCP 的限制，一个流的故障也不必影响其余的流。

正如 Cloudflare 的 Lucas Pardue 所说：

专注于 UDP流，QUIC 实现了多路复用，而无需捎带一个 TCP 连接。 QUIC 在比 TCP 更高的层次上建立连接。 QUIC 连接中的新流不会被迫等待其他连接完成。 QUIC 连接还受益于取消 TCP 握手开销，从而减少延迟。

Cisco 的人制作了一段有趣的视频，解释 TCP 的 3 次握手：

虽然 QUIC 取消了 TCP 可靠性特性，但它在 UDP 层之上弥补了这一点，提供了数据包的重传、排序等。 谷歌云平台在 2018 年为其负载均衡器引入了 QUIC 支持，全球平均页面加载时间提高了 8% ，在延迟较高的地区提高了 13%。

在谷歌浏览器、YouTube、Gmail、谷歌搜索和其他服务之间，谷歌能够在互联网的一大块上部署 QUIC，而无需等待 IETF。 谷歌的工程师声称，在 2017 年，7% 的互联网流量已经通过 QUIC 进行。

Google 的 QUIC 版本只专注于 HTTP 传输，使用 HTTP/2 语法。 IETF 的人员（负责标准化 QUIC 的人员）认为，IETF 版本的 QUIC 应该能够传输的不仅仅是 HTTP。 然而，就目前而言，任何基于 QUIC 的非 HTTP 协议的工作都被搁置了。

IETF 工作组决定的另一件事是标准化版本将使用 TLS 1.3 加密而不是 Google 的自定义解决方案。 与旧版本相比，TLS 1.3 也有助于提高协议速度，因为它的握手需要更少的往返。 Kinsta 在我们所有的服务器和我们的 Kinsta CDN 上都支持 TLS 1.3。

目前，谷歌继续在其产品中使用自己的 QUIC 版本，同时将其开发工作导向 IETF 标准。 大多数其他互联网参与者都在 IETF 版本之上构建（除了加密之外，两者在其他方面有所不同）。

如果我们打开 Chrome 开发工具，并在 Network 选项卡的 Protocol 列中加载一些谷歌的产品，比如 Gmail，我们会看到很多资源正在通过谷歌版本的 QUIC 协议加载。 谷歌的产品如分析、谷歌标签管理器等也是如此。

Cloudflare 发布了关于标准化进展的非常广泛的更新。

虽然 UDP 确实为 QUIC 和 HTTP/3 提供了一些固有的优势，但它也带来了一些挑战。

TCP 多年来一直是主流协议，而 UDP 不是，因此操作系统和它的软件堆栈通常没有得到优化。 因此，据估计，QUIC 的 CPU 负载/要求要高得多，是 HTTP/2 的两倍。

优化深入到操作系统的内核，以及不同的路由器和设备固件。 这份 Red Hat 调优指南可能会为那些更倾向于技术的人提供更多关于该主题的信息。

可以说，QUIC 尝试在更小、更灵活的协议之上重新设计 TCP 功能。

我们前面提到的 QUIC 连接结合了 TLS 和传输握手。 一旦建立，它们将由唯一的 CID（连接 ID）标识。 这些 ID 在 IP 更改中持续存在，并且可以帮助确保不间断的下载，例如从 4G 切换到 WiFi。 这是相关的，特别是因为越来越多的互联网流量是在移动设备上进行的。 可能会出现问题，谷歌是否构思了这个元素来促进更好地跨不同连接和互联网提供商的用户跟踪。

TLS 是强制性的，旨在使中间设备难以篡改或嗅探流量。 这就是为什么经常看到防火墙提供商和供应商（如 Cisco）将 UDP 协议视为一个问题，并提供禁用它的方法。 中间商更难检查、监督或过滤 QUIC 流量。

QUIC 流通过 QUIC 连接发送，单向或双向。 流具有标识发起者的 ID，以及流是单向的还是双向的，并且还提供流内流控制。

QUIC 是传输层协议，而 HTTP 是其之上的层，即应用层协议或应用程序协议。

由于向后兼容至关重要，IETF 推动了 HTTP/3 的实现，并将在响应中包含旧版本（HTT1 或 HTTP/2）。 它将包含一个标头，通知客户端 HTTP/3 可用，以及端口/主机信息，如 RFC 7838 中所述。

这与 HTTP/2 不同，后者可以在 TLS 握手中协商传输。 但由于 IETF 几乎采用了基于 QUIC 的 HTTP/3 作为下一个标准，我们可以预期 Web 客户端会越来越多地期望对 HTTP/3 的支持。 客户端可以缓存来自先前 HTTP/3 连接的数据，并在后续访问同一主机时直接连接（零往返或 0-RTT）。

概括

有人认为，由于 HTTP/2 标准尚未完全采用，现在广泛推动 HTTP/3 可能还为时过早。 这是一个有效的观点，但是，正如我们所提到的，这个协议已经看到了大规模的测试和实现。 谷歌早在 2015 年就开始对其进行测试，Facebook 也于 2017 年开始对其进行测试。

2022 年，我们获得了来自 Google Chrome 和 Brave 等主要浏览器的 HTTP/3 支持。 在基础设施方面，像 Litespeed 和 Nginx 这样的网络服务器都有 HTTP/3 的工作实现，而像 Cloudflare 这样的网络提供商已经部署了对 HTTP/3 的全面支持。

目前，HTTP/3 仍处于 Internet Draft 阶段，最新的修订版将于 2021 年 8 月到期。今年将是令人兴奋的，因为我们可以期待看到主要软件供应商实施新版本的举措标准。