Skip to content
←

필사 모드: 为什么 QUIC 在快速互联网上反而更慢 — 接收端 CPU 与尚未到来的内核 QUIC

中文
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

引言 — 首先，QUIC 究竟在哪里赢了

关于 QUIC 的故事，通常以「比 TCP 快」开场，以「所以打开 HTTP/3 吧」收尾。本文要讲的是它的另一面 — QUIC 在什么条件下会输，以及为什么。但要做到公允，得先确认它赢在哪里。而且这不是印象，是有实测数字支撑的。

Google 发表于 SIGCOMM 2017 的The QUIC Transport Protocol: Design and Internet-Scale Deployment，用表格给出了 QUIC 实验组与 TLS/TCP 对照组在同等规模下的对比结果。把论文 Table 1 和 Table 2 的平均值搬过来是这样的。

搜索延迟(Search Latency)下降率 — 平均
  桌面端  8.0%      移动端  3.6%

视频延迟(Video Latency)下降率 — 平均
  桌面端  8.0%      移动端  5.3%

视频卡顿率(Video Rebuffer Rate)下降率 — 平均
  桌面端 18.0%      移动端 15.3%

论文也指出了这个收益从何而来。QUIC 握手中约 88% 以 0-RTT 完成，因此握手延迟几乎不受 RTT 影响。TCP/TLS 的平均握手延迟随 RTT 线性上升，QUIC 却几乎持平。在此之上，还叠加了丢包恢复方面的改进，用论文的说法，整体的抗丢包能力提高了，短连接的延迟也降低了。

有三点提示值得一并记住。第一，这是Google 自己测量自己流量得到的数值(厂商自测)。被测群体是使用 Chrome 和 YouTube 的 Google 用户，服务器也是 Google 的服务器 — 不是你的流量组合。第二，这是 IETF QUIC 的前身 gQUIC，而不是 IETF QUIC 本身。第三，论文自己也承认了这份收益的局限 — 握手延迟在搜索延迟和视频延迟中所占的比重远不到 20%，所以即便把握手延迟彻底消除，整体延迟下降也只是一个很小的比例。

而在同一张 Table 1 里，有一格很少被人引用。移动端搜索的第 1 百分位和第 5 百分位下降率分别是 -0.6% 和 -0.3%。负数意味着 QUIC 反而更慢。也就是说，对已经处在最快条件下的移动端用户来说，即便在 Google 自己的测量中，QUIC 也是略微亏的。收益都集中在尾部 — 桌面端搜索的第 99 百分位，下降率达到 16.7%。QUIC 是一个把平均值改善一点、把最差情况大幅改善的协议。

部署程度也已经不再是实验性质。根据 W3Techs 2026 年 7 月的统计，HTTP/3 已被 39.9% 的网站使用(按 W3Techs 自身调查样本计)。

然而链路一变快，故事就反转了

问题在于，这些测量是在什么条件下做的。WWW 2024 的论文梳理了既有的 QUIC 测量研究后总结道 — 这些结果性能提升与(某些情况下的)下降混杂在一起，其中大多数集中在低吞吐量(low-throughput)的场景。那链路变快之后会怎样呢？

密歇根大学等机构的研究者在QUIC is not Quick Enough over Fast Internet(Zhang 等，WWW 2024)中正面挖掘了这个问题，结论正如标题所说。照搬论文摘要里的原话：在快速互联网上，UDP+QUIC+HTTP/3 技术栈相较于 TCP+TLS+HTTP/2，会遭遇最高达 45.2% 的数据传输速率下降，而且这一差距会随底层带宽增大而进一步拉大。

数字必须和条件精确地绑在一起看。

  • 用命令行客户端(cURL、quic_client)比较时，带宽较低(大致低于 600 Mbps)时 QUIC 与 HTTP/2 性能相近。超过这个界限，QUIC 就开始落后，差距最大可达 15.7%。
  • 在浏览器中，差距更大。以 Chrome 为例，带宽超过约 500 Mbps 时 QUIC 就开始落后，一旦达到 1 Gbps 会慢 45.2%。
  • 客户端越弱，差距就越大。

论文 Table 1 中关于下载 1 GB 文件的预备实验很好地展示了这一点(10 次平均)。

                       下载时间(s)         CPU 使用率(%)
