目录


文章目录


QUIC

QUIC(Quick UDP Internet Connections,快速 UDP 互联网连接)是一种实验性的网络传输协议。从网络层级来看,QUIC 是类似于 TCP,UDP 和 SPDY 的数据传输协议,目前正在由 Internet 工程任务组(IETF)进行标准化。

关于 QUIC 的研究始于 2010 年代初期,最初的 QUIC 协议由 Jim Roskind 在 Google 设计并于 2012 年实现。当时 Google 希望创建一个更快,更强调性能的数据传输协议来代替 HTTPS/HTTP。经过 Google 的扩大试验后,于 2013 年向全世界公开发布。

QUIC 借鉴了 TCP、UDP 和 TLS(用于加密)的原理和功能,在这个基础上优化了传输的速度。QUIC 的数据传输从第一个数据包传送(0-RTT)开始立即开始,从而减少了应用程序延迟时间。并且可以在数据量已满时调整管理流程(拥塞控制),从而更快更安全。QUIC 协议在登录成功、推拉流成功的耗时,大幅低于 TCP 协议,优化百分比在 30% 以上,极端场景甚至超过 90%。

互联网协议 — QUIC 快速 UDP 互联网连接_流量控制

为满足不局限于 HTTP 的传输需求,IETF QUIC 协议的架构被分为两个独立的层:传输层 QUIC 和 “基于 QUIC 的 HTTP”(HTTP over QUIC)层。

2018 年,基于 QUIC 协议的 HTTP(HTTP over QUIC)也就是 HTTP/3,正式被确定为下一代网络规范。HTTP/3 作为超文本传输协议的下一个主要迭代版本,目前仅被全球 3% 的互联网网站所使用。但好消息是,微软、谷歌等科技巨头都表现出了浓厚的兴趣并付出了实际的支持行动,结合 QUIC 协议深度优化信令服务,新形态的互联网技术,可能不用等太久了。

互联网协议 — QUIC 快速 UDP 互联网连接_数据_02

QUIC 的特性

互联网协议 — QUIC 快速 UDP 互联网连接_服务器_03

基于 UDP

QUIC 是基于 UDP 在用户空间实现的传输协议。如果不观察细节,你会觉得 QUIC 跟 UDP 报文差不多。这也意味着它使用 UDP 端口号来识别指定机器上的特定服务器。目前已知的所有 QUIC 实现都位于用户空间,这使它能得到更快速的迭代(相较于内核空间中的实现)。

可靠性

虽然 UDP 不提供可靠的传输,但 QUIC 在基于 UDP 之上增加了一层带来可靠性的层。它提供了数据包重传、拥塞控制、调整传输节奏(pacing)以及其他一些 TCP 中存在的特性。只要连接没有中断,从 QUIC 一端传输的数据迟早会出现在另一端,这是可靠的。

数据流

类似 SCTP、SSH 和 HTTP/2,QUIC 在同一物理连接上可以有多个独立的逻辑数据流。这些数据流并行在同一个连接上传输,不影响其他流。连接在两个端点之间经过类似 TCP 连接的方式协商建立。QUIC 连接基于 UDP 端口和 IP 地址建立,而一旦建立,连接通过其连接ID(connection ID)关联。

在已建立的连接上,双方均可以建立传输给对方的数据流。单一数据流的传输是可靠、有序的,但不同的数据流间可能无序传送。QUIC 可对连接和数据流分别进行流量控制(flow control)。

有序交付

QUIC 的单个数据流可以保证有序交付,但多个数据流之间可能乱序。这意味着单个数据流的传输是按序的,但是多个数据流中接收方收到的顺序可能与发送方的发送顺序不同。

举个例子:服务器传送流 A 和 B 到客户端。流 A 先启动,然后是流 B。在 QUIC 中,丢包只会影响该包所处的流。如果流 A 发生了一次丢包,而流 B 没有,流 B 将继续传输直到结束,而流 A 将会进行丢包重传过程。而在 HTTP/2 中这不可能发生。

下图展示了连通两个 QUIC 端点的单一连接中的黄色与蓝色的数据流。它们互相独立,所以可能乱序到达,但是每个流内的信息将按序可靠到达。

互联网协议 — QUIC 快速 UDP 互联网连接_流量控制_04

快速握手

与 TCP 的 3 次握手相比,QUIC 提供了 0-RTT 和 1-RTT 的握手,这减少了协商和建立新连接时所需的时间。其中更快的 0-RTT 仅在两个主机之间建立过连接且缓存了该连接的 Secret 时可以使用。

此外,QUIC 提供了提早传输更多数据的 “早期数据”(early data)特性,并且它的使用比 TCP 快速打开(TCP Fast Open)更加简便。同时,因为数据流概念的引入,客户端不用等待前一个连接结束,便可以与同一个主机建立另一个逻辑连接。

安全性

QUIC 使用 TLS 1.3 传输层安全协议,并且 QUIC 协议没有明文的版本,所以想要建立一个 QUIC 连接,就必须通过 TLS 1.3 来安全地建立一个加密连接。如上文所说,加密可以避免协议僵化等拦截和特殊处理。这也使 QUIC 具有了 Web 用户所期望的所有的 HTTPS 安全特性。QUIC 只在加密协议协商时会发送几个明文传送的初始握手报文。

连接迁移

TCP 连接基于四元组(源 IP、源端口、目的 IP、目的端口),切换网络时至少会有一个因素发生变化,导致连接发生变化。当连接发生变化时,如果还使用原来的 TCP 连接,则会导致连接失败,就得等原来的连接超时后重新建立连接,所以我们有时候发现切换到一个新网络时,即使新网络状况良好,但内容还是需要加载很久。如果实现得好,当检测到网络变化时立刻建立新的 TCP 连接,即使这样,建立新的连接还是需要几百毫秒的时间。

