问HTTP/2及文件下载

EN

由于两个主要原因:帧开销和流量控制，HTTP/2文件下载速度比HTTP/1.1慢一些。

在HTTP/1.1中，如果使用Content-Length分隔的下载，则下载的唯一字节是内容字节。但是，在HTTP/2中，每个DATA帧为帧头携带9个额外字节。在正常的最大帧大小为16384字节时，这是一个小开销，但它是存在的。

HTTP/2流控制是导致可能减速的更大因素。客户端必须确保放大默认的会话和流控制窗口，在默认情况下这两个窗口都是65535字节。

HTTP/2的工作方式是，服务器为每个HTTP/2会话(连接)和该会话中的每个流保留一个发送窗口。下载开始时，服务器只有权为该流或该会话发送发送窗口所允许的若干字节，无论哪种字节首先耗尽。然后，它必须等待客户端发送WINDOW_UPDATE帧，以补充流和会话流控制窗口，告诉服务器客户端已准备好接收更多数据。

对于像默认窗口这样的小窗口，这种机制可能会由于客户机和服务器之间的网络延迟而降低下载性能，特别是如果它是天真地实现的话。服务器将在大部分时间处于停滞状态，等待客户端发送WINDOW_UPDATE，以便服务器能够发送更多的数据。

多路复用起着双重作用。虽然它允许同时启动多个文件的下载(可能比HTTP/1.1多很多文件，这可能由于它只能打开较少的连接而受到限制)，但为每个流下载的数据确实有助于减少会话发送窗口。每个流可能仍然有一个未耗尽的发送窗口(因此它可以发送更多的数据)，但是会话窗口已经耗尽，因此服务器必须停止运行。流正在相互竞争，以使用会话发送窗口。服务器实现也很重要，因为它必须正确地从多个流中交织帧。

话虽如此，HTTP/2仍然有可能实现与HTTP/1.1的奇偶，前提是客户端和服务器都有相当高级的实现，并且有足够的调优旋钮来控制关键参数。

理想情况下，在客户端：

• 能够控制会话和流初始流控制窗口。
• 一个很好的实现，在服务器仍在下载时将WINDOW_UPDATE帧发送给服务器，这样服务器就不会停止；这可能需要根据带宽延迟积 (类似于TCP所做的)自调优功能。

理想情况下，在服务器上：

• 能够正确地从同一会话的多个流交织帧(例如，避免下载第一流的所有帧，然后是第二流的所有帧等，而是第一流的一个帧，然后是第二流的一个帧，然后再次下载第一流的一个帧，等等)。

[免责声明，我是防波堤的HTTP/2维护者]

Jetty9.4.x支持上述所有特性，因为我们已经与社区和客户合作，以确保HTTP/2下载尽可能快。

我们在服务器上实现了适当的交织，Jetty的HttpClient和HTTP2Client分别提供了高级别和低级别的API来处理HTTP和HTTP/2请求。流控制是在BufferingFlowControlStrategy中实现的，允许在发送WINDOW_UPDATE帧时进行优化(尽管还没有动态)。客户端还具有配置初始流控制窗口的选项。Jetty中的所有内容都是可插拔的，因此您可以编写更高级的流控制策略。

即使您不使用Java或Jetty，也要确保分析(或编写)您在客户机和服务器上使用的库，以便它们提供上述特性。

最后，您需要尝试和度量；通过适当的HTTP/2实现和配置，应该发挥多路复用的作用，从而提高客户机和服务器上的并行性，降低资源利用率，从而使您比HTTP/1.1具有优势。