测试环境              HTTP/2   HTTP/3        HTTP/2   HTTP/3
桌面端，以太网          9.32    18.60(+99%)    77.5     96.9
Pixel 5, low-band 5G   37.11    78.65(+112%)  121.55   161.77
Pixel 5, mmWave 5G     30.10    63.20(+110%)  128.43   165.20

需要注意 — 桌面端的 CPU 数值是在浏览器的网络服务中测得的，而智能手机的数值是整个浏览器进程的。超过 100% 意味着用到了多核。也就是说，这两行不能直接放在一起比较。

影响并不局限于批量传输。DASH 视频传输出现了最高9.8% 的码率下降，100 个代表性网站的平均页面加载时间延长了 3.0%(不过尾部差距超过 50%)。论文在这里的观察很敏锐 — 这种下降在 4G 上是隐藏的，到了 5G 才显现出来。链路慢的时候，瓶颈就是链路本身，所以 QUIC 的成本根本看不出来。

揪出真凶 — 把嫌疑对象逐一排除

从这里开始才是这篇论文真正的贡献。研究者通过对照实验把有嫌疑的对象逐一排除。

是 UDP 本身慢吗? 不是。在相同的网络设置下用 iPerf 重新测量，UDP 和 TCP 都能把 1 Gbps 的链路跑满 — UDP 958 Mbps，TCP 944 Mbps。UDP 反而略高一点。内核的 UDP 数据路径是无辜的。

是服务器软件的锅吗? 不是。换成 Nginx-quic 之后，HTTP/2 基本不变，QUIC 反而慢了 18%。

HTTP 语法? 加密? 参数调优? 客户端操作系统? 全都不是。HTTP/3 在语法结构上和 HTTP/2 几乎一样，两套技术栈用的都是同一个 TLS_AES_128_GCM_SHA256 密码套件，pacing 与 PMTU 调优都没有带来明显改善，在 macOS 和 Windows 接收端上也得到了同样的结果。

剩下的只有接收端处理。两个观察指向了这里。第一，使用 QUIC 的客户端收到的数据包数量，远多于 HTTP/2 时的情况。第二，QUIC 在高速接收时，数据包与对应 ACK 之间的延迟很大。测量平均数据包 RTT 时，HTTP/2 是 1.9ms，而 QUIC 飙升到 16.2ms。两台机器之间的 ping RTT 只有 0.23ms，所以延迟的大部分并非来自线路，而是来自端点的数据包处理。

论文明确把这一点列为自己的贡献 — 用户态实现通常会拖累性能，这早已是常识，也已经有过针对发送端的优化努力，但指出接收端才是更有力的瓶颈，他们说这是自己的首创。理由也给出来了：服务器通常比桌面机、笔记本、手机更强。当我们习惯性地说「QUIC 吃服务器 CPU」时，真正受伤的其实是用户手里的设备。

为什么接收端代价高 — GRO 与用户态 ACK

用 perf 对内核和 Chromium 做剖析后，浮现出两个根本原因。

第一，内核对数据包动手的次数太多了。 接收一次 1 GB 文件的过程中，netif_receive_skb 的调用次数在 QUIC 下是231K 次，HTTP/2 下是15K 次 — 相差 15 倍。do_syscall_64 也从 4K 拉大到 17K。原因很简单 — TCP 靠 GRO(Generic Receive Offload)把多个分段合并后再往上传递，而论文调查的 QUIC 实现里，没有一个用到了 UDP GRO。

论文的 Table 3 把这一点钉死了。

配置                  发送包数    接收包数    时间(s)
QUIC (offload on)      743K       743K      18.60
QUIC (offload off)     744K       744K      18.82
HTTP/2 (offload on)     19K        53K       9.36
HTTP/2 (offload off)   744K       744K      10.84

读法：HTTP/2 打开 offload 后，内核要动手的数据包从 744K 降到 53K，时间也从 10.84 秒降到 9.36 秒。QUIC 无论开关都是 743K/744K，几乎不变，时间也是 18.60 秒对 18.82 秒，没有实质差别。QUIC 完全没有从 GRO/GSO 里得到任何好处。

