与HTTP2服务器推送相比，HTTP2多路复用是否具有显著的性能优势？

Question

HTTP2多路复用使用相同的TCP连接，从而减少了到同一主机的连接时间。

但对于HTTP2服务器推送，除了HTTP2多路复用在请求每个资源时需要的往返时间之外，是否有任何显着的性能优势。

Answer 1

我对此做了一个演示，你可以找到here。

特别是，该演示(从36:37开始)展示了仅使用多路复用，然后添加HTTP/2推送可以获得的好处。

剧透:相对于HTTP/1.1，HTTP/2多路复用和推送的组合产生了惊人的更好的结果。

话又说回来，每个案例都是不同的，所以你必须实际衡量你的案例。但是HTTP/2产生比HTTP/1.1更好的性能的潜力确实很大，而且很多(大多数？)案例将从中受益。

Answer 2

我不确定你在这里问的到底是什么，或者它是否适合StackOverflow，但我会尝试回答。如果这不是您正在寻找的答案，请重新表述问题，以便我们能够了解您正在寻找的究竟是什么。

您说得对，HTTP/2使用多路复用，这确实消除了对多个连接的需求(以及设置和管理它们所需的时间和资源)。然而，它远不止于此，因为它不受限制(浏览器通常会将每个主机的连接限制为4-6个)，并且还允许“相似”的连接(相同的IP和相同的证书，但不同的主机名)共享连接。基本上，它解决了HTTP/1的请求/响应方法所意味着的资源排队问题，并减少了HTTP/1所需的有限多个连接。这也减少了对其他变通方法的需求，如分片、精灵文件、拼接……等。

是的，HTTP/2服务器推送节省了一次往返。因此，当你请求一个网页时，它会同时发送绘制页面所需的HTML和CSS，因为服务器知道你将需要CSS，因为只需发送HTML，等待你的web浏览器获取它，解析它，查看它需要CSS，并请求CSS文件并等待它下载，这是没有意义的。

我不确定你是不是在暗示往返时间如此之短，以至于HTTP/2服务器推送几乎没有收益，因为现在由于HTTP/2多路复用，请求文件时没有延迟？如果是这样的话，情况并非如此--在推送资源方面有很大的收获，特别是阻止像CSS这样的资源，在屏幕上绘制单个内容之前，浏览器会等待这些资源。虽然多路复用减少了发送请求的延迟，但它不会减少传输到服务器的请求的延迟，现在是在服务器上响应并发回请求。虽然这些听起来很小，但它们很明显，会让网站感觉很慢。

所以，是的，目前，HTTP/2服务器推送的主要好处是减少了往返时间(关键资源基本上为零)。

然而，我们还处于这方面的初级阶段，出于性能或其他原因，还有其他潜在的用途。例如，您可以将其用作区分内容优先级的方法，以便在浏览器可能会首先请求CSS和Javascript，然后将图像留到以后时，可以提早推送重要的图像。服务器推送还可以消除对内联CSS的需求(它会用样式表的副本使页面膨胀，然后可能需要Javascript加载适当的CSS文件)-另一个HTTP/1.1性能解决方案。我认为观察未来几年HTTP/2服务器推送会发生什么，这将是非常有趣的。

话虽如此，HTTP/2服务器推送仍然存在一些重大挑战。最重要的是，如何防止通过推送浏览器已经缓存的资源来浪费带宽？很可能会为此添加摘要HTTP报头，但仍在讨论中。这导致了如何以最好的方法实现HTTP/2服务器推送-对于web浏览器，web服务器和web开发人员？HTTP/2 spec在如何实现这一点上有点含糊，这让它留给不同的web服务器，特别是提供不同的方法来向服务器发送信号来推送资源。

正如我所说的，我认为这是HTTP/2中可能导致一些非常有趣的应用程序的部分之一。我们生活在一个有趣的时代。