HTTP/3 是下一代跨 Web 的网络通信协议,这意味着它会部分取代 HTTP/1 和 HTTP/2。离2月在苏黎世召开的下一届QUIC工作组会议还有一个月的时间,回顾一下 HTTP/3 的承诺和当前客户端/服务器的支持情况可能会非常有助益。
HTTP/3 承诺让互联网连接更快、更稳定和更安全。它的前身为“HTTP over QUIC”,其目标是让 HTTP 在谷歌自己的传输层协议 QUIC 上运行,随后,它被提议为IETF,目前它是Internet草案。在 2018 年 10 月,IETF HTTP & QUIC 工作组联席主席 Mark Nottingham提议将HTTP over QUIC重命名为HTTP/3,以澄清其本质特点以及与 QUIC 的独立性。
QUIC 是 HTTP/3 的关键元素,因为它是主要特性的基础。QUIC 构建在 UDP 之上,致力于解决使用 TCP 协议的主要问题,比如,连接建立的延迟以及在包丢失的情况下多个流的处理。TCP 延迟问题源于其拥塞控制算法的需求,该算法要求在拥塞发生之前会缓慢地开始(slow start)评估可以发送多少流量。在 HTTP/1.0 中,每个 TCP 请求/响应交换都会被分配一个新的连接,因此会导致启动缓慢的问题。
从此之后,规避 TCP 启动慢的尝试一直是 HTTP 协议改善的核心。
HTTP/1.1引入了“keep-alive”连接,允许在同一个 TCP 连接上对多个请求-响应交换进行序列化,因此不需要为每个请求都设置新的连接建立阶段。然而,HTTP/1.1 的 keep-alive 连接不支持同时发送多个请求,随着 Web 页面日益复杂,这导致了新的瓶颈。
HTTP/2则源自现在已被弃用的SPDY协议,它引入了在同一连接中嵌入第一等流的概念。这使得在保证多路复用的同时实现请求-响应交换成为可能,但是它有一个主要的缺陷:当包丢失增加时,HTTP/2的性能会由于TCP处理包重传的方式(HOL阻塞)而下降。这种影响可能非常严重,因为所有流都共享相同的连接。当数据包丢失超过一个给定的阈值时,HTTP/1的多连接甚至会比HTTP/2运行地更高效。
如前文所述,QUIC 提供了对流的第一等支持,这解决了 HTTP/2 中连接初始化缓慢的问题。另外,它可以对它们进行单独处理,从而解决了由于包丢失而导致的性能问题。采用 QUIC 作为传输层协议是 HTTP/3 与 HTTP/2 最大的区别。由于 QUIC 原生实现了大量与流管理相关的特性,这些特性是 HTTP/2 规范的组成部分,因此可以从 HTTP/3 中删除它们。此外,由于HTTP/2 HPACK报头压缩严重依赖于TCP向端点传递包的顺序,所以需要采用 QUIC 来创建新的 HTTP 报头压缩方案,即QPACK。
最近几年来,谷歌一直在使用QUIC提供自己的服务,包括搜索、YouTube 等,而且在 Chrome 中也支持它。曾经有一段时间,在与支持 QUIC 的谷歌服务通信时,Chrome 是唯一的手段。最近,Mozilla在Firefox 72中也增加了对HTTP/3的支持,尽管仍处于试验阶段。命令行工具curl在 7.66.0 版本中也增加了对 HTTP/3 的支持以及许多其他特性。在服务器端,LightSpeed和Nginx支持 HTTP/3。
在云方面,除了谷歌之外,Cloudflare 几个月前宣布已经为部分客户启用了对HTTP/3的初步支持。Cloudflare 也是Quiche背后的公司,Quiche 是一个支持HTTP/3客户端和服务器实现的开源Rust库。
如前所述,HTTP/3 仍然正在由 IETF 进行定义,还没有确定正式的发布日期。与此同时,在世界范围内,HTTP/3 的使用正在增长,全世界使用它的服务接近300,000个。谷歌仍然是部署 HTTP/3 的最重要组织,但是其他几个组织也占据了重要的份额。InfoQ 将继续及时报道 HTTP/3,让我们的读者了解互联网的最新变革。
原文链接:
评论