在HTTP/2中，多路复用意味着什么

Question

有人能解释一下与HTTP/2相关的多路复用以及它是如何工作的吗？

Answer 1

请求多路复用

HTTP/2可以通过单个TCP连接并行发送多个数据请求。这是HTTP/2协议最高级的功能，因为它允许您从一台服务器异步下载web文件。大多数现代浏览器将TCP连接限制在一台服务器上。这减少了额外的往返时间（RTT），使您的网站在没有任何优化的情况下加载得更快，并且使域切分变得不必要。

Answer 2

由于@Juanma Menendez的答案是正确的，而他的图表令人困惑，因此我决定对其进行改进，澄清多路复用和流水线之间的区别，这两个概念经常被混淆。

流水线（HTTP/1.1）

通过同一HTTP连接发送多个请求。回复的接收顺序相同。如果第一个响应需要很多时间，其他响应必须排队等待。与CPU管道类似，在CPU管道中，一条指令被提取，另一条指令被解码。多条指令同时运行，但它们的顺序保持不变。

多路复用（HTTP/2）

通过同一HTTP连接发送多个请求。响应按任意顺序接收。无需等待阻碍他人的缓慢响应。类似于现代CPU中的无序指令执行。

希望改进后的图像能澄清这一区别：

Answer 3

简单地说，多路复用允许浏览器在同一个连接上同时发出多个请求，并以任意顺序接收回请求。

现在我们来看看更复杂的答案。。。

当你加载一个网页时，它会下载HTML页面，它会看到它需要一些CSS，一些JavaScript，一堆图像。。。等

在HTTP/1.1下，您一次只能在您的HTTP/1.1连接上下载其中一个。因此，您的浏览器会下载超文本标记语言，然后它会询问CSS文件。当它返回时，它会询问JavaScript文件。当它返回时，它会询问第一个图像文件...等等。HTTP/1.1基本上是同步的-一旦您发送请求，您就会被卡住，直到您得到响应。这意味着大多数时候浏览器并没有做很多事情，因为它已经发出了一个请求，正在等待响应，然后再发出另一个请求，然后正在等待响应...等等。当然，具有大量JavaScript的复杂站点确实需要浏览器进行大量处理，但这取决于正在下载的JavaScript，因此，至少在开始时，继承到HTTP/1.1的延迟确实会导致问题。通常服务器也没有做太多事情（至少每个请求——当然它们对繁忙的站点来说是累加的），因为它应该几乎立即响应静态资源（如CSS、JavaScript、图像、字体......等等），希望即使是动态请求（需要数据库调用等）也不会太久。

因此，当今网络上的一个主要问题是在浏览器和服务器之间发送请求的网络延迟。它可能只有几十毫秒或几百毫秒，看起来可能不多，但它们加起来往往是网页浏览中最慢的部分——尤其是当网站变得更复杂，需要额外资源（正如它们所得到的那样），并且越来越多地通过移动设备接入互联网（延迟比宽带慢）。

作为一个例子让我们假设有10个资源，你的网页需要加载后超文本标记语言本身加载（这是一个非常小的网站，以今天的标准，因为100资源是常见的，但我们会保持简单，并继续使用这个例子）。并且让我们说每个请求需要100ms通过Internet到Web服务器并返回并且两端的流转时长可以忽略不计（为了简单起见，让我们说0为这个例子）。由于您必须发送每个资源并一次等待一个响应，这将需要10*100ms=1,000ms或1秒下载整个站点。

为了解决这个问题，浏览器通常会打开到web服务器的多个连接（通常是6个）。这意味着浏览器可以同时发出多个请求，这要好得多，但代价是必须设置和管理多个连接（这会影响浏览器和服务器）的复杂性。让我们继续上一个例子，并且假设有4个连接，为了简单起见，让我们假设所有请求都是相等的。在这种情况下，您可以在所有四个连接中拆分请求，这样两个将有3个资源要获取，两个将有2个资源要获取总共10个资源（3 2=10）。在这种情况下，最坏的情况是3次循环或300ms=0.3秒——这是一个很好的改进，但这个简单的例子不包括设置这些多个连接的成本，也不包括管理它们对资源的影响（我在这里没有讨论这个问题，因为这个答案已经足够长了，但设置单独的TCP连接确实需要时间和其他资源——进行TCP连接、HTTPS握手，然后由于TCP启动缓慢而全速启动）。