那为什么不直接打开呢？论文给出了三个结构性原因。TCP 是字节流模型，可以自由地对负载重新分包，但 UDP 的 offload 逻辑必须保留数据包边界。所以现有的 UDP GSO/GRO 只能对长度相同的一串 UDP 包做 offload。而 QUIC 天生就是多路复用的，不同流的帧大小各不相同，并且是在加密之后才做多路复用的。长度参差不齐的一串数据报，现有的 GSO/GRO 处理不了。此外，把 UDP 数据报不加区分地打包成一个突发一次性发出去，会引发拥塞丢包和公平性问题，加上 QUIC 的变种繁多，把 offload 逻辑塞进 NIC 硬件里也很复杂。

第二，ACK 是在用户态生成的。 Chromium 网络栈的耗时拆解见 Table 4。

Chromium 网络栈阶段                QUIC(8.5s)   HTTP/2(4.1s)
从 socket 读取 UDP/TCP 数据包        0.248s        0.037s
从 UDP/TCP 数据包中提取负载          0.310s        0.084s
解密 QUIC/TLS 加密数据包             0.660s        0.814s
解析已解密的 QUIC/HTTP2 帧           3.468s        3.182s
生成 QUIC 响应(ACK 等)              2.972s          --
其他                                0.859s        0.001s

从这张表里要读出两件事。

第一，光是生成 ACK 就整整花掉 2.972 秒。HTTP/2 这一列压根没有这一项 — TCP 的 ACK 由内核生成，加上延迟 ACK(delayed ACK)和接收 offload 之类的优化，出现得更少、也更高效。QUIC 把这件事放在用户态做，逐包处理，还没有延迟 ACK 之类的优化。整个下载耗时 20.6 秒中，QuicChromiumPacketReader 占了 8.7 秒，其中 3.0 秒是响应生成。

意外的地方 — 加密不是真凶

再看一眼上面那张表。在解密阶段，QUIC 是 0.660 秒，HTTP/2 是 0.814 秒。QUIC 反而更快。

「QUIC 慢是因为加密」这个常见的说法，至少在这次测量里并不成立。QUIC 用的是 TLS 1.3，HTTP/2 用的是 TLS 1.2，密码套件相同；研究者也用其他密码套件做了基准测试，发现对性能没有明显影响。成本不在密码运算，而在数据包被动手的次数太多、太频繁，还要不断跨越用户态与内核态的边界。

这个误解流传得相当广，值得专门指出来。在考虑内核旁路或硬件加密加速之前，得先做剖析，确认你的瓶颈是不是真的是 AES。

不过对称加密也不是永远无罪 — 后面会看到，一旦发送路径被充分优化，加密就会重新浮上来。这是个先后顺序的问题。

发送端的故事 — Google 是如何把成本砍到 2 倍的

如果说接收端是新发现，那发送端就是一片老战场。Google 的 Ian Swett 在 SIGCOMM EPIQ 2020 上发表的QUIC CPU Performance幻灯片，就是这场战斗的实测记录。副标题很坦诚 — 「HTTP/3 能做到和 HTTP/2、HTTP/1.1 一样高效吗?」

出发点：截至 2017 年 1 月，QUIC 的 CPU 开销是 HTTPS 1.1 的 2 倍。最初的实现是 3.5 倍，经过一些显而易见的修正(去掉对昂贵函数的重复调用、去掉数据路径上的内存分配、把拷贝降到最少、使用针对该工作负载定制的数据结构)之后，降到了 2 倍。

瓶颈的位置也很清楚。据幻灯片所说，UDP 发送占了这个工作负载 CPU 的 25%，在部分环境和基准测试中甚至超过 50%。在 Linux 上，UDP 的 sendmsg 相比 TCP，每字节的 cycle 数最高可达 3.5 倍。

以下是之后应用的各项优化及其实测效果(均为 Google 自己的测量)。

UDP GSO                        比 TCP GSO 快 7%
UDP GSO + 硬件 offload          再快 2-3 倍
  累计加速                      理想情况下约 10 倍，通常 5 倍
  => 最差情况 50% 的 CPU 降到 5%，整体提升 2 倍
UDP GRO (补丁)                  接收端 CPU 改善 35%
每包 1 个 STREAM 帧的优化        单独节省 5%
减少发送 ACK 的数量              节省 25%
  - 在 Quicly 基准测试中，是追平 TCP 的关键一步
