我目前正在运行启用了 HTTP/2 的 Apache 服务器作为我的 Web 应用程序的反向代理。我注意到通过此配置请求大量小缩略图（每个大约 60KB）时速度明显减慢。奇怪的是，这种速度下降是在从 HTTP/1.1 切换到 HTTP/2 后开始发生的，尽管 HTTP/2 应该可以提高性能（特别是在这种情况下，因为请求许多小文件对于所有花哨的多路复用来说都是一个很好的用例） HTTP/2 可以）。
当顺序请求图像时，我没有注意到速度减慢，但只有当客户端一次提交大量文件（大约 200 个）时才注意到速度减慢。
烘焙程序仅使用 HTTP/1.1，并且可以使用反向代理进行访问。缩略图预先缓存在磁盘上。
这是 Chromium 的 HTTP/2 瀑布图： Waterfall HTTP/2
对于 HTTP/1.1： 瀑布式 HTTP 1.1
正如您在图像中看到的那样，HTTP/2 请求不再停滞，但总体时间增加了。
任何如何进一步调试的指针或提示都会很棒
（这应该是一个评论 - 但空间有限）
1.) 当服务未按预期运行时，首先要查看的地方是日志。但默认的日志格式不会捕获有用的计时信息 - 您应该在 httpd 上至少添加 %D
2.) 我喜欢 Apache httpd 作为原始服务器，但它作为反向代理不太理想
3.) 当就软件未按预期运行寻求帮助时，最好提供版本信息及其配置详细信息
4.）您向我们展示的内容看起来更像是符合 HTTP/1.1 对并发请求的限制，而不是速度减慢的内容（但我没有在 mod_proxy 中看到这种行为）
我认为这与达到最大 Apache 会话流限制以及发生这种情况时 Chrome 在 HTTP/2 及更高版本中处理离屏图像（和其他较低优先级请求）的方式有关。
默认情况下， mod_http2 允许同时最多允许 100 个流。此后，请求将在发送之前排队。
我在这里有一个类似的测试（尽管图像较小）：https://https.tunetheweb.com/performance-test-360/
在4g连接下测试时：
在 HTTP/1.1 下进行相同的测试，您不会看到这种阶梯效果：
然而，在这两项测试中，HTTP/2 都比 HTTP/1.1 快得多（移动设备上为 9.775 秒 vs 13.864 秒，桌面设备上为 4.129 秒 vs 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 使请求变得更便宜，但不是免费的。