1.1.2.2 [一步步跑完前端学习路线] 前端内容系统化梳理-Internet-应用层-HTTPS/3协议-实用部署选项

一念一梦
230 阅读50分钟

引言

本文是一篇外文翻译，原文是由Robin Marx所写，他是一位深入研究HTTP/3和QUIC的Web 性能的网络协议研究员。

他将分三个以下部分深入探讨HTTP/3的内容：

本文即为第三部分内容的翻译，旨在知识传播。

开始

大家好，欢迎来到这个由三部分组成的关于新 HTTP/3 和 QUIC 协议的系列的最后一部分！如果在前两部分 — HTTP/3 历史和核心概念以及 HTTP/3 性能特性 — 之后，您确信开始使用新协议是个好主意（您应该如此），那么最后一部分包括您开始之前需要了解的所有信息！

首先，我们将讨论您需要对页面和资源进行哪些更改才能以最佳方式使用新协议（这是最简单的部分）。接下来，我们将了解如何设置服务器和客户端（除非您使用的是内容分发网络 （CDN），否则这是困难的部分）。最后，我们将看到您可以使用哪些工具来评估新协议对性能的影响（至少目前这几乎是不可能的部分）。

页面和资源的更改 #

让我们从一些好消息开始：如果您已经使用 HTTP/2，那么在迁移到 HTTP/3 时，您可能不需要对页面或资源进行任何更改！ 这是因为，正如我们在 第1 部分和第 2 部分中所解释的那样，HTTP/3 实际上更像是 HTTP/2-over-QUIC，并且两个版本的高级功能保持不变。因此，对 HTTP/2 所做的任何更改或优化仍适用于 HTTP/3，反之亦然。

但是，如果您仍在使用 HTTP/1.1，或者您已经忘记了向 HTTP/2 的过渡，或者您从未真正针对 HTTP/2 进行调整，那么您可能想知道这些更改是什么以及为什么需要它们。然而，即使在今天，您也很难找到一篇详细介绍细微最佳实践的好文章。这是因为，正如我在 第1 部分的引言中所说，许多早期的 HTTP/2 内容对它在实践中的效果过于乐观，坦率地说，其中一些内容存在重大错误和糟糕的建议。可悲的是，这些错误信息大多今天仍然存在。这是我撰写 HTTP/3 系列文章的主要动机之一，以帮助防止这种情况再次发生。

目前，我能推荐的最好的 HTTP/2 一体化细致入微的来源是 Barry Pollard 的 HTTP/2 in Action 一书。但是，由于这是一个付费资源，我不希望您在这里猜测，因此我在下面列出了一些要点，以及它们与 HTTP/3 的关系：

1. 单个连接 #

HTTP/1.1 和 HTTP/2 之间的最大区别是从 6 个并行 TCP 连接切换到 30 个并行 TCP 连接，以及单个底层 TCP 连接。我们在第 2 部分中讨论了单个连接如何仍然与多个连接一样快，因为拥塞控制如何导致更多或更早的数据包丢失和更多的连接（这抵消了它们聚合的更快启动的好处）。HTTP/3 继续这种方法，但“只是”从一个 TCP 切换到一个 QUIC 连接。这种差异本身并没有太大作用（它主要减少了服务器端的开销），但它导致了以下大部分要点。

2. 服务器分片和连接合并 #

在实践中，切换到单一连接设置非常困难，因为许多页面被分片在不同的主机名甚至服务器（如 img1.example.com 和 img2.example.com）之间。这是因为浏览器最多只能为每个主机名打开六个连接，因此拥有多个连接可以允许更多连接！如果不更改此 HTTP/1.1 设置，HTTP/2 仍将打开多个连接，从而降低其他功能（例如优先级（见下文））的实际工作能力。

因此，最初的建议是撤消服务器分片并尽可能在单个服务器上整合资源。HTTP/2 甚至提供了一项功能，可以更轻松地从 HTTP/1.1 设置过渡，称为连接合并。粗略地说，如果两个主机名解析为相同的服务器 IP（使用 DNS）并使用类似的 TLS 证书，那么浏览器甚至可以在两个主机名之间重用单个连接。

在实践中，连接合并可能很难正确处理，例如，由于涉及 CORS 的几个细微的安全问题。即使您设置正确，您仍然很容易以两个单独的连接结束。问题是，这并不总是坏事。首先，由于优先级和多路复用实施不佳（见下文），单个连接很容易比使用两个或更多连接慢。其次，使用过多的连接可能会因竞争拥塞控制器而导致早期数据包丢失。但是，仅使用几个（但仍然不止一个）可以很好地平衡拥塞增长和更好的性能，尤其是在高速网络上。由于这些原因，我相信即使使用 HTTP/2，一点分片仍然是一个好主意（比如，两到四个连接）。事实上，我认为大多数现代 HTTP/2 设置的性能都与它们一样好，因为它们的关键路径中仍然有一些额外的连接或第三方负载。

3. 资源捆绑和内联 #

在 HTTP/1.1 中，每个连接只能有一个活动资源，从而导致 HTTP 级别的队头 （HoL） 阻塞。由于连接数的上限为 6 到 30 个，因此资源捆绑（将较小的子资源合并为单个较大的资源）是长期的最佳实践。我们今天仍然在 Webpack 等打包器中看到这一点。同样，资源通常在其他资源中内联（例如，关键 CSS 在 HTML 中内联）。

但是，使用 HTTP/2 时，单个连接可以多路复用资源，因此您可以对文件发出更多未完成的请求（换句话说，单个请求不再占用您宝贵的少数连接之一）。这最初被解释为“我们不再需要为 HTTP/2 捆绑或内联我们的资源”。这种方法被吹捧为更适合细粒度缓存，因为每个子资源都可以单独缓存，如果其中一个子资源发生更改，则不需要重新下载整个捆绑包。这是真的，但程度相对有限。

例如，您可以降低压缩效率，因为这样可以更好地处理更多数据。此外，每个额外的请求或文件都有固有的开销，因为它需要由浏览器和服务器处理。例如，与几个大文件相比，数百个小文件的成本可能会加起来。在我们自己的早期测试中，我发现大约 40 个文件的回报严重递减。尽管这些数字现在可能更高一些，但 HTTP/2 中的文件请求仍然没有最初预测的那么便宜。最后，不内联资源会增加延迟成本，因为需要请求文件。这与优先级和服务器推送问题（见下文）相结合，意味着即使在今天，你仍然最好内联一些关键的 CSS。也许有一天 Resource Bundles 提案会对此有所帮助，但目前还没有。

