为什么HTTP/2完全通过tcp进行复用呢？

据我所知，TCP将消息分解为多个段。那么，为什么再次在HTTP2上进行多路复用？复用两次有什么好处？

TCP不多路复用。TCP只是保证的消息传递流（即，重新请求丢失的数据包，并且在发生这种情况时，TCP流基本上被暂时阻止）。

如果高层应用程序协议（例如HTTP）允许发送多个消息，则 TCP作为基于分组的协议，可以用于多路复用连接。不幸的是，HTTP / 1.1不允许这样做：一旦发送了HTTP / 1.1消息，就无法在该连接上发送任何其他消息，直到该消息被完全返回为止（忽略了受严重支持的流水线概念）。这意味着HTTP / 1.1基本上是同步的，并且，如果未使用全部带宽并且其他HTTP消息已排队，则将浪费任何可用于基础TCP连接的额外容量。

为了解决这个问题，可以打开更多的TCP连接，这基本上允许HTTP / 1.1 充当（有限的）多路复用协议。如果网络带宽被充分利用，那么那些额外的连接将不会增加任何好处-这是事实，即存在容量，而其他TCP连接没有得到充分利用，这是有道理的。

因此，HTTP / 2向协议添加了多路复用，以允许单个TCP连接用于多个飞行中的HTTP请求。

它通过将基于文本的HTTP / 1.1协议更改为基于二进制的基于数据包的协议来实现此目的。这些可能看起来像TCP数据包，但是并没有真正的意义（就像说TCP类似于IP一样，因为它基于数据包是无关紧要的）。将消息拆分为数据包实际上是允许多个消息同时传输的唯一方法。

HTTP / 2还添加了流的概念，以便数据包可以属于不同的请求-TCP没有这样的概念-这才是真正使HTTP / 2多路复用的原因。

实际上，由于TCP不允许单独的独立流（即多路复用），并且由于有保证，因此实际上引入了一个新问题，即单个丢弃的TCP数据包将保留该连接上的所有 HTTP / 2流。事实上，尽管如此，实际上只有一个流应该受到影响，而其他流应该能够继续进行。在某些情况下，这甚至会使HTTP / 2变慢。Google正在尝试从TCP转向QUIC来解决此问题。

在我在这里的答案中，详细介绍了HTTP / 2下多路复用的含义（以及为什么会有很好的改进！）：HTTP / 2中多路复用的含义是什么