FDO + ThinLTO                   节省 15% CPU

这里有两点值得注意。

第一，光是减少 ACK 就带来了 25% 的节省，幻灯片写道，这在 Quicly 基准测试中是追平 TCP 的关键一步。这和 WWW 2024 论文在接收端发现的 ACK 瓶颈，指向的正是同一个地方。不管是发送方还是接收方，QUIC 的 ACK 都很贵。

第二，把发送路径做得足够快之后，对称加密会占到 CPU 的约 30%。而且 IETF QUIC 因为头部保护(header protection)的缘故需要两遍加密，用幻灯片的说法，小规模的密码运算远比批量加密昂贵。这是为了隐私而支付 CPU 成本的一种设计取舍。

幻灯片的展望也是有条件的 — 它说如果有对称加密的 offload，QUIC 应该能变得和 kTLS 一样快，但同时也留下了一个开放问题：「QUIC offload 真的值得吗？TSO 的效果参差不齐，尤其是在低带宽下。」考虑到这是 2020 年的发表，也得带着这个时间背景去读。

2026 年的尝试 — 把 QUIC 搬进内核

到了这一步，一个自然的问题就冒出来了：如果问题就是在用户态一个一个地处理数据包，那直接搬进内核不就行了？

这正是眼下正在发生的事。Xin Long 正在提交一系列将 QUIC 实现进 Linux 内核的补丁。LWN 在 2025 年 7 月 22 日以QUIC for the kernel做了梳理，之后又以net: introduce QUIC infrastructure and core subcomponents发布了 v2 — 15 个补丁，新增 9,081 行代码，相当于计划中五部曲的第 1-2 部，并标记为 EXPERIMENTAL。

具体设计整理在 lxin/quic 仓库中。核心思路是只把握手留在用户态，其余全部搬进内核。

  • 用户态：只处理和生成原始的 TLS 握手消息。由 GnuTLS 这类 TLS 库负责，通过 sendmsg/recvmsg 与内核交换消息，密码信息则通过 cmsg 传递。
  • 内核：QUIC 协议的其余全部。不使用 ULP 层，而是创建 IPPROTO_QUIC 类型的 socket(方式类似 IPPROTO_MPTCP)，运行在 UDP 隧道之上。
  • 内核消费者：通过既有的 net/handshake netlink，由内核向用户态请求握手。

动机不只是性能。LWN 指出了两点。一个是让硬件协议 offload 成为可能 — 前面提到的 GSO/GRO 与加密 offload 的故事在这里衔接上了。另一个是内核消费者。目前已经有一个开放的 pull request，要为 Samba 的服务端和客户端加入 QUIC 支持，也有人希望把这项支持加进内核内的 SMB 和 NFS 文件系统。浏览器只需要链接一个用户态的 QUIC 库就够了，但内核态的 NFS 客户端做不到这一点。

搬进内核就会更快吗 — 诚实地解读自测基准

那么，它实际上变快了吗？lxin/quic 仓库的 README 公开了在 100G 物理网卡上测得的 iperf 数据。这是项目自己的测量，是合成基准测试，不是真实工作负载。

先看内核 QUIC 对比 kTLS。

UNIT        size:1024      size:4096      size:16384     size:65536
Gbits/sec   QUIC | kTLS    QUIC | kTLS    QUIC | kTLS    QUIC | kTLS
--------------------------------------------------------------------
mtu:1500    1.67 | 2.16    3.04 | 5.04    3.49 | 7.84    3.83 | 7.95
no GSO           | 1.73         | 3.12         | 4.05         | 4.28
--------------------------------------------------------------------
mtu:9000    2.17 | 2.41    5.47 | 6.19    6.45 | 8.66    7.48 | 8.90
no GSO           | 2.30         | 5.69         | 8.66         | 8.82

表面上看很惨。在 MTU 1500、64KB 消息下，内核 QUIC 是 3.83 Gbps，kTLS 是 7.95 Gbps — 差了两倍还多。就算搬进了内核，还是输。

