通过反向代理向 HTTP/1.1 后端请求小缩略图 (60KB) 时，Apache 使用 HTTP/2 的速度会变慢

Question

我目前正在运行一个启用了 HTTP/2 的 Apache 服务器作为我的 Web 应用程序的反向代理。我注意到，通过此配置请求大量小缩​​略图（每个大约 60KB）时，速度会明显减慢。奇怪的是，这种减慢是在从 HTTP/1.1 切换到 HTTP/2 后开始出现的，尽管 HTTP/2 应该可以提高性能（尤其是在这种情况下，因为请求许多小文件是 HTTP/2 所做的所有花哨的多路复用功能的绝佳用例）。

• 当按顺序请求图像时，我没有注意到速度变慢，但只有当客户端一次归档大量文件（约 200 个）时才会出现。

• 该烘焙端仅支持 HTTP/1.1，可使用反向代理访问。缩略图已预先缓存在磁盘上。

以下是 Chromium 的 HTTP/2 瀑布图： 瀑布式 HTTP/2

对于 HTTP/1.1： 瀑布式 HTTP 1.1

从图中可以看出，HTTP/2 请求不再停滞，但总体时间有所增加。

任何关于如何进一步调试的指示或提示都很好

Answer 1

（这应该是一条评论 - 但空间有限）

1.) 当服务表现不正常时，首先要查看的是日志。但默认日志格式不会捕获有用的时间信息 - 您应该在 httpd 上至少添加 %D

2.) 我喜欢用 Apache httpd 作为原始服务器，但它作为反向代理不太理想

3.) 当寻求有关软件无法正常工作的帮助时，最好提供版本信息和配置细节

4.) 您向我们展示的内容看起来更像是符合 HTTP/1.1 对并发请求的限制，而不是速度变慢（但我没有看到 mod_proxy 有这种行为）

Answer 2

我认为这与达到最大 Apache 会话流限制以及当发生这种情况时 Chrome 在 HTTP/2 及更高版本中如何处理屏幕外图像（和其他优先级较低的请求）有关。

默认情况下mod_http2 最多允许 100 个流任何时候。此后，请求将排队等待发送。

我在这里有一个类似的测试（尽管图像较小）：https://https.tunetheweb.com/performance-test-360/

在4g连接下测试时：

• 在移动设备上（大多数图像都在屏幕外），在 100 张图像之后，您会在 HTTP/2 上看到这种阶梯式效果，Chrome 会等待所有当前正在进行的请求完成后，再以 8 个为一批的形式发送下一组请求：https://www.webpagetest.org/result/231001_BiDcVS_6JG/1/details/#waterfall_view_step1
• 在桌面上（所有图像都在屏幕上），发送 100 多张图像仍然会有延迟（因为已经达到最大流限制而无法发送），但 Chrome 不会等待所有当前正在传输的图像都耗尽后才开始：https://www.webpagetest.org/result/231001_BiDcT3_6SC/1/details/#waterfall_view_step1

在 HTTP/1.1 下进行相同的测试，你不会看到这种阶梯效应：

• 移动的：https://www.webpagetest.org/result/231001_AiDcTM_6YH/1/details/#waterfall_view_step1
• 桌面：https://www.webpagetest.org/result/231001_AiDcAF_6XZ/1/details/#waterfall_view_step1

但是，HTTP/2 在这两个测试中都比 HTTP/1.1 快得多（移动设备上 9.775 秒对 13.864 秒，桌面上 4.129 秒对 13.622 秒）。对于较大的图像，这种权衡可能不太奏效，HTTP/2 最终可能会更慢。

因此我建议对所有屏幕上的图片重复测试。或者将H2MaxSessionStreams最大尺寸提高到更适合你网站的尺寸。

将限制设置为 400 后重新运行移动测试，H2MaxSessionStreams结果显示它没有限制：https://www.webpagetest.org/result/231001_BiDcBW_70Q/1/details/#waterfall_view_step1

然而，当许多请求同时进行时，您最终会遇到各种优先级问题。服务器是否应该以循环方式发送每个响应的一小部分？或者按照请求的顺序完整发送第一个响应。关于这一点已经有很多文章（见这个帖子例如），答案取决于很多因素。对于 HTML 和图像（尤其是渐进式图像），一次发送一些位可能更好，因为浏览器可以在它们到达时处理它们。对于其他需要整个资源才能使用的资源（比如 CSS 和 JavaScript），发送部分资源是没有意义的，最好按顺序发送响应。

因此，我建议不要在这里过多地更改默认值，因为实际上可能没有那么有用。此外，这将需要浏览器和服务器的更多资源。如果这是由于屏幕外图像造成的，那么情况可能没有您的测试显示的那样糟糕，因为对用户的影响可能要小得多。

我还建议尝试减少页面上的资源数量。处理 200 多个文件是件很麻烦的事。HTTP/2 使请求更便宜，但并非免费。