HTTP/3部署所面临的挑战（上）

---

翻译、编辑：Alex

技术审校：刘连响

本文来自_Smashing Magazine_，原文链接：

https://www.smashingmagazine.com/2021/09/http3-practical-deployment-options-part3/

Robin讲HTTP/3 #006#

经过近五年的开发，新的HTTP/3协议终于接近尾声。接下来让我们详细了解一下在部署和测试HTTP/3时所遇到的挑战，以及如何或是否也应该更改你的网站和资源。

大家好，欢迎来到HTTP/3和QUIC协议系列的第三部分，也是最后一部分！在学习了前两部分内容之后，你已经相信开始使用新协议是一个不错的主意（你也应该如此！），接下来最后一部分的内容囊括了你需要知道的所有入门知识！

首先，我们将讨论需要对网页和资源进行哪些更改才能充分使用这些新协议（这一部分比较容易）。接着，我们将了解如何设置服务器和客户端（这一部分较难，除非你使用了CDN）。最后，我们将了解可以使用哪些工具来评估新协议所带来的性能影响（这一部分几乎无法实现，至少目前如此）。

网页和资源的更改

让我们从一些好消息开始：**如果你已经在使用HTTP/2，那么在向HTTP/3迁移时，你可能无需更改网页和资源！**我们在第一部分和第二部分曾解释过：这是因为HTTP/3更像是HTTP/2-over-QUIC，而且这两个版本的高层特性没有发生变化。因此，任何对HTTP/2的更改和优化也将同样适用于HTTP/3，反之亦然。

然而，如果你正在使用HTTP 1.1，或者你忘了向HTTP/2过渡，又或者你从未调整过HTTP/2，那么你也许想知道究竟需要什么样的更改以及为什么需要这些更改。即使在今天，你也很难找到详细描述这些具备细微差别的最佳实践的好文章。正如我在第一部分所介绍的那样，这是因为早期 HTTP/2 的大部分内容都过于乐观地认为它的实际效果会很好，但坦诚讲，其中一些包含了重大错误和糟糕的建议。遗憾的是，很多错误信息在今天依然存在。这也是我创作HTTP/3系列文章的主要原因：防止重蹈覆辙。

此刻，我要大家推荐Barry Pollard[1]的 HTTP/2 in Action [2]一书，它是最全面且最细致入微介绍HTTP/2的图书。不过，这是一个付费资源，我不想你在这里各种猜测，所以我下面列出了一些要点，以及它们与HTTP/3的关系。

1. 单一连接（Single Connection）

HTTP/1.1与HTTP/2之间最大的差异是：从6~30个并行TCP连接切换到单一的底层TCP连接。我们曾在第二部分讨论过，由于拥塞控制在多个连接的情况下会产生更多或者更早的丢包（这抵消了多个连接拥有较快开始的优势），所以单一连接依然可以和多个连接一样快。HTTP/3继续使用这种方法，但“只是”从一个TCP连接切换到了一个QUIC连接。这种差异本身并没有太大作用（它主要减少了服务器端的开销），但接下来的大部分内容都是由这种差异引起的。

2. 服务器sharding和连接合并（Server Sharding and Connection Coalescing）

实际中，切换到单一连接设置非常困难，因为许多页面被shard到不同的主机名甚至是服务器上（如img1.example.com 和 img2.example.com）。这是因为浏览器最多只能为每个主机名打开6个连接，所以多个主机名就要打开更多连接！如果不更改多个域名的设置，HTTP/2仍然会打开多个连接，从而降低了其他特性（比如优先级，见下文）的实际效果。

因此，最开始的建议是撤销服务器sharding并将资源尽量整合在一个服务器上。HTTP/2甚至提供了一个被称为连接合并[3]的特性。通过它，HTTP/2从HTTP/1设置的过渡变得更容易。简单来说，如果两个主机名解析为相同的服务器IP（使用DNS）并使用一个相似的TLS证书，那么浏览器甚至可以在两个主机名上重用单一连接。

由于涉及CORS的几个微妙的安全问题[4]，连接合并在实际中很难正确操作[5]。即使你能够正确设置，最后也可能仍然获得两个分开的连接。但这并不总是坏事。首先，由于优先级和多路复用糟糕的实现（见下文），单一连接很容易比两个或者多个连接更慢[6]；第二，由于拥塞控制器的竞争，使用过多的连接有可能会导致早期丢包。使用较少的连接（仍然多于一个）可以平衡拥塞增长和更好的性能，尤其在高速网络上。因此，我相信少量的sharding仍是一个不错的主意（如2~4个连接），即使使用的是HTTP/2。事实上，我认为大部分现代HTTP/2设置在性能上表现不错，因为它们的关键路径中仍然有一些额外的连接和第三方负载。

3. 资源打包和内联（Resource Bundling and Inlining）

在HTTP/1.1中，每个连接只能有一个活跃资源，进而导致了HTTP级别的队头阻塞[7]。因为连接数量被限制在仅仅6~30个，所以资源打包（其中较小的子资源被合并到一个更大的资源中）长期以来都是最佳实践。今天我们仍然在Webpack等打包器中看到这种操作。同样，资源也曾经常被内联在其他资源中（比如，关键CSS被内联在HTML）。

然而通过HTTP/2，单一连接可以多路复用多个资源，那么你就会有各种文件的大量未完成请求（outstanding request）（换言之，单一请求不再占据你的前几个宝贵连接）。这最初被解读为：“我们不再需要为HTTP/2打包或内联资源”。很多人吹捧这种方法要优于细粒度缓存（fine-grained caching），因为子资源可以被单独缓存，而且如果其中一个资源发生变化，则无需重新下载完整打包。这是真的&#