为啥使用多个连接进行 HTTP/2 多路复用演示？

Posted 2023-03-10

【中文标题】为啥使用多个连接进行 HTTP/2 多路复用演示？

【英文标题】：Why does a HTTP/2 multiplexing demo using multiple connections?为什么使用多个连接进行 HTTP/2 多路复用演示？

【发布时间】：2016-10-26 00:50:59

【问题描述】：

这些天我正在评估 HTTP/2（在 nginx 上），作为提高我的应用程序性能的可能候选者。

我在看 this 不错的 Akamai HTTP2 演示。从这个演示中我可以看到“http2”部分的加载速度要快得多，这显然要归功于 HTTP2 多路复用功能。

所以，我决定再仔细看看。我打开了 Chrome（版本 51）开发者工具并检查了网络面板。

我希望看到一个单一的网络连接，处理所有请求（例如多路复用）。

但是，我看到发出了多个连接，每个图像图块一个：

此外，我发现几乎每个请求都有延迟（“停滞”）：

我预计（与 HTTP1 相反）所有请求都将并行发出而不会延迟。有人可以帮助我了解发生了什么吗？

【参考方案1】：

您看到的不是多个连接，每个图像块一个，而是多个请求，每个图像块一个，在单个 TCP 连接上。

多路复用的事实是显而易见的，因为有大量的请求（数十甚至数百个）同时发送。 看看请求是如何垂直对齐的。

将其与 HTTP/1.1 配置文件进行比较，您会看到一个阶梯式、ziggurat 样式的配置文件，因为一次只能（通常）发送 6 个请求。例如，请参阅我在 39:54 上的演示文稿。

因此，您看到的是 HTTP/2 等多路复用协议的预期配置文件。

您看到的这些请求的微小“停滞”延迟可能是由于内部实现延迟（例如排队）以及 HTTP/2 协议细节（例如流量控制）造成的。