HTTP/3:从 SPDY 到 QUIC

HTTP/3 和 HTTP/2 以及 HTTP/1.1 最大的不同应该是 HTTP/3 颠覆了 HTTP 使用 TCP 的「传统」。如果要写一系列和 HTTP/3 相关的文章,不能不提一提 QUIC 的故事。

硬币:HTTP/2 的正面和反面

在这之前,我用了三四千字写了一篇 HTTP/2 三大特性的介绍、以及讲述了如何将其用于更快速的递送静态资源,如果你还没有读过那篇「静态资源递送:HTTP/2 和 Server Push」的话,其实无伤大雅,反正我要把 HTTP/2 再总结一次。

HTTP/2 的多路复用使得只需要一个 TCP 连接、一股数据流就可以递送多个静态资源,在这基础上 HPACK 头部压缩技术使得在响应头上消耗的流量进一步减少。但是,HTTP/2 带来最深远的变革是,一个资源需要一个 TCP 连接的时代过去了。

但是,HTTP/2 毕竟还是基于 TCP 的。丢包重传注定要面对「头部阻塞」。如果一个 TCP 连接中某个数据包丢失,那么整个 TCP 数据流必须暂停,丢失的数据包需要重新传输,然后数据流才能继续。在弱网环境下(想象一下宇宙射线、运营商 QoS、骨干网阻塞、部署不当的 4G 基站、打开了的微波炉都会导致数据包丢失),HTTP/2 的性能甚至不如 HTTP/1.1,因为 HTTP/2 只使用一个 TCP 连接,而在 HTTP/1.1 的年代人们会通过域名散列的方式同时使用六个连接、(暂时)没有受到丢包影响的 TCP 连接仍然可以继续传输数据。

快,造个新的轮子!

如果 TCP 的头部阻塞问题无法被解决,为什么不发明一个新的协议呢?

坏消息是,现在互联网不是这么工作的。为了保证互联网的存在和工作,需要各式各样的设备:防火墙、NAT、路由器,还有一大堆其他的玩意。正是这些玩意组成了我们的互联网。互联网服务提供商(ISP)采购的设备有(很大的)可能支持常规的 TCP 和 UDP。除此以外,操作系统内核中关于网络栈的实现也需要一起更新。

对那些组成互联网的设备全部进行更新换代、以及让一堆绞尽脑汁关闭 Windows Update 的用户升级他们的操作系统,这是一项耗时漫长、不切实际且几乎不可能完成的任务。

UDP、TCP 或者,SCTP?

如果不能发明一个新的协议,那可以从 IETF 制定的 RFC 里碰碰运气、找找有没有符合要求的协议。一个想法是 HTTP 应该基于 SCTP —— 流控制传输协议,这一协议的相关规范由 RFC4960 制定。更棒的是,这个协议甚至还有现成的 UDP 实现(WebRTC)。但是:

  • SCTP 没有 TLS 支持
  • SCTP 建立连接还是需要 4 次握手
  • SCTP 在连接建立时需要协商并固定允许的数据流数量
  • SCTP 不支持 NAT

当然,也有破坏性不那么大的、对现有的 TCP 进行改造的方案。RFC7143 提出了 TCP Fast Open(一般被简称为 TFO),客户端在第一个 TCP SYN 报文中就可以包含有效数据。RFC7143 发布于 6 年前,但是对 TFO 提供兼容的操作系统和硬件仍然寥寥无几。而且似乎,针对 TFO 的 QoS 比 TFO 本身的发展还要快得多。

拥抱 QUIC

QUIC 不是什么缩写词(虽然它每个字母都是大写的)。QUIC 的意思就是 quick(有趣的事实,SPDY 的意思是 speedy),目的是为了在 TLS 的基础上修补当时 SPDY(HTTP/2 的前身)未能解决的缺陷。

正如其名,QUIC 在设计之初也是为了将数据更快的交付给最终用户。QUIC 在设计时允许在一个连接上建立两个独立平行的数据流,如果遭遇了丢包,只有某一个数据流需要暂停、而另一个数据流并不受影响。和依赖 TCP 三次握手加上 TLS 一次握手相比,QUIC 提供了 0-RTT 和 1-RTT 的握手,大大减少了协商建立新连接所需的时间;相比 TFO,QUIC 的「Early Data」在实现和使用上更加简便。

在保证快速的同时,QUIC 在设计时也强调了安全性。和 HTTP/2 不同(只有浏览器在实现 HTTP/2 时要求使用 HTTPS),QUIC 不被允许使用明文、所有握手和传输都需要加密,只有在进行加密协议协商时才会发送数个明文握手报文。

所以 QUIC 是从哪里来的?

早在 2012 年至 2015 年这段时间(是的,TFO 差不多也是那个时候提出来的),Google 就开始着手于一系列实验,这些实验的成果就是 gQUIC,类似下图的千层饼:

+-----------------+
|  HTTP Semantics |
+-----------------+
|  SPDY Syntax    |
+-----------------+
|  QUIC Packets   |
+-----------------+
|  UDP Protocol   |
+-----------------+

在当时,HTTP/2 还没有正式完成,因此 Google 仍通过 SPDY 二进制编码 HTTP 语义,同时将 SPDY 编码封装在 QUIC 数据包中通过 UDP 传输,一般被称为 gQUIC。但是,由于对 SPDY 编码方式的应用,意味着 gQUIC 只能被用于 HTTP 协议。随着 HTTP/2 正式发布,Google 也不断迭代 gQUIC、不断将 HTTP/2 的语法和编码方式添加到 gQUIC 中。

值得注意的是,gQUIC 并不通过 TLS 提供安全性。Google 造了一个新的加密方案的轮子,称作「QUIC Crypto」,而其中「快速安全握手」这一特性(复用先前会话的 Session 等信息)后来被合并到 TLS 1.3,成为 0-RTT 的一部分。

在 IETF 小组参与 QUIC 规范化后,为了改善普适性,IETF 提出了 HTTP over QUIC 和 QUIC 传输层两个概念,将 QUIC 分别用于 HTTP 和其他类型的数据传输。从这一刻开始,Google 的 gQUIC 和 iQUIC(也被称作 IETF-QUIC)开始逐渐分道扬镳(虽然 Google 继续在 gQUIC 迭代中合并 IETF 的进展、以期获得 iQUIC 的相关经验)。之后,IETF 的 HTTP over QUIC 成为了如今被称为 HTTP/3 的东西,而将 QUIC 用于其他数据传输的草案至今仍未落地。

本文作者 : Sukka
本文采用 CC BY-NC-SA 4.0 许可协议。转载和引用时请注意遵守协议、注明出处!
本文链接 : https://blog.skk.moe/post/http3-from-spdy-to-quic/

喜欢这篇文章?为什么不考虑打赏一下作者呢?

评论加载中 ...