QUIC 的连接不受四元组的影响,当这四个元素发生变化时,原连接依然维持。那这是怎么做到的呢?道理很简单,QUIC 连接不以四元组作为标识,而是使用一个 64 位的随机数,这个随机数被称为 Connection ID,即使 IP 或者端口发生变化,只要 Connection ID 没有变化,那么连接依然可以维持。

互联网协议 — QUIC 快速 UDP 互联网连接_流量控制_05

解决队头阻塞

  • QUIC 的传输单元是 Packet,加密单元也是 Packet,整个加密、传输、解密都基于 Packet,这样就能避免 TLS 的队头阻塞问题;
  • QUIC 基于 UDP,UDP 的数据包在接收端没有处理顺序,即使中间丢失一个包,也不会阻塞整条连接,其他的资源会被正常处理。

互联网协议 — QUIC 快速 UDP 互联网连接_流量控制_06

HTTP/3 支撑

HTTP/3 协议使用了 QPACK 进行 HTTP 头部压缩,这和 HTTP/2 中使用 HPACK 压缩头部类似。HPACK 算法依赖于数据流的有序交付,由于 HTTP/3 的数据流之间可能乱序,所以该算法需要修改才能使用。QPACK 可被视作适用于 QUIC 版本的 HPACK。

QUIC 的工作原理

连接

QUIC 连接是两个 QUIC 端点之间的单次会话(conversation)过程。QUIC 建立连接时,加密算法的版本协商与传输层握手合并完成,以减小延迟。在连接上实际传输数据时需要建立并使用一个或多个数据流。

每个连接过程都有一组连接标识符,或称连接 ID,该 ID 用以识别该连接。每个端点各自选择连接 ID。每个端点选择对方使用的连接 ID。连接 ID 的基本功能是确保底层协议(UDP、IP 及其底层协议)的寻址变更不会使 QUIC 连接传输数据到错误的端点。

利用连接 ID 的优势,连接可以在 IP 地址和网络接口迁移的情况下得到保持,这是 TCP 永远也做不到的。举例来说,当用户的设备连接到一个 Wi-Fi 网络时,将进行中的下载从蜂窝网络连接转移到更快速的 Wi-Fi 连接。与此类似,当 Wi-Fi 连接不再可用时,将连接转移到蜂窝网络连接。

由于 QUIC 基于 UDP 建立,因此使用 16 比特的 UDP 端口号字段来区分传入的不同连接。

在初始的数据包建立连接之后,连接发起者会马上发一个加密的帧以开始安全层握手。安全层使用 TLS 1.3 协议。

数据流

数据流(Streams)在 QUIC 中提供了一个轻量级、有序的字节流的抽象化。QUIC 中有两种基本的数据流类型:

  1. 从发起者到对等端(Peer)的单向数据流。
  2. 双向均可发出数据的双向数据流。

连接端点的任意一方都可以建立这两种数据流,数据流之间可并行、交错地传输,并且可以被取消。通过 QUIC 发送数据需要建立一个或多个数据流。

  • 流量控制(Flow control):每个数据流都有独立的流量控制,端点可以通过此实现内存控制和反压(back pressure)。数据流的创建本身也有流量控制,连接双方可以声明最多愿意创建几个流 ID。
  • 流标识符:数据流通过一个无符号的 62 比特整数标识,也称流 ID。流 ID 的最低 2 位比特用于识别流的类型(单向或双向)和流的发起者。流 ID 的最低 1 位比特(0x1)用于识别流的发起者。客户端发起双数(最低位置 0)流,服务器发起单数(最低位置 1)流。第 2 个比特(0x2)识别单/双向流。单向流始终置 1,双向流则置 0。
  • 流并发:QUIC 允许任意数量的并发流。端点通过闲置最大流 ID 来控制并发活动的传入流数量。每个端点指定自己的最大流 ID 数,并只对对等端端点有效。
  • 收发数据:端点使用流来收发数据,这是流的最终用途。QUIC 数据流是有序的字节流抽象。但是,不同流之间是无序的。
  • 流优先度:如果正确设置了各流的优先度,流复用机制可以显著提升应用的效率。使用其他多路复用协议(如 HTTP/2)的经验表明,有效的优先度划分策略对效率具有显著的正面影响。QUIC 本身没有提供交换优先度信息的报文。接收优先度信息依赖于使用 QUIC 的应用层。应用层可以定义所有复合其语义的优先度方案。基于 QUIC 使用 HTTP/3 时,优先度信息在 HTTP 层完成。

用户态实现

在用户空间中实现一个传输层协议有助于协议的快速迭代,协议的演进更为容易,不需要客户端和服务器更新其操作系统内核才能部署新的版本。同时,QUIC 本身没有固有的东西阻碍未来在操作系统内核中实现和提供 QUIC 协议。

API

常规 TCP 与程序最成功的因素之一便是标准化的套接字(Socket)API。其 API 有着定义良好的功能,使用它能让你轻松地在各操作系统之间移植程序,因为 TCP 采用同样的方式运作。

但 QUIC 不是如此。QUIC 目前没有标准化的 API。使用 QUIC 时,你需要选择一个现有的库实现,并坚持使用它的 API。这在某种程度上把应用 “绑定” 到了单一的库上。换库意味着使用另外一套 API,这可能带来相当的工作量。

另外,由于 QUIC 一般在用户空间中实现,所以它不像现有的 TCP 和 UDP 套接字 API 那样能轻松扩展。使用 QUIC 意味着选择了套接字 API 之外的另一套 API。