【发布时间】：2020-06-03 08:30:59
【问题描述】：
如果我们发出一个较大的 HTTP 请求，而不是通过 HTTP2 发出多个较小的 HTTP 请求，是否有可能从我们的服务器获得更好的吞吐量。
据我了解，它不应该在性能上产生任何显着差异，因为使用 HTTP2 我们可以通过一个 TCP 连接多路复用多个请求。
【问题讨论】：
标签： performance http tcp http2
【发布时间】：2020-06-03 08:30:59
【问题描述】：
是的，在网络级别，一个大请求将比多个小请求更有效。这是由于发出网络请求的开销造成的。
这也是为什么在 HTTP/1.1 下建议将 CSS 和 JavaScript 连接起来并为图像绘制精灵，这样发送的数据量是相同的，但请求的数量要少得多。事实上，由于 gzip 等压缩的工作方式，发送大请求时数据量通常较小。
HTTP/2 旨在通过使用multiplexing 重用单个 TCP 连接来大大降低 HTTP 请求的成本。从理论上讲，这将允许我们放弃串联和拆分。然而，现实并不完美——通常是由于浏览器效率低下而不是 HTTP/2 的错误。瓶颈刚刚转移，我们需要针对新世界优化浏览器。所以，就目前而言，仍然建议使用某种程度的 connation 和 spriting。
回到您的问题，是的，它应该在该网络级别具有单一效果，事实上，如果您这样做，HTTP/1.1 和 HTTP/2 甚至可能在性能上相似。
但是，在网络级别之外，您可能会发现其他不将文件打包成更少文件的原因。例如，如果您有一个较大的 JavaScript 文件，那么浏览器必须等待它全部下载完毕，然后才能对其进行解析、编译和运行。最好先下载更小、更重要的 JavaScript。与图像精灵类似，您可能会在显示单个图像之前等待整个精灵文件下载。
然后是缓存的含义。更改单行 JS 或将单个图像添加到图像 Sprite 需要创建一个全新的大文件，这意味着旧的无法使用，需要重新完整下载整个文件。
另外，拥有大文件可能更难以实现和管理。它们需要一个构建步骤（可能不像许多网站那样重要），并且通过 CSS 创建和管理图像精灵通常更加困难。
此外，如果使用它来坚持 HTTP/1.1，那么您可能会错过 HTTP/2 的其他好处，包括 HPACK header compression 和 HTTP/2 推送（尽管这也是 more tricky to get right，而不是最初的想法/希望！）。
It’s a fascinating topic that I’ve spent a lot of time on，最好的建议（一如既往！）是了解技术并测试、测试、测试！
【讨论】：