据我所知，TCP 将消息分成段。那么，为什么 HTTP2 又要进行多路复用呢？两次复用有什么好处？
TCP 不是多路复用的。 TCP 只是一个有保证的消息流（即，重新请求丢失的数据包，并且在发生这种情况时 TCP 流基本上暂时被阻止）。
TCP作为基于数据包的协议，can如果更高级别的应用程序协议（例如 HTTP）允许发送多个消息，则可用于多路复用连接。不幸的是，HTTP/1.1 不允许这样做：一旦发送了 HTTP/1.1 消息，就不能在该连接上发送其他消息，直到该消息完整返回（忽略不支持的管道概念）。这意味着 HTTP/1.1 基本上是同步的，如果未使用全部带宽且其他 HTTP 消息排队，则会浪费可用于底层 TCP 连接的任何额外容量。
为了解决这个问题，可以打开更多的 TCP 连接，这基本上允许 HTTP/1.1act就像（有限的）多路复用协议。如果网络带宽被充分利用，那么这些额外的连接不会增加任何好处——事实是存在容量并且其他 TCP 连接没有被充分利用，这意味着这是有道理的。
因此，HTTP/2 在协议中添加了多路复用，以允许单个 TCP 连接用于多个正在进行的 HTTP 请求。
它通过将基于文本的 HTTP/1.1 协议更改为基于数据包的二进制协议来实现此目的。这些可能看起来像 TCP 数据包，但这并不真正相关（就像说 TCP 类似于 IP 因为它基于数据包并不相关一样）。将消息拆分成数据包实际上是允许多个消息同时传输的唯一方法。
HTTP/2 还添加了流的概念，以便数据包可以属于不同的请求（TCP 没有这样的概念），这才是 HTTP/2 多路复用的真正原因。
事实上，因为 TCP 不允许单独的、独立的流（即多路复用），并且因为它是有保证的，所以这实际上引入了一个新问题，即单个丢弃的 TCP 数据包仍然存在all该连接上的 HTTP/2 流，尽管事实上只有一个流应该真正受到影响，而其他流应该能够继续运行。在某些情况下，这甚至会使 HTTP/2 变慢。 Google 正在尝试从 TCP 转向QUIC来解决这个问题。
有关 HTTP/2 下多路复用含义的更多详细信息（以及为什么它是一个很好的改进！），请参阅我的回答：HTTP/2 中的多路复用意味着什么
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
