互联网协议 — QUIC 快速 UDP 互联网连接

转载

云物互联 2022-03-22 10:21:38 博主文章分类：SDN/NFV 网络技术专栏

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 中有两种基本的数据流类型：

从发起者到对等端（Peer）的单向数据流。
双向均可发出数据的双向数据流。

连接端点的任意一方都可以建立这两种数据流，数据流之间可并行、交错地传输，并且可以被取消。通过 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 层完成。