当然，所有这一切对于 HTTP/3 来说仍然适用。 尽管如此，我还是读到有人声称许多小文件会比 QUIC 更好，因为更多并发活动的独立流意味着从 HoL 阻塞移除中获得更多利润（正如我们在第 2 部分中讨论的那样）。我认为这可能有一定的道理，但是，正如我们在第 2 部分中所看到的，这是一个高度复杂的问题，有很多移动参数。我不认为好处会超过所讨论的其他成本，但需要更多的研究。（一个离谱的想法是让每个文件的大小都精确到适合单个 QUIC 数据包中，完全绕过 HoL 阻塞。我将接受任何实施执行此操作的资源捆绑程序的初创公司的版税。;))

4. 优先级 #

为了能够在单个连接上下载多个文件，您需要以某种方式对它们进行多路复用。正如第 2 部分所讨论的，在 HTTP/2 中，这种多路复用是使用其优先级系统进行控制的。这就是为什么在同一连接上请求尽可能多的资源很重要的原因 - 以便能够在彼此之间正确地确定它们的优先级！然而，正如我们所看到的，这个系统非常复杂，导致它在实践中经常被错误地使用和实施（见下图）。反过来，这意味着 HTTP/2 的其他一些建议（例如减少捆绑，因为请求成本低，减少服务器分片，以最佳地利用单个连接（见上文）——在实践中表现不佳。

实施不当的 HTTP/2 堆栈可能会导致高优先级资源（底部两个）延迟到其他低优先级下载（所有其他下载）之后。（图片来源：Andy Davies）（大预览）

遗憾的是，作为普通的 Web 开发人员，这是您无能为力的事情，因为它主要是浏览器和服务器本身的问题。但是，您可以尝试通过不使用太多单个文件（这将降低竞争优先级的机会）并仍然使用（有限的）分片来缓解此问题。另一种选择是使用各种影响优先级的技术，例如延迟加载、JavaScript async 和 defer，以及资源提示，例如 preload。在内部，这些主要更改资源的优先级，以便它们提前或延迟发送。但是，这些机制可能会 （并且确实） 受到错误的影响。此外，不要指望在一堆资源上预加载并让事情变得更快：如果一切都突然成为高优先级，那么什么都没有！通过使用 preload 之类的东西，甚至很容易延迟实际关键的资源。

正如第 2 部分所解释的，HTTP/3 从根本上改变了这个优先级系统的内部结构。我们希望这意味着它的实际部署会少很多 bug 和问题，所以至少应该解决一部分问题。但是，我们还不能确定，因为目前很少有 HTTP/3 服务器和客户端完全实现此系统。尽管如此，优先级的基本概念不会改变。如果不真正了解内部发生的情况，您仍然无法使用 preload 等技术，因为它可能仍然会错误地确定资源的优先级。

5. 服务器推送和首次飞行 #

服务器推送允许服务器发送响应数据，而无需先等待来自客户端的请求。同样，这在理论上听起来很棒，并且可以使用它来代替内联资源（见上文）。但是，正如第 2 部分所讨论的，由于拥塞控制、缓存、优先级和缓冲方面的问题，push 很难正确使用。总的来说，最好不要将其用于一般网页加载，除非你真的知道自己在做什么，即使那样它也可能是一个微优化。不过，我仍然相信它可以在 （REST） API 中占有一席之地，您可以在其中将 （JSON） 响应中链接到的子资源推送到预热连接上。HTTP/2 和 HTTP/3 都是如此。

概括一下，我觉得可以对 TLS 会话恢复和 0-RTT 做出类似的评论，无论是通过 TCP + TLS 还是通过 QUIC。如第 2 部分所述，0-RTT 类似于服务器推送（通常使用），因为它会尝试加速页面加载的最初阶段。然而，这意味着它当时所能实现的目标同样有限（出于安全考虑，在 QUIC 中更是如此）。因此，微优化是您可能需要在低级别上微调事物才能真正从中受益的方式。想想我曾经非常兴奋地尝试将服务器推送与 0-RTT 相结合。

这一切意味着什么？#

以上所有内容都归结为一个简单的经验法则：应用您在网上找到的大多数典型 HTTP/2 建议，但不要将它们走极端。

以下是一些主要适用于 HTTP/2 和 HTTP/3 的具体要点：

  1. 在关键路径上通过大约一到三个连接对资源进行分片（除非您的用户主要使用低带宽网络），并在需要时使用 preconnect 和 dns-prefetch。
  2. 按路径或功能或更改频率以逻辑方式捆绑子资源。每页 5 到 10 个 JavaScript 和 5 到 10 个 CSS 资源应该就可以了。内联关键 CSS 仍然是一个很好的优化。
  3. 请谨慎使用复杂功能，例如预加载。
  4. 使用正确支持 HTTP/2 优先级的服务器。对于 HTTP/2，我建议使用 H2O。Apache 和 NGINX 大多没问题（尽管可以做得更好），而 HTTP/2 则要避免Node.js。对于 HTTP/3，目前情况不太清楚（见下文）。
  5. 确保您的 HTTP/2 Web 服务器上启用了 TLS 1.3。

正如你所看到的，虽然远非简单，但针对 HTTP/3（和 HTTP/2）优化页面并不是火箭科学。但是，更困难的是正确设置 HTTP/3 服务器、客户端和工具。

服务器和网络 #

正如您现在可能已经了解的那样，QUIC 和 HTTP/3 是相当复杂的协议。从头开始实施它们将涉及阅读（和理解！数百页分布在超过 7 个文档中。幸运的是，多家公司已经致力于开源 QUIC 和 HTTP/3 实施五年多了，因此我们有几个成熟而稳定的选项可供选择。

一些最重要和最稳定的包括：

  语言  实现
Goquic-go
Rustquiche (Cloudflare), Quinn, Neqo (Mozilla)
C and C++mvfst (Facebook), MsQuic, (Microsoft), (Google), ngtcp2, LSQUIC (Litespeed), picoquic, quicly (Fastly)

但是，这些实现中的许多（也许是大多数）主要处理 HTTP/3 和 QUIC 内容;它们本身并不是真正成熟的 Web 服务器。当涉及到您的典型服务器（想想 NGINX、Apache Node.js）时，由于多种原因，事情会稍微慢一些。首先，他们的开发人员从一开始就很少参与 HTTP/3，现在他们必须迎头赶上。许多人通过使用上面列出的 implementations 之一作为库来绕过这一点，但即使是这种集成也很困难。

