HTTP/2.0 多路复用如何与 TCP 配合使用？

Question

我不是专业的网络工程师，所以我希望我的问题不会显得含糊或na\xc3\xafve。

\n\n

HTTP/2.0 中的多路复用似乎利用单个 TCP 连接来同时处理多个/不同的请求，这样我们就可以避免队头阻塞问题。我想知道在数据重组的意义上它是如何与底层 TCP 连接一起工作/重叠的意义上它是如何与底层 TCP 连接一起工作/重叠的。

\n\n

TCP 还确保接收方接收到的数据 (D) 被重建，即使构成 D 的数据包乱序（或丢失）接收，以便在接收方重新构建 D，然后将其交给应用程序。

\n\n

我的问题是：HTTP/2.0 中的帧概念如何适应 TCP 数据包重组以在接收端组成完整的消息？哪一个先发生？或者，帧和数据包之间存在什么样的映射（一对一、一对多等）？简而言之，他们如何协同工作？

\n

Answer 1

HTTP/2 数据包作为一个或多个 TCP 数据包发送。与 TCP 数据包最终作为 IP 数据包发送的方式相同。

\n

这确实意味着，尽管 HTTP/2 在应用层 (HTTP) 进行了多路复用，但它在传输层 (TCP) 上并没有真正独立的流，而且 HTTP/2 的一个问题是我们刚刚移动了队列的头部（ HOL）从HTTP层到TCP层的阻塞问题。

\n

让\xe2\x80\x99s看一个例子：一个例子网页需要下载10张图片才能显示。

\n

在 HTTP/1.1 下，浏览器将打开 TCP 连接，触发第一个请求，然后因为无法使用该 TCP 连接发出后续请求而卡住。尽管事实上 TCP 连接在收到响应之前什么都不做，并且 TCP 层没有任何东西阻止它。这纯粹是一个 HTTP 限制，主要是因为 HTTP/1 是基于文本的，因此不可能\xe2\x80\x99 混合请求位。HTTP/1.1 确实有 HTTP 管道的概念，它允许发送后续请求，但它们仍然必须按顺序返回。而且它的支持非常差。相反，作为一种解决方法，浏览器打开了多个连接（通常是 6 个），但这也有很多缺点（创建速度慢、跟不上速度并且不可能对它们进行优先级排序）。

\n

HTTP/2 允许在同一个 TCP 连接上发送这些后续请求，然后以任意顺序接收所有请求的位并将它们拼凑在一起进行处理。因此，请求的第一张图像实际上可能是最后收到的图像。这对于慢速连接（其中发送延迟占总时间的很大一部分）或当服务器与其他请求相比可能需要一段时间处理某些请求时（例如，如果必须从磁盘获取第一个图像但第二个图像已经在缓存中可用，那么为什么不使用连接来发送第二个图像）。这就是为什么 HTTP/2 通常比 HTTP/1.1 更快、更好的原因 - 因为它更好地使用 TCP 连接并且不那么浪费。

\n

然而，由于 TCP 是一个有保证的、有序的协议，它不知道更高级别的应用程序 (HTTP) 使用它做什么，因此如果 TCP 数据包丢失，这确实会给 HTTP/2 带来一些问题。

\n

假设\xe2\x80\x99s 表示这 10 个图像全部按顺序返回。但是第一张图像的数据包丢失了。理论上，如果 HTTP/2 确实是由独立的流组成的，那么浏览器可以显示最后 9 个图像，然后重新请求丢失的 TCP 数据包，然后显示第一个图像。相反，发生的情况是所有 10 个图像都被搁置，等待重新发送丢失的 TCP 数据包，然后 TCP 让\xe2\x80\x99s 上层 HTTP 知道已收到哪些消息。

\n

因此，在有损环境中，HTTP/2 的性能明显比具有 6 个连接的 HTTP/1.1 差。

\n

这在创建 HTTP/2 时就已众所周知，但在大多数情况下，HTTP/2 速度更快，因此他们无论如何都会发布它，直到他们能够解决该问题。

\n

HTTP/3 旨在解决剩下的问题。它通过从 TCP 转向一种名为 QUIC 的新协议来实现这一点，与 TCP 不同，QUIC 是通过内置多路复用的思想来实现的。QUIC 建立在 UDP 之上，而不是尝试创建一个全新的低级协议，因为该协议得到了很好的支持。但 QUIC 非常复杂，需要一段时间才能实现，这就是为什么他们没有阻止 HTTP/2 实现这一点，而是将他们所拥有的内容作为一个步骤发布。

\n