通过 HTTP2 批处理请求

Question

如果我们发出一个大型 HTTP 请求，而不是通过 HTTP2 发出多个较小的 HTTP 请求，是否有可能从我们的服务器获得更好的吞吐量？

根据我的理解，它不会对性能产生任何显着差异，因为使用 HTTP2，我们可以在一个 TCP 连接上多路复用多个请求。

Answer 1

是的，在网络级别，一个大请求比多个小请求更有效。 这是由于发出网络请求的开销。

这也是为什么在 HTTP/1.1 下推荐将 CSS 和 JavaScript 连接并为图像进行 spriting 的原因，因此发送的数据量相同，但请求量要低得多。 事实上，由于像 gzip 这样的压缩方式，发送大请求时数据量通常较小。

HTTP/2 旨在通过使用多路复用重用单个 TCP 连接来降低 HTTP 请求的成本。 理论上，这将允许我们放弃串联和精灵。 然而，现实情况并不完美——通常是由于浏览器效率低下而不是 HTTP/2 的错误。 瓶颈刚刚转移，我们需要为新世界优化浏览器。 所以，就目前而言，仍然推荐一定程度的专注和精灵。

回到您的问题，是的，它应该在该网络级别具有单一效果，事实上，如果您这样做，HTTP/1.1 和 HTTP/2 的性能甚至可能相似。

然而，在网络级别之外，您可能会发现不捆绑到更少文件中的其他原因。 例如，如果您有一个大型 JavaScript 文件，那么浏览器必须等待所有文件下载完毕，然后才能对其进行解析、编译和运行。 您最好先下载更小、更重要的 JavaScript。 与图像精灵类似，您可能会在显示单个图像之前等待整个精灵文件下载。

然后是缓存的影响。 更改一行 JS 或将单个图像添加到图像 Sprite 需要创建一个全新的大文件，这意味着不能使用旧文件，需要重新下载整个文件。

此外，大文件的实施和管理可能会更加复杂。 它们需要一个构建步骤（可能不像许多站点那样重要）并且通过 CSS 创建和管理图像精灵通常更加困难。

此外，如果使用这种坚持使用HTTP / 1.1，那么你可能会错过了是HTTP / 2的其他好处，包括HPACK报头压缩和HTTP / 2推（虽然这也 更棘手得到的权利比最初认为/希望！）。

这是一个有趣的话题，我花了很多时间，最好的建议（一如既往！）是了解技术并测试、测试、再测试！