其次，许多服务器依赖于第三方 TLS 库，例如 OpenSSL。这也是因为 TLS 非常复杂并且必须安全，因此最好重用现有的、经过验证的工作。但是，虽然 QUIC 与 TLS 1.3 集成，但它的使用方式与 TLS 和 TCP 的交互方式大不相同。这意味着 TLS 库必须提供特定于 QUIC 的 API，而他们的开发人员长期以来一直不愿意或迟迟没有这样做。这里的问题尤其在于 OpenSSL，它推迟了对 QUIC 的支持，但它也被许多服务器使用。这个问题变得如此严重，以至于 Akamai 决定启动一个特定于 QUIC 的 OpenSSL 分支，称为 quictls。虽然存在其他选项和解决方法，但 TLS 1.3 对 QUIC 的支持仍然是许多服务器的障碍，并且预计会在一段时间内保持这种状态。

您应该能够开箱即用的完整 Web 服务器的部分列表及其当前的 HTTP/3 支持如下：

  • Apache
    目前尚不清楚支持情况。目前还没有宣布任何消息。它可能还需要 OpenSSL。（请注意，有一个 Apache Traffic Server 实现。
  • NGINX
    这是一个自定义实现。这是相对较新的，并且仍然处于高度实验阶段。预计到 2021 年底将合并到主线 NGINX 中。这是相对较新的，并且仍然处于高度实验阶段。请注意，还有一个补丁可以在 NGINX 上运行 Cloudflare 的 quiche 库，目前可能更稳定。
  • Node.js
    这在内部使用 ngtcp2 库。它被 OpenSSL 进度阻止了，尽管他们计划切换到 QUIC-TLS 分支以更快地工作。
  • IIS公司
    目前尚不清楚支持情况，也尚未宣布任何消息。不过，它可能会在内部使用 MsQuic 库。
  • Hypercorn 这将 aioquic 与实验性支持集成在一起。
  • Caddy 它使用 quic-go，并提供完全支持。
  • H2O
    这使用 quicly，并得到完全支持。
  • Litespeed 它使用 LSQUIC，并提供完全支持。

请注意一些重要的细微差别：

  • 即使是“完全支持”也意味着“目前为止”，而不一定是“生产就绪”。例如，许多实现尚不完全支持连接迁移、0-RTT、服务器推送或 HTTP/3 优先级。
  • 其他未列出的服务器，例如 Tomcat，（据我所知）尚未发布任何公告。
  • 在列出的 Web 服务器中，只有 Litespeed、Cloudflare 的 NGINX 补丁和 H2O 是由密切参与 QUIC 和 HTTP/3 标准化的人员制作的，因此它们最有可能在早期效果最佳。

如您所见，服务器环境尚未完全实现，但肯定已经有设置 HTTP/3 服务器的选项。但是，简单地运行服务器只是第一步。配置它和网络的其余部分更加困难。

网络配置 #

如第 1 部分所述，QUIC 在 UDP 协议上运行，使其更易于部署。然而，这主要只是意味着大多数网络设备都可以解析和理解 UDP。遗憾的是，这并不意味着 UDP 是普遍允许的。由于 UDP 通常用于攻击，并且除了 DNS 之外对正常的日常工作并不重要，因此许多（公司）网络和防火墙几乎完全阻止了该协议。因此，可能需要明确允许 UDP 传入/传出您的 HTTP/3 服务器。QUIC 可以在任何 UDP 端口上运行，但端口 443（通常用于 TCP 上的 HTTPS）是最常见的。

但是，许多网络管理员不希望只允许 UDP 批发。相反，他们将特别希望允许 QUIC 而不是 UDP。问题是，正如我们所看到的，QUIC 几乎是完全加密的。这包括 QUIC 级别的元数据，例如数据包编号，但也包括指示连接关闭的信号。对于 TCP，防火墙会主动跟踪所有这些元数据以检查预期行为。（在传输数据数据包之前，我们是否看到过完整的握手？数据包是否遵循预期的模式？有多少个打开的连接？正如我们在第 1 部分中看到的，这正是 TCP 实际上不再可演化的原因之一。但是，由于 QUIC 的加密，防火墙可以执行的这种连接级跟踪逻辑要少得多，并且它们可以检查的少数位相对复杂。

因此，许多防火墙供应商目前建议阻止 QUIC，直到他们可以更新其软件。但是，即使在那之后，许多公司可能也不想允许它，因为防火墙 QUIC 支持总是比他们习惯的 TCP 功能少得多。

连接迁移功能使这一切变得更加复杂。正如我们所看到的，此功能允许使用连接 ID （CID） 从新的 IP 地址继续连接，而无需执行新的握手。但是，对于防火墙来说，这看起来就像在没有先使用握手的情况下使用了新连接，这很可能是攻击者发送恶意流量。防火墙不能只使用 QUIC CID，因为它们也会随着时间的推移而变化以保护用户的隐私！因此，服务器需要与防火墙通信，了解需要哪些 CID，但这些都不存在。

对于更大规模设置的负载均衡器，也存在类似的担忧。这些计算机将传入连接分发到大量后端服务器上。当然，一个连接的流量必须始终路由到同一后端服务器（其他连接不知道该如何处理它！对于 TCP，这可以简单地基于 4 元组完成，因为它永远不会改变。但是，使用 QUIC 连接迁移时，这不再是一种选择。同样，服务器和负载均衡器需要以某种方式就选择哪些 CID 达成一致，以便允许确定性路由。然而，与防火墙配置不同的是，已经有一个设置此功能的提案（尽管这远未广泛实现）。

最后，还有其他更高级别的安全注意事项，主要围绕 0-RTT 和分布式拒绝服务 （DDoS） 攻击。正如第 2 部分所讨论的，QUIC 已经包含了相当多的针对这些问题的缓解措施，但理想情况下，它们还将在网络上使用额外的防线。例如，代理或边缘服务器可能会阻止某些 0-RTT 请求到达实际后端，以防止重放攻击。或者，为了防止仅发送第一个握手数据包然后停止回复的反射攻击或 DDoS 攻击（在 TCP 中称为 SYN 泛洪），QUIC 包含重试功能。这允许服务器验证它是否是一个行为良好的客户端，而不必在此期间保留任何状态（相当于 TCP SYN cookie）。当然，此重试过程最好发生在后端服务器之前的某个位置，例如，在负载均衡器处。不过，这需要额外的配置和通信来设置。

这些只是网络和系统管理员在使用 QUIC 和 HTTP/3 时遇到的最突出问题。还有几个，其中一些我已经谈到了。QUIC RFC 还有两个单独的随附文档，讨论了这些问题及其可能的（部分）缓解措施。

这一切意味着什么？#