但请看 no GSO 这一行。关掉 TCP GSO 的 kTLS，在同样条件下会跌到 4.28 Gbps — 和内核 QUIC 的 3.83 几乎持平。MTU 9000 时更明显 — kTLS 从 8.90 关掉 GSO 也只降到 8.82，跌得不多，而 QUIC 的 7.48 已经很接近了。

也就是说，内核 QUIC 和 kTLS 之间的差距，大部分来自 GSO。 README 也明确写了这一点 — 在 MTU 1500 和大消息的情况下，TCP GSO 对 TCP 和 kTLS 的性能贡献很大，关掉 TCP GSO 之后剩下的那点小差距，原因有三个。

  • QUIC 在发送路径上多了一次拷贝。
  • QUIC 为了头部保护多了一次加密。
  • QUIC 的 stream DATA 头部更长。

关掉加密、把 QUIC 和 TCP 放在一起对比的表格，讲的是同一个故事。

UNIT        size:1024      size:4096      size:16384     size:65536
Gbits/sec   QUIC | TCP     QUIC | TCP     QUIC | TCP     QUIC | TCP
--------------------------------------------------------------------
mtu:1500    2.17 | 2.49    3.59 | 8.36    6.09 | 15.1    6.92 | 16.2
no GSO           | 2.50         | 4.12         | 4.86         | 5.04
--------------------------------------------------------------------
mtu:9000    2.47 | 2.54    7.66 | 7.97    14.7 | 20.3    19.1 | 31.3
no GSO           | 2.51         | 8.34         | 18.3         | 22.3

在 MTU 1500、64KB 下，TCP 以 16.2 Gbps 一骑绝尘，但关掉 GSO 就跌到 5.04。同一格的 QUIC 是 6.92 — 没有 GSO 的 TCP，反而比内核 QUIC 更慢。

从这里该得出的结论不是「内核就是答案」。而是offload 才是答案，进入内核只是获得使用 offload 资格的第一步。TCP 之所以快，不是因为它在内核里，而是因为它背靠着 30 年积累下来的 offload 生态(TSO/GSO/GRO、网卡硬件支持)。把 QUIC 搬进内核，是排队加入这个生态的第一步，而不是终点。

但它还没进主线

有必要先把最重要的事实说清楚。LWN 在 2025 年 7 月的文章中写道，「就算最乐观，恐怕也要到 2026 年的某个时间点之后，才有可能在主线里看到它」。

我在今天(2026 年 7 月 16 日)做了直接确认。只要看内核代码树里有没有 net/quic 目录就行了。

# 主线 (torvalds/linux)
curl -s -o /dev/null -w "%{http_code}\n" \
  "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/quic"
# => 404

# net-next (下一个合并窗口的目标分支)
curl -s -o /dev/null -w "%{http_code}\n" \
  "https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/net/quic"
# => 404

# 对照组: 已经合并的 net/mptcp
curl -s -o /dev/null -w "%{http_code}\n" \
  "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/mptcp"
# => 200

主线里没有，net-next 里也没有。作为对照组的 net/mptcp 返回了 200，说明也不是 URL 格式写错了。即便 Linux 7.0 已经在 2026 年 4 月发布，内核 QUIC 到现在依然在树外。想用的话，得自己构建 out-of-tree 模块，仓库依旧标着 EXPERIMENTAL，五部曲也只上了第 1-2 部。

LWN 拿来做对比的案例很能说明问题 — Homa 协议在 9 个月里改了 11 版，依然没有合并。往内核网络子系统里塞一个新协议，本来就是这么慢的事。「内核 QUIC 快来了，等等看」不能算是一个计划。

那个 45.2% 现在还成立吗

还有一点得诚实地说清楚。WWW 2024 的论文是用 Chromium v102 测的，那是 2022 年的构建版本。实现在这之后一直在变化。

论文的建议之一是「Chromium 目前用 recvmsg 逐个读取 UDP 数据包，如果改用 recvmmsg 在一次系统调用里读取多个，接收性能可能会改善」。今天打开 Chromium 的源码，在 net/socket/udp_socket_posix.h 里能看到一条注释，说在支持 recvmmsg 的平台(Linux、ChromeOS、Android)上会使用它。看起来部分建议已经被采纳了。