HTTP/2允许你在同一个连接上发送多个请求，所以你不需要像上面那样打开多个连接。所以你的浏览器可以说“给我这个CSS文件。给我那个JavaScript文件。给我image1.jpg。给我image2.jpg…等等”，以充分利用单一连接。这有一个明显的性能优势，即不会延迟那些等待免费连接的请求的发送。所有这些请求都以（几乎）并行的方式通过互联网到达服务器。服务器对每一个都做出响应，然后它们开始返回。事实上，它甚至比这更强大，因为web服务器可以按感觉到的任何顺序响应它们，并以不同的顺序发回文件，甚至可以将请求的每个文件分解成碎片，并将文件混合在一起。这样做的第二个好处是，一个重请求不会阻塞所有其他后续请求（称为行首阻塞问题）。然后，网络浏览器的任务是将所有部件重新组合在一起。在最好的情况下（假设没有带宽限制——见下文），如果所有10个请求几乎同时并行发出，并且服务器立即响应，这意味着您基本上有一次往返或100毫秒或0.1秒的时间来下载所有10个资源。这没有HTTP/1.1的多个连接的缺点！随着每个网站上资源的增长，这一功能的可扩展性也会大大提高（目前，浏览器在HTTP/1.1下最多可打开6个并行连接，但随着网站变得更复杂，这一功能是否会增长？）。

这个图表显示了不同之处，还有一个动画版本。

注意：HTTP/1.1确实有管道的概念，它还允许同时发送多个请求。然而，它们仍然必须按照被请求的顺序全部返回，因此远不如HTTP/2好，即使在概念上是相似的。更不用说浏览器和服务器对它的支持非常差，以至于很少使用它。

下面的评论中强调的一件事是带宽对我们的影响。当然，您的Internet连接受到您可以下载多少的限制，而HTTP/2并没有解决这个问题。因此，如果上面示例中讨论的10个资源都是大量打印质量的图像，那么它们的下载速度仍然很慢。然而，对于大多数网络浏览器来说，带宽不是问题，而是延迟问题。因此，如果这10个资源是小项（尤其是CSS和JavaScript等文本资源，它们可以被gzip压缩为很小），这在网站上很常见，那么带宽并不是真正的问题——问题往往在于资源的庞大数量，HTTP/2希望解决这个问题。这也是为什么在HTTP/1.1中使用连接作为另一种解决方法，因此例如，所有CSS通常都连接到一个文件中：下载的CSS数量是相同的，但作为一个资源进行操作会带来巨大的性能优势（尽管HTTP/2的性能较低，事实上有人说连接应该是HTTP/2下的反模式——尽管也有反对完全取消它的论点）。

把它作为一个现实世界的例子：假设你必须从一家商店订购10件物品以便送货上门：

>

具有多个连接的HTTP/1.1意味着您可以同时拥有（有限的）数量的独立订单。

带有流水线的HTTP/1.1意味着您可以一个接一个地要求所有10件商品，而无需等待，但它们都会按照您要求的特定顺序到达。如果一件商品缺货，那么您必须等待它，然后才能得到您在那之后订购的商品——即使那些后来的商品实际上有库存！这要好一点，但仍然会延迟，假设大多数商店无论如何都不支持这种订购方式。

HTTP/2意味着您可以按任何特定顺序订购商品，而不会出现任何延迟（类似于上文）。商店会在他们准备好后发货，因此他们可能会以不同于您要求的订单到达，他们甚至可能会分割商品，以便订单的某些部分先到达（因此比上述更好）。最终，这应该意味着你1）整体上更快地完成所有事情，2）可以在每件商品到达时就开始工作（“哦，这并不像我想象的那么好，所以我可能还想点其他东西，或者取而代之”）。

当然，你仍然受到邮递员货车大小（带宽）的限制，所以如果当天的包裹已经满了，他们可能不得不把一些包裹留在分拣办公室，直到第二天，但与实际来回发送订单的延迟相比，这几乎不是问题。大多数网页浏览涉及来回发送小信件，而不是笨重的包裹。

希望有帮助。