HTTP/3 和 QUIC 是复杂的协议，依赖于许多内部机制。并非所有这些都准备好迎接黄金时段，尽管您已经有一些选择可以在后端部署新协议。但是，最著名的服务器和底层库（例如 OpenSSL）可能需要几个月甚至几年的时间才能更新。

即便如此，正确配置服务器和其他网络中介，以便可以以安全和最佳的方式使用协议，在更大规模的设置中也并非易事。您需要一个优秀的开发和运营团队来正确进行此过渡。

因此，尤其是在早期，最好依靠大型托管公司或 CDN 来为您设置和配置协议。正如第 2 部分所讨论的，无论如何，这就是 QUIC 最有可能获得回报的地方，使用 CDN 是您可以进行的关键性能优化之一。我个人推荐使用 Cloudflare 或 Fastly，因为它们一直密切参与标准化过程，并且将拥有最先进和经过充分调整的实施。

客户端和 QUIC 发现 #

到目前为止，我们已经考虑了对新协议的服务器端和网络内支持。但是，客户方面也需要克服几个问题。

在此之前，让我们从一些好消息开始：大多数流行的浏览器已经具有（实验性）HTTP/3 支持！ 具体来说，在撰写本文时，以下是支持状态（另请参见 caniuse.com）：

浏览器对 HTTP/3 的支持已经相当成熟。（来源： caniuse.com）（大预览）

  • Google Chrome（版本 91+）： 默认启用。
  • Mozilla Firefox（版本 89+）： 默认启用。
  • Microsoft Edge（版本 90+）： 默认启用（内部使用 Chromium）。
  • Opera（版本 77+）： 默认启用（内部使用 Chromium）。
  • Apple Safari（版本 14）： 在手动标记后面。将在版本 15 中默认启用，该版本目前处于技术预览阶段。
  • 其他浏览器：目前还没有我知道的信号（尽管其他内部使用 Chromium 的浏览器，例如 Brave，理论上也可以开始启用它）。

  请注意一些细微差别：

  • 大多数浏览器都是逐步推出的，因此并非所有用户都会从一开始就默认启用 HTTP/3 支持。这样做是为了限制单个被忽视的 bug 可能影响许多用户或 Server 部署过载的风险。因此，即使在最近的浏览器版本中，您也很有可能默认无法获得 HTTP/3，而必须手动启用它。
  • 与服务器一样，HTTP/3 支持并不意味着目前已实现或正在使用所有功能。特别是，0-RTT、连接迁移、服务器推送、动态 QPACK 标头压缩和 HTTP/3 优先级可能仍缺失、禁用、使用较少或配置不佳。
  • 如果要在浏览器外部（例如，在本机应用程序中）使用客户端 HTTP/3，则必须集成上面列出的库之一或使用 cURL。Apple 将很快将原生 HTTP/3 和 QUIC 支持引入 macOS 和 iOS 上的内置网络库，Microsoft 正在将 QUIC 添加到 Windows 内核及其 .NET 环境中，但（据我所知）尚未宣布类似的原生支持用于 Android 等其他系统。

Alt-Svc #

即使您已经设置了兼容 HTTP/3 的服务器并使用更新的浏览器，您也可能会惊讶地发现 HTTP/3 实际上并没有得到一致的使用。为了理解原因，我们假设您暂时是浏览器。您的用户要求您导航到 example.com（您以前从未访问过的网站），并且您已使用 DNS 将其解析为 IP。您可以向该 IP 发送一个或多个 QUIC 握手数据包。现在有几件事可能会出错：

  1. 服务器可能不支持 QUIC。
  2. 其中一个中间网络或防火墙可能会完全阻止 QUIC 和/或 UDP。
  3. 握手数据包可能会在传输过程中丢失。

但是，您如何知道发生了这些问题中的（哪一个） 呢？在这三种情况下，您都不会收到对握手数据包的回复。您唯一能做的就是等待，希望回复仍然可能进来。然后，经过一段时间（超时）后，您可能会认为 HTTP/3 确实存在问题。此时，您将尝试打开与服务器的 TCP 连接，希望 HTTP/2 或 HTTP/1.1 能够正常工作。

如您所见，这种方法可能会带来重大延迟，尤其是在许多服务器和网络尚不支持 QUIC 的最初几年。一个简单但天真的解决方案是同时打开 QUIC 和 TCP 连接，然后使用先完成的握手。这种方法被称为 “连接赛车” 或 “快乐眼球”。虽然这当然是可能的，但它确实有相当大的开销。即使丢失的连接几乎立即关闭，它仍然会占用客户端和服务器上的一些内存和 CPU 时间（尤其是在使用 TLS 时）。最重要的是，这种方法还存在其他问题，包括 IPv4 与 IPv6 网络以及前面讨论的重放攻击（我的演讲将更详细地介绍）。

因此，对于 QUIC 和 HTTP/3，浏览器宁愿谨慎行事，只有在知道服务器支持 QUIC 的情况下才尝试 QUIC。因此，首次联系新服务器时，浏览器将仅通过 TCP 连接使用 HTTP/2 或 HTTP/1.1。然后，服务器可以让浏览器知道它也支持 HTTP/3 进行后续连接。这是通过在通过 HTTP/2 或 HTTP/1.1 发送回的响应上设置特殊的 HTTP 标头来完成的。这个头文件被称为 Alt-Svc，代表 “alternative services”。Alt-SVC 可以用来让浏览器知道某个服务也可以通过另一个服务器（IP 和/或端口）访问，但它也允许指示替代协议。这可以在下面的图 1 中看到。

Facebook indicates Alt-Svc for its home page

图 1：Facebook 包含一个 Alt-SVC 标头，通知浏览器也可以通过 UDP 端口 443 上的 HTTP/3 访问它（有效期为 3600 秒）。目前，协议名称仍然是 h3-29 或 h3-27（HTTP/3 的第 29 版和第 27 版草案），但这最终将变成 h3（一些服务器，如 google.com，今天已经在使用 h3）。（大预览）

