http2 - 为什么 HTTP/2 多路复用虽然 tcp 做同样的事情？

Question

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

Answer 1

TCP 没有被多路复用。 TCP 只是一个有保证的消息流(即重新请求丢失的数据包，并且在发生这种情况时 TCP 流基本上被暂时阻塞)。

TCP，作为基于数据包的协议(protocol)，可以如果更高级别的应用程序协议(protocol)(例如 HTTP)允许发送多个消息，则用于多路复用连接。不幸的是，HTTP/1.1 不允许这样做:一旦发送了 HTTP/1.1 消息，在该消息完全返回之前，不能在该连接上发送其他消息(忽略严重支持的流水线概念)。这意味着 HTTP/1.1 基本上是同步的，如果没有使用全部带宽并且其他 HTTP 消息排队，那么它会浪费任何可以用于底层 TCP 连接的额外容量。

为了解决这个问题，可以打开更多的 TCP 连接，这基本上允许 HTTP/1.1 像一个(有限的)多路复用协议(protocol)一样工作。如果网络带宽被充分利用，那么这些额外的连接不会增加任何好处——事实上有容量并且其他 TCP 连接没有被充分利用，这意味着这是有道理的。

因此 HTTP/2 在协议(protocol)中添加了多路复用，以允许将单个 TCP 连接用于多个正在运行的 HTTP 请求。

它通过将基于文本的 HTTP/1.1 协议(protocol)更改为基于数据包的二进制协议(protocol)来实现这一点。这些可能看起来像 TCP 数据包，但实际上并不相关(就像说 TCP 与 IP 相似，因为它是基于数据包的并不相关)。将消息拆分为数据包实际上是允许多个消息同时传输的唯一方法。

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

事实上，因为 TCP 不允许单独的、独立的流(即多路复用)，并且因为它是有保证的，所以这实际上引入了一个新问题，即单个丢弃的 TCP 数据包保持 全部 该连接上的 HTTP/2 流，尽管实际上只有一个流应该受到影响，并且尽管如此，其他流应该能够继续。在某些情况下，这甚至会使 HTTP/2 变慢。 Google 正在尝试从 TCP 迁移到 QUIC来解决这个问题。

更多关于 HTTP/2 下多路复用意味着什么(以及为什么它是一个很好的改进!)的详细信息，请参见我的回答:What does multiplexing mean in HTTP/2