我不是专业的网络工程师，所以我希望我的问题不会显得模棱两可或天真。
HTTP / 2.0中的多路复用似乎将单个TCP连接同时用于多个/不同请求，因此我们避免了行头阻塞问题。我想知道它与感知数据reassembly中的基础TCP连接如何工作/重叠。
TCP还确保即使在接收方无序接收（或丢失）构成D的数据包的情况下，也重构了在接收方接收的数据（D），以在接收方建立D，然后将其移交给应用程序。
我的问题是：HTTP / 2.0中的帧概念如何适合/重新组合TCP数据包以在接收方组成整个消息？哪一个先发生？或者，帧和数据包之间存在什么样的映射（一对一，一对多等）？简而言之，它们如何协同工作？
属于同一流或属于不同流的一系列HTTP / 2帧无关紧要，只是一系列字节。
TCP不会解释这些字节。TCP发送方只是将字节打包到TCP帧中并一起发送。TCP接收器接收TCP帧，然后重新组合碰巧形成一系列HTTP / 2帧的字节。
TCP和HTTP / 2不能真正一起工作，因为TCP并不知道它在传输什么，它只是一系列不透明的字节。
因此，TCP帧和HTTP / 2帧之间没有映射。
[考虑到在大多数情况下，HTTP / 2是加密的，因此您有TCP传输不透明的字节，而这些字节恰好是TLS帧字节（可能是分段的-即TCP帧可能包含1.5 TLS帧，而其余的TLS帧字节在后续的TCP中帧）;每个TLS帧均包含不透明字节，这些字节恰好是HTTP / 2帧字节（也可能是分段的）。
HTTP / 2数据包作为一个或多个TCP数据包发送。与TCP数据包最终以IP数据包（或数据报）的发送方式相同。
这的确意味着，即使HTTP / 2在应用程序层（HTTP）上进行了多路复用，它在传输层（TCP）上也没有真正独立的流，而HTTP / 2的一个问题是我们只是将其开头从HTTP层到TCP层的线路（HOL）阻塞问题。
让我们看一个例子：一个例子网页需要下载10张图片才能显示。
在HTTP / 1.1下，浏览器将打开TCP连接，触发第一个请求，然后由于无法使用该TCP连接发出后续请求而被卡住。尽管事实是TCP连接在获得响应之前没有执行任何操作，并且在TCP层没有停止响应的事实。这纯粹是HTTP的限制，主要是因为HTTP / 1是基于文本的事实，因此无法混淆请求的各个部分。 HTTP / 1.1确实具有HTTP流水线的概念，该概念允许发送后续请求，但仍然必须按顺序返回。而且它的支持非常差。相反，作为一种变通办法，浏览器打开了多个连接（通常为6个），但同时也存在许多缺点（创建速度慢，无法加快速度，并且无法优先考虑它们）。
HTTP / 2允许这些后续请求在同一TCP连接上发送，然后以任意顺序接收所有请求的位，并将它们组合在一起进行处理。因此，请求的第一个图像实际上可能是最后收到的图像。这对于连接速度慢（发送延迟占总时间的很大一部分）或服务器处理一些请求（相对于其他请求）要花费一些时间（例如，如果必须从磁盘中获取第一个映像而又需要从磁盘中获取）却特别有用。第二个在缓存中已经可用，那么为什么不使用该连接发送第二个图像）。这就是为什么HTTP / 2通常比HTTP / 1.1更快和更好的原因-因为它更好地使用了TCP连接并且没有那么浪费。
但是，由于TCP是有保证的有序协议，不知道更高级别的应用程序（HTTP）将其用于什么，因此，如果TCP数据包丢失，确实会给HTTP / 2带来一些问题。] >
假设这10张图片全部按顺序返回。但是第一个图像的数据包丢失了。从理论上讲，如果HTTP / 2真正由独立的流组成，则浏览器可以显示最后9个图像，然后重新请求丢失的TCP数据包，然后显示第一个图像。取而代之的是，在TCP让上层HTTP知道已接收到哪些消息之前，所有10张图像都被保留，等待丢失的TCP数据包重新发送。
因此，在有损环境中，HTTP / 2的性能显着低于具有6个连接的HTTP / 1.1。
这在创建HTTP / 2时就已经众所周知，但是在大多数情况下，HTTP / 2的速度更快，因此他们还是放开了它，直到可以解决这种情况为止。
HTTP / 3看起来可以解决这种剩余情况。它是通过从TCP转移到新协议QUIC来实现的，该协议是TCP中内置的多路复用思想，它是由TCP / IP协议内置的。 QUIC建立在UDP之上，而不是尝试创建一个全新的低层协议，因为它得到了很好的支持。但是QUIC非常复杂，要花一些时间才能到达这里，这就是为什么他们没有举起HTTP / 2拥有它，而是在整个过程中释放了他们拥有的东西的原因。