在收到指示 HTTP/3 支持的有效 Alt-Svc 标头后，浏览器将缓存此标头并尝试从那时起设置 QUIC 连接。一些客户端会尽快执行此操作（即使在初始页面加载期间 - 见下文），而其他客户端将等到现有的 TCP 连接关闭。这意味着浏览器只有在首先通过 HTTP/2 或 HTTP/1.1 下载了至少一些资源后才会使用 HTTP/3。即便如此，也不是一帆风顺的。浏览器现在知道服务器支持 HTTP/3，但这并不意味着中间网络不会阻止它。因此，在实践中仍然需要连接赛车。因此，如果网络以某种方式将 QUIC 握手延迟得足够长，您最终可能仍然会得到 HTTP/2。此外，如果 QUIC 连接连续几次建立失败，一些浏览器会在一段时间内将 Alt-SVC 缓存条目放在黑名单上，暂时不尝试 HTTP/3。因此，如果出现问题，手动清除浏览器的缓存可能会有所帮助，因为这也会清空 Alt-SVC 绑定。最后，Alt-SVC 已被证明会带来一些严重的安全风险。因此，一些浏览器对可以使用哪些端口提出了额外的限制（在 Chrome 中，你的 HTTP/2 和 HTTP/3 服务器需要都位于低于 1024 的端口上，或者两者都位于高于或等于 1024 的端口上，否则 Alt-SVC 将被忽略）。所有这些逻辑在浏览器之间变化和变化很大，这意味着获得一致的 HTTP/3 连接可能很困难，这也使得测试新设置变得具有挑战性。

正在进行的工作在一定程度上改进这个两步的 Alt-SVC 过程。这个想法是使用称为 SVCB 和 HTTPS 的新 DNS 记录，它们将包含类似于 Alt-SVC 中的信息。因此，客户端可以在 DNS 解析步骤中发现服务器支持 HTTP/3，这意味着它可以从第一次页面加载开始尝试 QUIC，而不必首先通过 HTTP/2 或 HTTP/1.1。有关此内容和 Alt-SVC 的更多信息，请参阅去年的 Web Almanac 关于 HTTP/2 的章节。

如您所见，Alt-Svc 和 HTTP/3 发现过程为本已具有挑战性的 QUIC 服务器部署增加了一层复杂性，因为：

  • 您始终需要将 HTTP/3 服务器部署在 HTTP/2 和/或 HTTP/1.1 服务器旁边;
  • 您需要配置 HTTP/2 和 HTTP/1.1 服务器，以便在其响应中设置正确的 Alt-SVC 标头。

虽然这在生产级设置中应该是可管理的（因为，例如，单个 Apache 或 NGINX 实例可能会同时支持所有三个 HTTP 版本），但在 （本地）测试设置中可能会更烦人（我已经可以看到自己忘记添加 Alt-SVC 标头或弄乱它们）。由于（当前）缺乏浏览器错误日志和 DevTools 指示器，这个问题变得更加复杂，这意味着弄清楚设置不起作用的确切原因可能很困难。

其他问题 #

似乎这还不够，另一个问题将使本地测试变得更加困难：Chrome 使您很难将自签名的 TLS 证书用于 QUIC。这是因为公司经常使用非官方 TLS 证书来解密员工的 TLS 流量（例如，他们可以让防火墙扫描加密流量）。但是，如果公司开始使用 QUIC 来做这件事，我们将再次拥有自定义的中间盒实现，它们对协议做出自己的假设。这可能会导致他们将来可能会破坏协议支持，而这正是我们最初通过如此广泛地加密 QUIC 来试图防止的！因此，Chrome 对此采取了非常固执己见的立场：如果您没有使用官方 TLS 证书（由 Chrome 信任的证书颁发机构或根证书签名，例如 Let's Encrypt），那么您就不能使用 QUIC。遗憾的是，这还包括自签名证书，这些证书通常用于本地测试设置。

仍然可以通过一些奇怪的命令行标志（因为常见的 --ignore-certificate-errors 还不适用于 QUIC）、使用每个开发人员的证书（尽管设置这可能很乏味）或通过在开发 PC 上设置真正的证书（但这很少适用于大型团队，因为您必须与每个开发人员共享证书的私钥）来绕过这一点。最后，虽然您可以安装自定义根证书，但还需要在启动 Chrome 时同时传递 --origin-to-force-quic-on 和 --ignore-certificate-errors-spki-list 标志（见下文）。幸运的是，目前只有 Chrome 如此严格，希望它的开发人员会随着时间的推移放宽他们的方法。

如果您在浏览器中设置 QUIC 时遇到问题，最好先使用 cURL 等工具进行验证。cURL 具有出色的 HTTP/3 支持（您甚至可以在两个不同的底层库之间进行选择），并且还使观察 Alt-Svc 缓存逻辑变得更加容易。

这一切意味着什么？#

除了在服务器端设置 HTTP/3 和 QUIC 所涉及的挑战外，让浏览器始终如一地使用新协议也存在困难。这是由于涉及 Alt-SVC HTTP 标头的两步发现过程，以及 HTTP/2 连接不能简单地“升级”为 HTTP/3 的事实，因为后者使用 UDP。

然而，即使服务器支持 HTTP/3，客户端（和网站所有者）也需要处理中间网络可能会阻止 UDP 和/或 QUIC 流量的事实。因此，HTTP/3 永远不会完全取代 HTTP/2。在实践中，对于首次访问的访客和非宽松网络上的访客来说，保持良好的 HTTP/2 设置仍然是必要的。幸运的是，正如我们所讨论的，HTTP/2 和 HTTP/3 之间不应该有太多的页面级变化，所以这应该不是一个令人头疼的问题。

但是，测试和验证您是否使用了正确的配置以及协议是否按预期使用，这可能会成为一个问题。在生产中是如此，尤其是在本地设置中。因此，我预计大多数人将继续运行 HTTP/2（甚至 HTTP/1.1）开发服务器，仅在以后的部署阶段切换到 HTTP/3。然而，即便如此，使用最新一代的工具验证协议性能也并非易事。

工具和测试 #

与许多主要服务器的情况一样，最流行的 Web 性能测试工具的制造商从一开始就没有跟上 HTTP/3 的步伐。因此，截至 2021 年 7 月，很少有工具专门支持新协议，尽管它们在一定程度上支持新协议。

Google Lighthouse #

首先，有 Google Lighthouse 工具套件。虽然总的来说，这是一个了不起的 Web 性能工具，但我一直发现它在协议性能方面有些欠缺。这主要是因为它在浏览器中以相对不切实际的方式模拟慢速网络（与 Chrome 的 DevTools 处理此问题的方式相同）。虽然这种方法非常有用，并且通常“足够好”，可以了解慢速网络的影响，但测试低级协议差异还不够现实。由于浏览器无法直接访问 TCP 堆栈，因此它仍然会在您的正常网络上下载页面，然后人为地延迟数据到达必要的浏览器逻辑。这意味着，例如，Lighthouse 仅模拟延迟和带宽，而不模拟数据包丢失（正如我们所看到的，这是 HTTP/3 可能与 HTTP/2 不同的一个主要点）。或者，Lighthouse 使用非常先进的模拟模型来猜测实际的网络影响，因为，例如，Google Chrome 有一些复杂的逻辑，如果检测到网络速度较慢，它会调整页面加载的多个方面。据我所知，此模型尚未调整为处理 IETF QUIC 或 HTTP/3。因此，如果您现在使用 Lighthouse 的唯一目的是比较 HTTP/2 和 HTTP/3 性能，那么您可能会得到错误或过于简化的结果，这可能会导致您对 HTTP/3 在实践中可以为您的网站做什么得出错误的结论。 一线希望是，从理论上讲，这在未来可以得到大规模的改进，因为浏览器确实可以完全访问 QUIC 堆栈，因此 Lighthouse 可以为 HTTP/3 添加更高级的模拟（包括数据包丢失！不过，就目前而言，虽然 Lighthouse 理论上可以通过 HTTP/3 加载页面，但我建议不要这样做。

  网页测试 #

