论文阅读笔记-[SIGCOMM_17] The QUIC Transport Protocol- Design and Internet-Scale Deployment

摘要

QUIC（Quick UDP Internet Connections），一种加密的，多路复用的，并且低延时的传输层协议，被设计用于提高 HTTPS 流量的传输效率以及快速的部署和持续的传输机制的升级。它已经被谷歌部署在全球的上千台服务器上了，并用于了 Chrome 浏览器和 YouTube。

1 介绍

QUIC 替代了大多数传统的 HTTPS 协议栈：HTTP/2, TLS, TCP。QUIC 以 UDP 为底层，在用户空间建设 QUIC 方便了它作为多种应用的一部分的部署，也能够以应用层的速度进行快速迭代更新。UDP 的使用让 QUIC 数据包能够经过中间盒。QUIC 是加密传输：包需要认证和加密，防止中间盒的修改和限制协议的僵化（中间盒子协议升级过慢）。QUIC 能够减小握手延迟。QUIC 消除了队列头的阻塞延迟，通过使用一种轻量的数据结构，流，它能在一条连接中进行多路复用，所以一个包的丢失，只会使含那个包的流阻塞。

QUIC 已经被广泛部署了，超过 30% 的 Google 的外出流量，以及 7% 左右的全球流量。

本文介绍的是 IETF 标准化之前的 QUIC 的设计和部署，细节可能有所改变，但是认为核心设计和性能表现不变。

本文将经常插入对 QUIC 协议的讨论，它在 HTTPS 协议栈中的使用情况，和它的实现。

2 动机？为什么是 QUIC

对延迟敏感的 web 服务的增加，以及使用 web 作为应用的平台对减小 web 延迟提出了更高的要求。web 延迟影响了用户体验，尾延迟也阻碍了 web 平台的扩展。由于 HTTPS 的使用，因特网也在由不加密转变到加密传输，这也增加了延迟。减少延迟的努力经常会受到下列 TLS/TCP 生态的限制。

协议的鸿沟

大量中间盒子升级换代过慢，支持和部署太慢。协议僵化问题。

实现的鸿沟

对 TCP 协议实现的修改涉及到 OS 内核的修改，这需要大量的时间。

握手延迟

TCP 连接花费至少一轮延迟，TLS 又增加两轮。

队列头阻塞延迟

为了减少握手开销，HTTP 协议建议减少客户端和服务端之间的 TCP 连接数。然而丢失的 TCP 段会被重新传输，导致传输数据阻塞。

对传输层修改的部署，依赖于客户端、服务端和中间盒子的修改，需要三者的协调合作，还需要网络管理员的参与。而 QUIC 基于 UDP，避免了这些依赖，将传输层部署的控制转移到直接从中受益的应用程序中。

3 QUIC 设计和实现

QUIC 要满足若干设计目标：易部署，安全，减少握手开销和队列阻塞延迟。

• 使用独立的包编号来避免重传的模糊性
• explicit signaling in ACKs for accurate RTT measurements
• Connection ID 来标识连接，使其能够在 IP 地址的改变中实现迁移
• 流量控制，每个流都有流量控制

3.1 连接建立

客户端会缓存关于对端的信息。后续与同一个对端的连接，客户端可以直接发送加密数据，不需要等服务端的回应（0-RTT）。

初始握手

一开始，客户端没有关于服务端的信息，它会先发送 inchoate client hello (CHLO) 给服务端，来获得 reject (REJ) 消息。这个 REJ 消息包含服务端配置：

• 服务端的长期 Diffie-Hellman 公共值
• 认证服务端的证书链
• 用来自证书链末尾的私钥对服务端配置的签名
• 源地址令牌：经认证的加密块，其中包含客户端公开可见的 IP 地址，和服务端时间戳。客户端在后续的握手中会发送这个令牌，表示对这个 IP 地址的拥有。

一旦客户端收到了服务端的配置信息，就会通过证书链和签名对其进行认证。然后发送一个 complete CHLO，包含客户端的临时的 Diffie-Hellman 公共值。

最终（和重复）的握手

所有连接的密钥都使用Diffie-Hellman建立。在发送完整的CHLO后，客户端具有连接的初始密钥，因为它可以从服务器的长期Diffie-Hellman公共值和自己的临时Diffie-Hellman私钥计算共享值。此时，客户端可以自由地开始向服务器发送应用程序数据。实际上，如果它希望实现零往返延迟的数据传输，则必须在等待服务器回复之前使用初始密钥加密开始发送数据。

如果握手成功，服务器将返回一个服务器hello（SHLO）消息。该消息使用初始密钥进行加密，并包含服务器的临时Diffie-Hellman公共值。有了对等方的临时公共值，双方都可以计算连接的最终或前向安全密钥。在发送SHLO消息后，服务器立即切换到使用前向安全密钥加密的数据包。在接收到SHLO消息后，客户端切换到使用前向安全密钥加密的数据包。

