HTTP/3: 实用部署选项(第3部分)

原文链接：https://www.smashingmagazine.com/2021/08/http3-performance-improvements-part2/ 作者亲自操刀的系列文章，英文的，英文水平不错的同学请移步，毕竟我的英文水平比较low，可能翻译的不到位

第1部分: HTTP/3历史记录和核心概念
第2部分: HTTP/3性能特性
第3部分: 实用 HTTP/3部署选项

摘要

经过近五年的开发，新的 HTTP/3协议已接近最终形式。让我们仔细看看部署和测试 HTTP/3所涉及的挑战，以及如何以及是否也应该更改网站和资源。

开篇

您好，欢迎来到这个由三部分组成的系列文章的最后一部分，内容是关于新的 HTTP/3和 QUIC 协议的！如果在前两部分(HTTP/3历史记录和核心概念以及 HTTP/3性能特性)之后，您确信开始使用新协议是一个好主意(您应该这样做!)，然后这最后一块包括所有你需要知道的开始！

首先，我们将讨论需要对页面和资源进行哪些更改才能最佳地使用新协议(这是容易的部分)。接下来，我们将研究如何设置服务器和客户端(这是困难的部分，除非您使用的是内容传递网路(CDN))。最后，我们将看到可以使用哪些工具来评估新协议的性能影响(这几乎是不可能的部分，至少目前是这样)。

第1部分: HTTP/3历史记录和核心概念：本文针对 HTTP/3和一般协议的新手，主要讨论基础知识
第2部分: HTTP/3性能特性：这一个更深入和技术性。人们谁已经知道的基本知识可以从这里开始
第3部分: 实用 HTTP/3部署选项：本系列的第三篇文章解释了自己部署和测试 HTTP/3所涉及的挑战。它详细说明了如何以及是否应该更改您的网页和资源

页面和资源的更改

让我们从一些好消息开始: 如果您已经使用 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到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 的几个微妙的安全问题。即使您确实正确地设置了它，您仍然可以很容易地以两个独立的连接结束。问题是，这并不总是坏事。首先，由于优先级和多路复用实现不佳(见下文) ，单个连接很容易比使用两个或多个连接慢。其次，由于拥塞控制器之间的竞争，使用太多的连接会导致早期的包丢失。然而，只使用一些(但仍然不止一个)可以很好地平衡拥塞增长和更好的性能，特别是在高速网络上。由于这些原因，我相信一点点的分片仍然是一个好主意(比如说，2到4个连接) ，即使使用 HTTP/2。事实上，我认为大多数现代 HTTP/2设置的性能和它们一样好，因为它们在关键路径中仍然有一些额外的连接或第三方负载。

3. 资源捆绑和内联

在 HTTP/1.1中，每个连接只能有一个活动资源，这会导致 HTTP 级别的行首(head-of-line，HoL)阻塞。因为连接的数量被限制在区区6到30个，所以资源捆绑(将较小的子资源合并到单个较大的资源中)是一个长期的最佳实践。我们今天仍然在诸如 Webpack 这样的捆绑包中看到这一点。类似地，资源通常内联在其他资源中(例如，关键的 CSS 内联在 HTML 中)。

然而，使用 HTTP/2，单个连接可以复用资源，因此您可以有更多未处理的文件请求(换句话说，单个请求不再占用您为数不多的宝贵连接之一)。这最初被解释为，“我们不再需要为 HTTP/2绑定或内联我们的资源”。这种方法被吹捧为更适合细粒度缓存，因为每个子资源都可以单独缓存，而且如果其中一个子资源发生了更改，则不需要重新下载完整的 bundle。这是事实，但只是在相对有限的范围内。

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

当然，所有这些对于 HTTP/3来说仍然是正确的。尽管如此，我还是读到人们声称许多小文件比 QUIC 更好，因为更多并发活动的独立流意味着 HoL 阻塞移除的更多利润(正如我们在第2部分中讨论的)。我认为这可能有些道理，但是，正如我们在第2部分中看到的，这是一个非常复杂的问题，有很多移动参数。我不认为这样做的好处会超过讨论的其他成本，但是还需要更多的研究。(一个离谱的想法是让每个文件的大小完全符合一个 QUIC 包，绕过 HoL 完全阻塞。我将接受任何实现了这一功能的资源捆绑包的初创企业的版税。