我了解 HTTP/2 的所有优点，但是，是否有经过验证的同类比较来显示它的速度优势？
Akamai 拥有为此目的设立的页面，但 HTTP/2 似乎最好能跟上节奏，最坏的情况下会更慢。我在 Firefox 中进行了测试。在 Chrome 中，HTTP/2 稍快一些。
答案1
首先让我们验证您是否使用的是 HTTP/1.1 还是 HTTP/2。
在 Chrome 或 Firefox 中打开开发人员工具，添加协议列并重新加载页面。您应该看到从 http1.akamai.com 加载的许多图像和从 http2.akamai.com 加载的许多图像：
如果您在此处未看到 HTTP/2，则有某种因素阻止使用 HTTP/2（可能是代理或防病毒软件），这或许可以解释这一点。不过，我从您的屏幕截图中看到“您的浏览器支持 HTTP/2！”，因此我推测您正在使用 HTTP/2，但没有进行危害检查。
测试内容是加载 378 张图片来组成每个地球仪。HTTP/1 特别不擅长加载这么多资源，而 HTTP/2 则特别擅长——主要是因为HTTP/2 允许多路复用。
因此，如果您正在使用 HTTP/2，但没有发现 HTTP/2 速度更快，则可能是由于以下原因之一：
- 有一些东西在本地缓存资源，这意味着你是在本地加载它们，而不是直接从 Akamai 加载它们。例如，如果你有一个公司代理为你做一些缓存。现在 Akamai 确实
Cache-Control: max-age=0, no-cache, no-store在资源上设置了一个 HTTP 标头，所以它不应该被缓存，但代理仍然做了更奇怪的事情！老实说，在 HTTP/1 中用 0.62 秒加载这个网站听起来太快了，除非你坐在 Akamai 的数据中心，所以这就是我认为正在发生的事情。尝试另一个 HTTP/2 测试（例如，我博客上有自己的一个）。 - 您拥有超快的网络，没有延迟。延迟是 HTTP/1.1 比 HTTP/2 慢的主要原因，因为来回发送请求会浪费时间，在此期间，该连接上无法发送其他请求。从您的屏幕截图来看，您的延迟似乎低得不合理，所以您的连接一定非常快。要么您住在 Akamai 隔壁，要么您正在本地阅读。
- 您处在一个数据包丢失很多的网络上。HTTP/2 使用一个 TCP 连接（大多数情况下），虽然这对于大多数用例来说都很好，但在网络不好的情况下，情况实际上会变得更糟，因为所有 HTTP/2 流都会因单个 TCP 数据包丢失而受阻（直到 HTTP/1.1，6 个独立连接可以真正独立运行）。快看起来可以通过从 TCP 转移到基于 UDP 的协议来解决这个问题，该协议在流而不是连接级别提供类似 TCP 的可靠性。但在这种情况下，我预计 HTTP/1.1 和 HTTP/2 都会比您提供的屏幕截图慢，所以不要认为是那样。
- 你的 HTTP/2 浏览器很差劲。我见过即使最流行的浏览器也存在 HTTP/2 实现问题。尝试其他浏览器。您已经说过这在 Chrome 中按预期工作，但在 Firefox 中却不行，所以这可能是浏览器特有的问题。但这同样不能解释为什么 HTTP/1.1 分数如此之低。