其次，有 WebPageTest。这个了不起的项目可让您通过真实网络从世界各地的真实设备加载页面，它还允许您在顶部添加数据包级网络仿真，包括数据包丢失等方面！因此，WebPageTest 在概念上处于用于比较 HTTP/2 和 HTTP/3 性能的主要位置。然而，虽然它确实已经可以通过新协议加载页面，但 HTTP/3 尚未正确集成到工具或可视化中。例如，目前没有简单的方法可以强制通过 QUIC 加载页面，轻松查看 Alt-SVC 的实际使用情况，甚至无法查看 QUIC 握手的详细信息。在某些情况下，即使查看响应使用的是 HTTP/3 还是 HTTP/2 也可能具有挑战性。尽管如此，在 4 月份，我还是能够使用 WebPageTest 在 facebook.com 上运行相当多的测试，并查看 HTTP/3 的实际应用，我现在将对此进行介绍。

首先，我对 facebook.com 运行了一个默认测试，启用了 “repeat view” 选项。如上所述，我希望第一个页面加载使用 HTTP/2，其中将包括 Alt-SVC 响应标头。因此，重复视图应从一开始就使用 HTTP/3。在 Firefox 版本 89 中，这或多或少是这样。然而，当查看单个响应时，我们发现即使在第一个页面加载期间，Firefox 也会切换到使用 HTTP/3 而不是 HTTP/2！如图 2 所示，这种情况从第 20 个资源开始发生。这意味着 Firefox 在看到 Alt-SVC 标头后立即建立一个新的 QUIC 连接，并在成功后切换到该连接。如果您向下滚动到连接视图，它似乎还显示 Firefox 甚至打开了两个 QUIC 连接：一个用于有凭证的 CORS 请求，一个用于无 CORS 请求。这是意料之中的，因为正如我们上面所讨论的，即使对于 HTTP/2 和 HTTP/3，出于安全考虑，浏览器也会打开多个连接。但是，由于 WebPageTest 未在此视图中提供更多详细信息，因此如果不手动挖掘数据，则很难确认。查看重复视图（第二次访问），它首先直接使用 HTTP/3 作为第一个请求，正如预期的那样。

Firefox starts with HTTP/2, then switches to HTTP/3

图 2：Firefox 在第一个页面加载的中途切换到使用 HTTP/3。（大预览）

接下来，对于 Chrome，我们看到第一个页面加载的行为类似，尽管这里 Chrome 已经打开了第 10 个资源，这比 Firefox 早得多。这里更不清楚它是尽快切换还是仅在需要新连接时切换（例如，对于具有不同凭据的请求），因为与 Firefox 不同，连接视图似乎也不显示多个 QUIC 连接。对于重复视图，我们看到了一些更奇怪的事情。出乎意料的是，Chrome 也开始使用 HTTP/2，只有在几次请求后才切换到 HTTP/3！我也在其他页面上进行了更多测试，以确认这确实是一致的行为。这可能是由于以下几点：可能只是 Chrome 的当前策略，可能是 Chrome “争用”了 TCP 和 QUIC 连接，并且 TCP 最初获胜，或者可能是第一个视图中的 Alt-Svc 缓存由于某种原因未使用。遗憾的是，在这一点上，没有简单的方法可以确定问题的真正含义（以及它是否可以修复）。

“我在这里注意到的另一件有趣的事情是明显的连接合并行为。如上所述，HTTP/2 和 HTTP/3 都可以重用连接，即使它们转到其他主机名，以防止主机名分片的缺点。但是，如图 3 所示，WebPageTest 报告说，对于此 Facebook 负载，连接合并通过 HTTP/3 进行 facebook.com 和 fbcdn.net，但不通过 HTTP/2（因为 Chrome 为第二个域打开辅助连接）。但是，我怀疑这是 WebPageTest 中的一个错误，因为 facebook.com 和 fbcnd.net 解析为不同的 IP，因此无法真正合并。

该图还显示，当前 WebPageTest 可视化中缺少一些关键的 QUIC 握手信息。

Chrome seems to coalesce over HTTP/3 but not HTTP/2

图 3：Chrome 似乎通过 HTTP/3 而不是 HTTP/2 合并了 Facebook 连接。（大预览）

注意：正如我们所看到的，让 “真正的” HTTP/3 运行有时可能很困难。幸运的是，特别是对于 Chrome，我们可以使用命令行参数形式的其他选项来测试 QUIC 和 HTTP/3。

在 WebPageTest 的“Chromium”选项卡的底部，我使用了以下命令行选项：

--enable-quic  --quic-version=h3-29 --origin-to-force-quic-on=www.facebook.com:443,static.xx.fbcdn.net:443

  复制

该测试的结果表明，这确实从一开始就强制 QUIC 连接，即使在第一个视图中也是如此，从而绕过了 Alt-SVC 进程。有趣的是，您会注意到我必须将两个主机名传递给 --origin-to-force-quic-on。当然，在我没有打开的版本中，Chrome 仍然首先打开了与 fbcnd.net 域的 HTTP/2 连接，即使在重复视图中也是如此。因此，您需要手动指示所有 QUIC 源才能正常工作！

即使从这几个例子中，我们也可以看到，浏览器在实践中实际如何使用 HTTP/3 发生了很多事情。他们似乎甚至在初始页面加载期间切换到新协议，尽快或在需要新连接时放弃 HTTP/2。因此，不仅很难获得完整的 HTTP/3 负载，而且很难在支持两者的设置中获得纯 HTTP/2 负载！因为 WebPageTest 还没有显示太多的 HTTP/3 或 QUIC 元数据，所以弄清楚发生了什么可能很有挑战性，而且你也不能相信这些工具和可视化的表面价值。