但另一方面，翻看同一个文件以及 net/socket/udp_socket_posix.cc，我没有看到开启 UDP_GRO 的代码。这只是我在某个特定时间点查了两个特定文件的结果，Chromium 的 socket 路径不止一条，所以作为定论的依据比较薄弱 — 但这是一个可以自己去核实的点，所以记在这里。

所以别把 45.2% 这个数字原封不动地套到今天的 Chrome 上。这个数字告诉你的，不是一个精确的倍数，而是一种机制：用户态传输不得不自己去做那些原本由内核代劳的工作(数据包合并、ACK 生成、延迟 ACK)，而一旦链路变快、瓶颈从线路转移到 CPU 上，这份成本就会显现出来 — 这个机制不会因为实现改变而消失。具体倍数，你得在自己的环境里重新测。

那么，什么时候该用，什么时候不该用

把前面这些一手资料汇总起来，判断标准就相当清晰了。

QUIC/HTTP3 用了值回成本的情况

  • 客户端处在有丢包、RTT 较长的网络里。移动端、远距离、不稳定的无线网络。这正是 Google 测量中收益集中在尾部(第 99 百分位)的原因。
  • 连接又短又多。0-RTT/1-RTT 的握手收益会相对更大。
  • 确实需要连接迁移。在蜂窝网络和 Wi-Fi 之间切换的客户端。
  • 想改善那些由最差区间主导用户体验的指标，比如卡顿率。

属于过度或者反而吃亏的情况

  • 链路快，而且没有丢包。数据中心内部、千兆有线网络。WWW 2024 论文的条件正是如此。一旦线路不再是瓶颈，剩下的就只有 QUIC 的 CPU 成本。
  • 大容量批量传输是主要工作负载。文件下载、备份、大型制品。
  • 客户端很弱。嵌入式设备、低端安卓机。这正是论文 Table 1 中差距最大的地方。
  • 需要一个内核消费者。内核态的 NFS/SMB 没法链接用户态的 QUIC 库，而内核 QUIC 还没进主线。

如果你已经在用 QUIC，而且觉得慢，按这个顺序排查。加密加速或内核旁路放在最后。

  1. 先确认瓶颈是不是真的是 CPU。如果线路才是瓶颈，QUIC 的 CPU 成本根本看不出来。
  2. 如果是发送端，先从 UDP GSO 入手。在 Google 的测量中，再加上硬件 offload 通常能到 5 倍。
  3. 看 ACK 的频率。发送端和接收端都各有大约 25% 挂在这上面。
  4. 之后才轮到怀疑加密。在 WWW 2024 的测量里，解密反而是 QUIC 比 HTTP/2 更快。

结语

归纳一下就是这样。QUIC 在握手和丢包恢复上确实赢了，而且这份收益在尾部比在平均值上更大。而链路一旦变快，它就会输 — 瓶颈从线路转移到 CPU 的拐点大致在 500~600 Mbps 一带，超过这个点，用户态传输所付出的成本就会原原本本地暴露出来。

成本的真相不是加密，而是数据包被动手的次数。因为内核没有用 GRO 帮忙合并，多出 15 倍的数据包被送到了用户态，而原本由内核代劳的 ACK，现在得自己动手做，还没有延迟 ACK 之类的优化。这就是为什么 2026 年的答案是「搬进内核」，而这个答案还在评审中 — 主线和 net-next 里都还没有它。

那份补丁自己的基准测试给出了最后一课。就算搬进了内核，跟 kTLS 比还是要输将近两倍。但只要把 TCP 的 GSO 关掉试试，差距几乎就消失了。说到底，这从来都不是内核还是用户态的问题，而是能不能用上 offload 的问题。TCP 快，不是因为它资历老，而是因为资历老，硬件才有时间去帮它。

QUIC 要等到那份帮助落地，还得再等一阵子。在那之前，选协议之前，先测一测你的瓶颈到底是线路还是 CPU。答案会因此而反转。

参考资料

현재 단락 (1/149)

关于 QUIC 的故事，通常以「比 TCP 快」开场，以「所以打开 HTTP/3 吧」收尾。本文要讲的是它的另一面 — QUIC 在什么条件下会输，以及为什么。但要做到公允，得先确认它赢在哪里。而且这...

작성 글자: 0자원문 글자: 11,385자작성 단락: 0/149