QUIC的密码学提供了两个级别的机密性：初始客户端数据使用初始密钥进行加密，后续客户端数据和所有服务器数据使用前向安全密钥进行加密。初始密钥提供了类似于TLS会话恢复和会话票据[60]的保护。前向安全密钥是临时的，并提供更强的保护。

客户端缓存服务器配置和源地址令牌，在再次连接到同一源时，使用它们来使用完整的CHLO启动连接。如图4所示，客户端现在可以将初始密钥加密的数据发送给服务器，而无需等待服务器的响应。

最终，源地址令牌或服务器配置可能过期，或者服务器可能更改证书，导致握手失败，即使客户端发送了完整的CHLO。在这种情况下，服务器会回复一个REJ消息，就像服务器收到了一个不完整的CHLO一样，然后握手继续进行。关于QUIC握手的更多细节可以在[43]中找到。

版本协商

QUIC客户端和服务器在连接建立过程中进行版本协商，以避免不必要的延迟。QUIC客户端在连接的第一个数据包中提议使用的版本，并使用所提议的版本编码其余的握手过程。如果服务器不支持客户端选择的版本，它将通过向客户端发送一个版本协商数据包，其中包含服务器支持的所有版本，引发一个往返延迟，来强制进行版本协商。该机制在服务器支持客户端乐观选择的版本时消除了往返延迟，并激励服务器在部署更新版本时不落后于客户端。为了防止降级攻击，客户端请求的初始版本和服务器支持的版本列表都在客户端和服务器在生成最终密钥时的密钥派生函数中使用。

3.2 流多路复用

一个连接里有多个流，一个丢失的 UDP 包只影响对应的流，其他流不影响。

一个流最大可传输 $2^{64}$ 字节的消息。流由 stream ID 标识，奇数 ID 由客户端创建，偶数 ID 由服务端创建。

一个 QUIC 包可携带多个流的数据。

QUIC 端点的数据发送速率总会被限制。

3.3 身份验证和加密

除了少数早期的握手数据包和重置数据包外，QUIC数据包是完全认证和大部分加密的。

包头不加密。

在未加密握手数据包中发送的任何信息（例如在版本协商数据包中）都包含在最终连接密钥的生成中。

3.4 丢失恢复

TCP的序列号确保可靠性并表示接收端接收字节的顺序。这种混淆导致了“重传不确定性”问题，因为重新传输的TCP段与原始数据包具有相同的序列号。TCP ACK的接收方无法确定ACK是为原始传输还是为重传而发送的，且常常通过昂贵的超时来检测到重传段的丢失。

每个 QUIC 包携带一个全新的包编号，那些重传的数据包也是。流帧中的流偏移用于交付排序，将TCP混淆的两个功能分离。

QUIC的ACK明确地编码了接收数据包和发送ACK之间的延迟。

3.5 流量控制

限制一个流能消耗的缓存。采用连接层级的流量控制和流层级的流量控制。

3.6 拥塞控制

不依赖特定的拥塞控制算法，而采用可插拔的接口来允许实现。

3.7 NAT 重绑定和连接迁移

QUIC 连接由 64-bit 的 Connection ID 标识，所以客户端 IP 和端口的改变不影响连接，NAT 重绑定不是个问题。但由客户端发起的连接迁移是个还在进行中的工作，目前部署有限。

3.8 针对 HTTPS 的 QUIC 发现

客户端一开始不知道服务端用不用 QUIC，服务端返回的响应包中会告诉客户端可以尝试使用 QUIC。在后续的对同一服务端的 HTTP 请求中，客户端会让 QUIC 与 TLS/TCP 连接竞争，谁先建立连接就用谁，但会以延迟 TLS/TCP 最多 300 ms 的方式更偏好 QUIC。

3.9 开源实现

Chromium QUIC Implementation. https://cs.chromium.org/chromium/src/net/quic/

4 实验框架

在 Chrome 上实验。Chrome 的实验框架伪随机地分配客户端来实验，并报告大量的测量指标，例如 HTTP 错误率，传输握手延迟等。能够控制偶尔出现的错误产生的影响。Google 提供了很好很完整的实验环境。

5 互联网规模的部署

5.1 部署之路

Chrome 在 2013 年 6 月加入了对 QUIC 的支持。在 2017 年 6 月，Chrome 和安卓 YouTube APP 的几乎所有用户都打开了 QUIC 服务。这个过程并非一帆风顺的，下面介绍两个影响重大的事件。

0-RTT 请求中的未加密数据

