与 HTTP/1.1 相比，HTTP/2 如何提供更快的浏览速度？

Posted 2023-02-16

【中文标题】与 HTTP/1.1 相比，HTTP/2 如何提供更快的浏览速度？

【英文标题】：How does HTTP/2 provide faster browsing speed compared to HTTP/1.1?

【发布时间】：2015-04-27 10:34:29

【问题描述】：

我正在阅读关于启动 HTTP/2 的 article。据说HTTP/2是基于SPDY（speedy）协议的，通过使用“header field compression”和“multiplexing”可以提供比HTTP/1.1更快的浏览速度。这些术语究竟是如何工作的？

我是否应该相信在 HTTP/1.1 中请求是以“一个接一个”的方式处理的？

【参考方案1】：

多路复用

在 HTTP 1.1 中，很多时间都花在等待上。浏览器发送请求并等待响应返回，然后发送另一个 GET 等。带宽使用效率低下。有时它会使用流水线，但有时请求需要等待之前完成的请求也会受到影响。线头阻塞问题。

使用多路复用，几乎没有等待，但浏览器可以一次请求数百个内容，并且它们将按照可以交付的任何顺序交付，而无需单独的流或对象相互等待。 （通过优先级和流量控制来帮助正确控制它们。）

这在高延迟连接上最为显着。有关它可以做什么的可见且清晰的演示，请参阅 golang 的 gophertiles 演示，地址为 https://http2.golang.org/gophertiles?latency=1000（需要启用 HTTP/2 的浏览器）

标题压缩

此外，HTTP/2 提供了标头压缩，使客户端能够在 TCP 连接生命周期的早期压缩更多请求。在新 TCP 连接的早期慢启动阶段，塞入更多请求以使响应更早返回可能很有价值。 HTTP 标头本质上是极其重复的。

服务器推送

HTTP/2 服务器可以在客户端请求之前将数据发送到客户端就像客户端请求它！如果服务器认为客户端也可能想要/需要它，则可以节省一半的 RTT。

【讨论】：

我想这就是我正在寻找的答案:)`

【参考方案2】：

从 HTTP/2 开始，标头和 HTTP 响应内容都可以被压缩。在 HTTP/1.1 中，标头永远不会与内容相反地压缩（使用 Content-Encoding 标头指定）。

多路复用与服务器推送有关。实际上，当服务器发送一个 html 页面时，它可以使用相同的连接来推送额外的资源，如 css 和 javascript 文件。如果 HTML 页面需要加载这些额外的脚本，则不会再向服务器发送请求，因为它们之前已经发送过。

【讨论】：

大多数压缩算法是 deflate 和 gzip，但从技术上讲，协议允许指定任何其他方法，因为您明确指出在 Content-Encoding 标头中使用哪一种）。

多路复用并不是真正的服务器推送。它是关于一次允许多个同时传输。