因此，如果您使用 WebPageTest，则需要仔细检查结果以确保实际使用了哪些协议。因此，我认为这意味着现在真正测试 HTTP/3 性能还为时过早（尤其是将其与 HTTP/2 进行比较还为时过早）。并非所有服务器和客户端都已实现所有协议功能这一事实加强了这种信念。由于 WebPageTest 还没有简单的方法来显示是否使用了 0-RTT 等高级方面，因此要知道您实际测量的内容将很棘手。对于 HTTP/3 优先级功能尤其如此，该功能尚未在所有浏览器中正确实现，并且许多服务器也缺乏对该功能的完全支持。因为优先级可能是驱动 Web 性能的一个主要方面，所以在没有确保至少此功能正常工作的情况下（对于两种协议）将 HTTP/3 与 HTTP/2 进行比较是不公平的。不过，这只是一个方面，因为我的研究表明 QUIC 实现之间的差异有多大。如果你自己做任何此类比较（或者如果你阅读了这样做的文章），请 100% 确保你已经检查了实际发生的事情。

最后，还要注意，其他高级工具（或数据集，例如令人惊叹的 HTTP Archive）通常基于 WebPageTest 或 Lighthouse（或使用类似的方法），因此我怀疑我在这里的大部分评论将广泛适用于大多数 Web 性能工具。即使那些在未来几个月内宣布支持 HTTP/3 的工具供应商，我也会有点怀疑，并会验证他们是否真的这样做是正确的。不过，对于某些工具，情况可能更糟;例如，Google 的 PageSpeed Insights 今年才获得 HTTP/2 支持，因此我不会等待 HTTP/3 很快到来。

Wireshark、qlog 和 qvis #

如上面的讨论所示，此时仅使用 Lighthouse 或 WebPageTest 来分析 HTTP/3 行为可能很棘手。幸运的是，其他较低级别的工具可以帮助解决这个问题。首先，出色的 Wireshark 工具具有对 QUIC 的高级支持，它还可以实验性地剖析 HTTP/3。这使您可以观察哪些 QUIC 和 HTTP/3 数据包实际上正在通过网络。但是，为了使其正常工作，您需要获取给定连接的 TLS 解密密钥，大多数实现（包括 Chrome 和 Firefox）都允许您使用 SSLKEYLOGFILE环境变量提取该密钥。虽然这对某些事情很有用，但要真正弄清楚发生了什么，尤其是对于较长的连接，可能需要大量的手动工作。您还需要对协议的内部工作原理有相当深入的了解。

幸运的是，还有第二个选项，qlog 和 qvis。qlog 是一种基于 JSON 的日志记录格式，专门用于 QUIC 和 HTTP/3，大多数 QUIC 实现都支持该格式。qlog 直接在客户端和服务器上捕获此信息，而不是查看通过网络传输的数据包，这允许它包含一些附加信息（例如，拥塞控制详细信息）。通常，您可以在使用 QLOGDIR 环境变量启动服务器和客户端时触发 qlog 输出。（请注意，在 Firefox 中，您需要设置 network.http.http3.enable_qlog 首选项。Apple 设备和 Safari 浏览器改用 QUIC_LOG_DIRECTORY。Chrome 尚不支持 qlog。

然后，这些 qlog 文件可以上传到 qvis.quictools.info 的 qvis 工具套件中。在那里，您将获得许多高级交互式可视化效果，可以更轻松地解释 QUIC 和 HTTP/3 流量。qvis 还支持上传 Wireshark 数据包捕获（.pcap 文件），并且它对 Chrome 的 netlog 文件提供实验性支持，因此您还可以分析 Chrome 的行为。关于 qlog 和 qvis 的完整教程超出了本文的范围，但更多详细信息可以在教程形式、论文形式甚至脱口秀形式中找到。您也可以直接询问我，因为我是 qlog 和 qvis 的主要实现者。;)

但是，我并不幻想这里的大多数读者都应该使用 Wireshark 或 qvis，因为这些都是相当低级的工具。尽管如此，由于我们目前几乎没有其他选择，我强烈建议不要在不使用此类工具的情况下广泛测试 HTTP/3 性能，以确保您真正了解网络上发生的事情，以及您所看到的情况是否真的是由协议的内部解释的，而不是由其他因素解释的。

这一切意味着什么？#

正如我们所看到的，通过 QUIC 设置和使用 HTTP/3 可能是一件复杂的事情，很多事情都可能出错。遗憾的是，没有好的工具或可视化可以在适当的抽象级别公开必要的细节。这使得大多数开发人员此时很难评估 HTTP/3 可以为其网站带来的潜在好处，甚至很难验证他们的设置是否按预期工作。

仅依赖高级指标是非常危险的，因为这些指标可能会受到多种因素的影响（例如不切实际的网络模拟、客户端或服务器上缺乏功能、仅部分使用 HTTP/3 等）。正如我们在第 2 部分中所看到的那样，即使一切都运行得更好，在大多数情况下，HTTP/2 和 HTTP/3 之间的差异也可能相对较小，这使得在没有有针对性的 HTTP/3 支持的情况下从高级工具获取必要信息变得更加困难。

因此，我建议将 HTTP/2 与 HTTP/3 性能测量单独放置几个月，而是专注于确保我们的服务器端设置按预期运行。为此，最简单的方法是将 WebPageTest 与 Google Chrome 的命令行参数结合使用，并回退到 curl 以解决潜在问题 — 这是目前我能找到的最一致的设置。

结论和收获 #

亲爱的读者，如果您已经阅读了完整的三部分系列并来到这里，我向您致敬！即使您只阅读了几个部分，我也感谢您对这些令人兴奋的新方案的关注。现在，我将总结本系列的主要内容，为未来几个月和一年提供一些关键建议，最后为您提供一些其他资源，以备您了解更多信息。

摘要 #

首先，在第 1 部分中，我们讨论了需要 HTTP/3 主要是因为新的底层 QUIC 传输协议。QUIC 是 TCP 的精神继承者，它集成了 TCP 的所有最佳实践以及 TLS 1.3。这主要是因为 TCP 由于在中间设备中无处不在的部署和集成，它变得太不灵活而无法发展。QUIC 对 UDP 的使用和几乎完全加密意味着我们（希望）将来只需要更新端点即可添加新功能，这应该会更容易。但是，QUIC 还添加了一些有趣的新功能。首先，QUIC 的传输和加密握手比 TCP + TLS 更快，并且可以很好地利用 0-RTT 功能。其次，QUIC 知道它承载着多个独立的字节流，并且可以更智能地处理丢失和延迟，从而缓解队头阻塞问题。第三，QUIC 连接可以通过使用连接 ID 标记每个数据包来保留用户移动到不同的网络（称为连接迁移）。最后，QUIC 灵活的数据包结构（使用帧）使其更高效，但在未来也更加灵活和可扩展。总之，很明显 QUIC 是下一代传输协议，并将在未来许多年内使用和扩展。