2015 年 12 月，发现了握手的实现中的一个漏洞，这个漏洞会导致 0-RTT 请求未被加密地发送，尽管这个情况及其罕见。于是关闭了 QUIC 服务，直至漏洞修复。

移动端 QUIC 的增长

搜索应用，YouTube 应用

5.2 监测指标：搜索延迟

有很多指标，用搜索延迟作为例子。搜索延迟的定义是：用户发送搜索内容到用户收到所有搜索内容之间的时间间隔。

上图是用 QUIC 和用 TLS/TCP 的用户的搜索延迟的对比随时间的变化图。

事件 1 及其后面 5 个月是由于服务基础设施的变化和一个客户端配置的 bug。

事件 2，QUIC 恢复使用，客户端配置 bug 被修复，搜索性能提升。

事件 3，是由于 UDP 代理在 restricted edge locations (RELs) 的部署。

6 QUIC 性能表现

6.1 实验设置

性能表现数据来自部署在各种客户端上的 QUIC 实验，使用客户端的框架来进行随机化实验。用户要么在 QUIC 实验组，要么在 TLS/TCP 对照组

6.2 传输和应用指标

随着 RTT 的增加，TCP/TLS 的平均握手时延几乎线性增加，而 QUIC 几乎保持不变，因为有 0-RTT 握手存在，占了大约 88%，其余可能是 1-RTT 的。QUIC 的握手时延有微小的增加是由于 0-RTT 握手中有的是失败的。比 TLS/TCP 少花 2、3 个 RTT。

网络是端到端应用测量的一个组成部分。例如，握手时延为搜索时延和视频时延的贡献低于 20%。几乎完全消除握手时延也只会消除总时延的一小部分。然而，端到端的指标的一个小改变也影响重大，因为这个影响与用户体验和收益直接挂钩。亚马逊估计每增加 100ms 时延，收益减少 1%，谷歌、雅虎也做了相关估计。

应用程序指标对网络变化的敏感性依赖于应用的成熟程度。要让 QUIC 对谷歌搜索和 YouTube 产生较大影响比较困难。选择这两个应用的两个原因：提升这些高度优化的应用的性能有直接的经济效益；它们代表各种传输的用途案例：搜索代表低负载、时延敏感的应用，YouTube 代表高负载、带宽敏感的应用。

6.3 搜索时延

平均来说，一个人的搜索会返回 100 KB（电脑端）的结果或 40 KB（移动端）的结果。作为一种测量指标，搜索时延代表了小的，时延敏感的，动态生成的负载。

QUIC 大部分的时延的降低是来自 0-RTT 的握手，这种降低将随着 RTT 的增加而变得更加明显。

移动端的时延降低的效果不如电脑端的，主要是因为移动端在移动，其客户端的 IP 地址可能会变，以及它可能会访问到不同的数据中心，导致缓存到客户端和服务端的连接信息失效。所以导致移动端的 0-RTT 的比例只有 68%，而电脑端有 88%。

在低延时 1%，5% 分位数时，QUIC 时延反而不如 TCP，是由于 QUIC 的额外的小开销导致的。

6.4 视频时延

视频延迟是指用户点击播放到视频开始播放之间的时间。

QUIC 对移动端和桌面端都降低了视频播放延迟。

移动端的 QUIC 效果同样不如电脑端，0-RTT 比例只有 65%，另外还因为 YouTube 会隐藏握手延迟的开销，通过用户在浏览视频时就建立连接。

6.5 视频重缓冲率

视频重缓冲率是视频播放过程中暂停的时间占视频总播放时间的比例：Rebuffer Rate = (Rebuffer Time) / (Rebuffer Time + Video Play Time)。

重缓冲率对握手延迟不敏感，而丢失恢复延迟对其影响较大，也受总的吞吐率的影响。

丢失恢复延迟

QUIC 的重缓冲率的增长慢于 TCP，表明前者对更多的丢失具有更高的适应力

连接吞吐量

连接的吞吐量受拥塞窗口和接收窗口限制。

对于非零的重缓冲率，QUIC 提升了视频的质量。

当拥塞、丢包、RTT 更高时，QUIC 带来的好处更大。

6.6 不同地区的性能表现

不同地区的 RTT 不一样，总的来说，RTT 越大，QUIC 带来的性能提升越大。

6.7 服务端 CPU 占用率

一开始 QUIC 的 CPU 占用率是 TLS/TCP 的大约 3.5 倍。

主要是三个方面的原因：加密，发送和接收 UDP 包，维护内部 QUIC 状态。

经过优化后，现在 QUIC 的 CPU 占用率是 TLS/TCP 的 2 倍左右。

6.8 性能限制

提前预热的连接

有的应用会提前建立连接，例如 YouTube，但一般浏览器不会。提前连接，QUIC 的 0-RTT 握手收益不大。

