我们应该在 HTTP/2 中多路复用多少个并发请求
How many concurrent requests should we multiplex in HTTP/2
长期以来，浏览器在每个主机上使用最多 6 个并发 HTTP 1.1 连接来从网页检索资产。超出这个黄金标准（远）会被视为 DOS 并被服务器禁止。
现在有 HTTP/2，我们可以在单个连接上多路复用多个 HTTP 请求。为了防止服务器过载，我们是否仍应对连接上多路复用的并发请求数量使用类似的限制？还是在单个连接上多路复用更多请求没有害处？
有人知道 HTTP/2 服务器的每个主机和每个连接的浏览器使用什么限制吗？
客户端和服务器可以启动的流的数量不是无限的，它由每个对等方在连接开始时发送的 SETTINGS 帧的 SETTINGS_MAX_CONCURRENT_STREAMS 参数强制要求：参见section 6.5.2 of RFC 7540默认是无限制的，RFC有如下推荐：
It is recommended that this value be no smaller than 100, so as to
not unnecessarily limit parallelism.
然而，在 HTTP/2 中考虑并行性时，流的数量并不是唯一要考虑的参数。权重和流依赖性也发挥作用。
每个流都有一个权重，RFC 建议服务器根据权重为流分配资源。在客户端，Firefox 为 CSS 分配的权重高于图像。 See this great presentation for more details about how each browser prioritizes and organizes its streams. Chrome uses dependencies so that the most important elements (CSS, HTML) are higher in the dependency chain than others. See this tool that illustrates the dependecy tree that Chrome generates. Server side, H2O, a new and fast HTTP server，为每个连接实现一个 O(1) 调度程序，以便根据依赖项和权重将流发送到客户端。这意味着如果你请求 500 个具有默认依赖的元素，每个流将获得 1/500 的服务器资源。
请求尽可能多的元素应该没有任何缺点（对于常规网页浏览）。根据 HTTPArchive，40% 的页面包含超过 100 个元素，我认为同时询问它们是合理的（前提是流的数量保持在 SETTINGS_MAX_CONCURRENT_STREAMS 以下。我相信重要的是能够按照允许浏览器尽可能快地呈现它的顺序请求它们。
长期以来，浏览器在每个主机上使用最多 6 个并发 HTTP 1.1 连接来从网页检索资产。超出这个黄金标准（远）会被视为 DOS 并被服务器禁止。
现在有 HTTP/2，我们可以在单个连接上多路复用多个 HTTP 请求。为了防止服务器过载，我们是否仍应对连接上多路复用的并发请求数量使用类似的限制？还是在单个连接上多路复用更多请求没有害处？
有人知道 HTTP/2 服务器的每个主机和每个连接的浏览器使用什么限制吗？
客户端和服务器可以启动的流的数量不是无限的，它由每个对等方在连接开始时发送的 SETTINGS 帧的 SETTINGS_MAX_CONCURRENT_STREAMS 参数强制要求：参见section 6.5.2 of RFC 7540默认是无限制的，RFC有如下推荐：
It is recommended that this value be no smaller than 100, so as to not unnecessarily limit parallelism.
然而，在 HTTP/2 中考虑并行性时，流的数量并不是唯一要考虑的参数。权重和流依赖性也发挥作用。
每个流都有一个权重，RFC 建议服务器根据权重为流分配资源。在客户端，Firefox 为 CSS 分配的权重高于图像。 See this great presentation for more details about how each browser prioritizes and organizes its streams. Chrome uses dependencies so that the most important elements (CSS, HTML) are higher in the dependency chain than others. See this tool that illustrates the dependecy tree that Chrome generates. Server side, H2O, a new and fast HTTP server，为每个连接实现一个 O(1) 调度程序，以便根据依赖项和权重将流发送到客户端。这意味着如果你请求 500 个具有默认依赖的元素，每个流将获得 1/500 的服务器资源。
请求尽可能多的元素应该没有任何缺点（对于常规网页浏览）。根据 HTTPArchive，40% 的页面包含超过 100 个元素，我认为同时询问它们是合理的（前提是流的数量保持在 SETTINGS_MAX_CONCURRENT_STREAMS 以下。我相信重要的是能够按照允许浏览器尽可能快地呈现它的顺序请求它们。