其次，在第 2 部分中，我们对这些新功能进行了一些批判性的研究，尤其是它们对性能的影响。首先，我们看到 QUIC 对 UDP 的使用并没有神奇地使其更快（也不更慢），因为 QUIC 使用与 TCP 非常相似的拥塞控制机制来防止网络过载。其次，更快的握手和 0-RTT 更多的是微优化，因为它们实际上只比优化的 TCP + TLS 堆栈快一次往返，而 QUIC 真正的 0-RTT 进一步受到一系列安全问题的影响，这可能会限制其实用性。第三，连接迁移实际上仅在少数特定情况下才需要，并且仍然意味着重置发送速率，因为拥塞控制不知道新网络可以处理多少数据。第四，QUIC 的队头阻塞消除的有效性在很大程度上取决于流数据的多路复用和优先级排序方式。从数据包丢失中恢复的最佳方法似乎不利于网页加载性能的一般用例，反之亦然，尽管需要更多的研究。第五，QUIC 发送数据包的速度很容易比 TCP + TLS 慢，因为 UDP API 不太成熟，而且 QUIC 会单独加密每个数据包，尽管这在很大程度上可以随着时间的推移而缓解。第六，HTTP/3 本身并没有真正带来任何主要的新性能特性，而是主要重新设计和简化了已知 HTTP/2 特性的内部结构。最后，QUIC 允许的一些最令人兴奋的与性能相关的功能（多路径、不可靠数据、WebTransport、前向纠错等）并不是核心 QUIC 和 HTTP/3 标准的一部分，而是需要更多时间才能可用的拟议扩展。 总之，这意味着 QUIC 可能不会为高速网络用户提高性能，但主要对那些使用速度较慢且不稳定的用户很重要。

最后，在第 3 部分中，我们研究了如何实际使用和部署 QUIC 和 HTTP/3。首先，我们看到从 HTTP/2 中吸取的大多数最佳实践和经验教训都应该延续到 HTTP/3 中。无需更改捆绑或内联策略，也无需合并或分片服务器场。服务器推送仍然不是最好用的功能，预加载同样可以是一个强大的脚枪。其次，我们已经讨论过，现成的 Web 服务器包可能需要一段时间才能提供完整的 HTTP/3 支持（部分原因是 TLS 库支持问题），尽管早期采用者可以使用大量开源选项，并且几个主要的 CDN 已经提供了成熟的产品。第三，很明显，大多数主流浏览器都有（基本的）HTTP/3 支持，甚至默认启用。但是，它们在实际使用 HTTP/3 及其新功能的方式和时间存在重大差异，因此了解它们的行为可能具有挑战性。第四，我们已经讨论过，由于 Lighthouse 和 WebPageTest 等流行工具中缺乏明确的 HTTP/3 支持，情况会变得更糟，因此目前很难将 HTTP/3 性能与 HTTP/2 和 HTTP/1.1 进行比较。总之，HTTP/3 和 QUIC 可能还没有完全准备好迎接黄金时段，但它们很快就会准备好。

建议 #

从上面的总结来看，我似乎在强烈反对使用 QUIC 或 HTTP/3。然而，这与我想表达的观点完全相反。

首先，正如第 2 部分末尾所讨论的，即使您的 “普通” 用户可能不会获得重大的性能提升（取决于您的目标市场），但您的很大一部分受众可能会看到令人印象深刻的改进。0-RTT 可能只保存一次往返，但对于某些用户来说，这仍然意味着几百毫秒。连接迁移可能无法维持始终如一的快速下载，但它肯定会帮助试图在高速列车上获取 PDF 的人。电缆上的数据包丢失可能是突发的，但无线链路可能会从 QUIC 的队头阻止删除中受益更多。更重要的是，这些用户通常是那些通常会遇到产品性能最差的用户，因此受其影响最严重。如果您想知道为什么这很重要，请阅读 Chris Zacharias 的著名 Web 性能轶事。

其次，随着时间的推移，QUIC 和 HTTP/3 只会变得更好、更快。版本 1 专注于完成基本协议，为以后保留更高级的性能功能。因此，我觉得现在就开始投资这些协议是值得的，以确保您可以在它们可用时使用它们和新功能以获得最佳效果。考虑到协议及其部署方面的复杂性，最好给自己一些时间来熟悉它们的怪癖。即使您还不想动手，几家主要的 CDN 提供商也提供了成熟的“翻转开关”HTTP/3 支持（特别是 Cloudflare 和 Fastly）。如果您使用的是 CDN，我很难找到不尝试的理由（如果您关心性能，您真的应该这样做）。

因此，虽然我不会说尽快开始使用 QUIC 和 HTTP/3 至关重要，但我确实觉得已经有很多好处，而且它们在未来只会增加**。

其他资源 #

虽然这是一段很长的文字，但遗憾的是，它实际上只是触及了 QUIC 和 HTTP/3 复杂协议的技术表面。

您将在下面找到用于继续学习的其他资源列表，或多或少按技术深度升序排列：

  • “HTTP/3 解释”，Daniel Stenberg
    这本电子书由 cURL 的创建者编写，总结了该协议。
  • “HTTP/2 在行动”，Barry Pollard
    这本关于 HTTP/2 的优秀全能书籍包含可重复使用的建议和关于 HTTP/3 的部分。
  • @programmingart、推特
    我的推文主要致力于 QUIC、HTTP/3 和一般的 Web 性能（包括新闻）。
  • “YouTube”，罗宾·马克思
    我的 10 多次深入演讲涵盖了协议的各个方面。
  • “Cloudlare 博客”
    这是一家公司的主要产品，该公司也在旁边运行 CDN。
  • “Fastly 博客”
    这个博客对技术方面进行了很好的讨论，嵌入到更广泛的背景中。
  • QUIC，实际的 RFC
    您将找到指向 IETF QUIC 和 HTTP/3 RFC 文档以及其他官方扩展的链接。
  • IIJ 工程师博客：对 QUIC 功能细节的出色深入技术解释。
  • HTTP/3 和 QUIC 学术论文，Robin Marx
    我的研究论文涵盖了流多路复用和优先级、工具和实现差异。
  • QUIPS、EPIQ 2018 和 EPIQ 2020
    这些来自学术研讨会的论文包含对协议的安全性、性能和扩展的深入研究。

亲爱的读者，我给你留下一个希望对这个美丽新世界有很大了解。我始终乐于接受反馈，所以请让我知道你对这个系列的看法！

avatar
文章
阅读
粉丝