高带宽、低延迟、低丢包网络

在这种网络环境下，QUIC 帮助不大，甚至有负作用，可能表现会不如 TCP。

移动设备

移动设备的收益往往比桌面端的收益低一些。主要是由于移动设备的环境的变化导致的。移动设备的 CPU 性能也可能是个瓶颈而不是网络带宽。

7 实验和经验

7.1 包大小的考虑

测试 UDP 负载大小，从 1200 字节到 1500 字节，5 字节增量。1450 字节后，不可到达性快速增加，是因为包总长超过了以太网 MTU 1500 字节。基于这个数据，选择了 1350 字节作为 QUIC 的默认负载大小。

7.2 UDP 阻断和扼杀

95.3% 能成功使用 QUIC，4.4% 不能使用 QUIC，0.3% 对 QUIC 或 UDP 流量进行了速率限制。

7.3 前向纠错

使用基于异或的前向纠错方法，发现收益不大。于是移除了。

7.4 用户态的开发

不受内核态的内存限制等。发现问题，快速迭代

7.5 用中间盒子进行实验

8 相关工作

9 结论

论文评审

Overall merit

Accept

Reviewer expertise

Some familiarity

Paper summary

本文介绍了 QUIC 传输协议的使用经验，该协议是一种加密、多路复用和低延迟的传输协议，旨在改善 HTTPS 流量的传输性能，并促进传输机制的快速部署和持续演进。本文描述了作者开发新传输协议的动机，指导设计的原则，进行迭代实验的全球化过程，各种服务的性能改进，以及在全球范围内部署 QUIC 的经验，还分享了从部署中学到的有关传输设计和互联网生态系统的经验教训。

Strengths

• 对 QUIC 的原理讲解和后续做的相关实验的介绍非常详细。

• 对 QUIC 的设计采用快速迭代的方式，发现问题后能及时停止应用，并快速更新修复。

Weaknesses

• 图 9 将 y 轴数据进行了标准化，没有展示原始数据值。
• 比较回避 QUIC 的缺点，例如其可能面临的安全性和部署方面的问题。

Measurement details

• 测量手段
  • 利用 Chrome 强大的实验和分析框架，在各种客户端上部署 QUIC 实验，用这些客户端的框架进行随机化的实验。用户分为 QUIC 实验组 $QUIC_g$ 和 TLS/TCP 对照组 $TCP_g$。
• 结果
  • 平均来说，实验组的握手延迟、搜索延迟、视频播放延迟、视频重缓冲率均优于对照组，并且随着网络质量的降低、平均 RTT 的增加等，前者的优势更加明显。但是 QUIC 的 CPU 性能开销更大，在网络质量很好时，QUIC 的 CPU 开销可能会成为性能瓶颈，导致其表现不如 TLS/TCP。另外在桌面端的 QUIC 的表现往往比其在移动端的表现更好。

Comments for authors

这篇文章写得挺不错，比较清晰地介绍了 QUIC 这一比较新的协议，并且通过大量的实验测试和数据分析，说明了其对现有的 TLS/TCP 协议的优势。通过阅读本文，我学习到了这一富有前景的协议的原理，以及测量类文章的基本脉络。

QUIC 最初作为一个实验设计和推出，现在已经成为了服务基础设施的核心部分，并且持续的实验和开发还在进行。文章描述了作者开发新传输协议的动机，指导设计的原则，进行迭代实验的全球化过程，各种服务的性能改进，以及在全球范围内部署 QUIC 的经验，还分享了从部署中学到的有关传输设计和互联网生态系统的经验教训。

文章中对 QUIC 和 TLS/TCP 协议的对比实验也比较有说服力，从搜索延迟、视频播放延迟、视频重缓冲率等方面，进行了对比，在平均情况下，QUIC 的表现更好，随着网络质量的恶化，QUIC 的优势愈发明显。但是 QUIC 也不是完美的，它的性能开销更高，在网络质量很好的情况下，这有可能成为它的一个弱点。另外在移动端，典型应用可能对握手连接做了优化，导致 QUIC 的优势没有其在电脑端那么明显。

最后我也想问作者一些问题：

• 文章中的图表中的数据大多是经过变换后的，是否应该详细说明对原始数据的处理过程，并适当地展示部分原始数据。

• 6.7 节中提到的发现 QUIC 的 CPU 开销很大时，具体是怎么做的优化，这一点没有在文中详细说明。

• 尽管 QUIC 采用了很多加密的手段，但是肯定还存在或存在过安全性的问题，文中缺少对这方面的介绍。
• 经过加密的 QUIC 包可能会导致网络管理者无法对 QUIC 包进行流量分析，是否存在相关的问题。
• 目前 QUIC 的发展和部署情况是什么样的？