我们应该在 HTTP/2 中复用多少并发请求

Posted 2023-03-10

【中文标题】我们应该在 HTTP/2 中复用多少并发请求

【英文标题】：How many concurrent requests should we multiplex in HTTP/2

【发布时间】：2017-02-07 02:46:23

【问题描述】：

长期以来，浏览器最多使用每个主机 6 个并发 HTTP 1.1 连接来从网页中检索资产。 （远远）超出这个黄金标准会被视为 DOS 并被禁止访问服务器。

现在有了 HTTP/2，我们可以在一个连接上多路复用多个 HTTP 请求。为了防止服务器过载，我们是否还应该对连接上多路复用的并发请求数量使用类似的限制？还是在单个连接上多路复用更多请求没有害处？

谁知道浏览器对 HTTP/2 服务器的每个主机和每个连接使用的限制是什么？

【参考方案1】：

客户端和服务器可以发起的流的数量不是无限的，它由每个对等点在连接开始时发送的SETTINGS 帧的SETTINGS_MAX_CONCURRENT_STREAMS 参数规定：见section 6.5.2 of RFC 7540 默认为无限制，RFC 有以下建议：

建议该值不小于100，以便 不会不必要地限制并行性。

然而，在考虑 HTTP/2 中的并行性时，流的数量并不是唯一要考虑的参数。权重和流依赖关系也会发挥作用。

每个流都有一个权重，RFC 建议服务器根据权重为流分配资源。在客户端，Firefox 为 CSS 分配比图像更高的权重。 See this great presentation for more details about how each browser prioritizes and organizes its streams。 Chrome 使用依赖项，因此最重要的元素（CSS、html）在依赖项链中比其他元素更高。 See this tool 说明了 Chrome 生成的依赖树。服务器端H2O, a new and fast HTTP server 为每个连接实现一个 O(1) 调度程序，以便根据依赖关系和权重将流发送到客户端。这意味着如果您请求 500 个具有默认依赖项的元素，每个流将获得 1/500 的服务器资源。

请求尽可能多的元素（对于常规网页浏览）应该没有任何不利之处。根据HTTPArchive 的说法，40% 的页面包含超过 100 个元素，我认为同时询问它们是合理的（前提是流的数量保持在SETTINGS_MAX_CONCURRENT_STREAMS 以下。我认为重要的是能够以允许浏览器尽可能快地呈现它的顺序请求它们。