网络与分布式2024dl.acm.org
QUIC 在高速互联网上还不够快
QUIC is not quick enough over fast internet
进阶 · 约 60 分钟读完前置知识：QUIC 协议基础、TCP/IP 协议栈、Linux 网络编程
导读
这篇论文研究了 QUIC 在高速网络环境下性能不及 TCP/HTTP2 的问题，指出 UDP 协议栈缺乏优化、系统调用开销过大、缓冲区默认设置过小等是主要瓶颈。论文分析了这些具体性能障碍，为后续 UDP/QUIC 栈的优化指明方向。
HN 关注点：HN 读者长期关注 QUIC 的实际性能表现，这篇论文用数据证实了社区早有怀疑的'QUIC 在快网络下不如 TCP'的问题，引发对内核 UDP 栈优化和协议设计的讨论。
HN 评论精选
这几条评论里：支持 1 质疑 2 补充 1
补充详细列举了 QUIC 性能瓶颈的具体技术原因：syscall 开销、UDP 缓冲区过小、GSO 的局限等
论文指出了几个具体问题：系统调用接口混乱，原始 API 处理常规大小数据包（约 1500 字节）太慢、开销太高；GSO 虽有帮助但 API 设计糟糕，近期还因复杂度和低劣代码质量出现 bug。Spectre 缓解措施让系统调用成本更高，BSD sockets/POSIX API 这十年表现糟糕，需要替代方案——不一定要用 uring 那么复杂，可以有一个安全且开销低 10 倍的中间层 API。系统 UDP 缓冲区默认值远小于 TCP，只有专家会去调优。UDP 栈的优化是可行的（如不通过 connect(2) 复用路由查找），GSO 证明了这一点，但它本身开销大、设计过于复杂，尤其我们希望非特权用户态也能安全使用。此外一些优化只在低/中规模下有效，比如 GSO 在多对端竞争的 socket 上会因单对端限制导致 offload 链变短，收益被侵蚀。
raggi查看英文原文
There are a number of concrete problems: - syscall interfaces are a mess, the primitive APIs are too slow for regular sized packets (~1500 bytes), the overhead is too high. GSO helps but it’s a horrible API, and it’s been buggy even lately due to complexity and poor code standards. - the syscall costs got even higher with spectre mitigation - and this story likely isn’t over. We need a replacement for the BSD sockets / POSIX APIs they’re terrible this decade. Yes, uring is fancy, but there’s a tutorial level API middle ground possible that should be safe and 10x less overhead without resorting to uring level complexity. - system udp buffers are far too small by default - they’re much much smaller than their tcp siblings, essentially no one but experts have been using them, and experts just retune stuff. - udp stack optimizations are possible (such as possible route lookup reuse without connect(2)), gso demonstrates this, though as noted above gso is highly fallible, quite expensive itself, and the design is wholly unnecessarily intricate for what we need, particularly as we want to do this safely from unprivileged userspace. - several optimizations currently available only work at low/mid-scale, such as connect binding to (potentially) avoid route lookups / GSO only being applicable on a socket without high peer-competition (competing peers result in short offload chains due to single-peer constraints, eroding the overhead wins). Despite all this, you can implement GSO and get substantial performance improvements, we (tailscale) have on Linux. There will be a need at some point for platforms to increase platform side buffer sizes for lower end systems, high load/concurrency, bdp and so on, but buffers and congestion control are a high complex and sometimes quite sensitive topic - nonetheless, when you have many applications doing this (presumed future state), there will be a need.
支持认为 UDP 栈长期缺乏优化是问题根源，这篇论文会推动相关优化
QUIC 早期就有很多人指出，UDP 协议栈得到的优化远少于 TCP 栈。果然，本文发现的一些问题正是因为 UDP 栈没有做那些本可以做但没人有动力去做的事，比如 UDP 通用接收卸载（GRO）。这类论文很可能催生各种明显或微妙的优化。
JoshTriplett查看英文原文
In the early days of QUIC, many people pointed out that the UDP stack has had far far less optimization put into it than the TCP stack. Sure enough, some of the issues identified here arise because the UDP stack isn't doing things that it could do but that nobody has been motivated to make it do, such as UDP generic receive offload. Papers like this are very likely to lead to optimizations both obvious and subtle.
质疑质疑 Google 主导的协议设计过于仓促，HTTP/2 的 server push 就是前车之鉴
HTTP/2 似乎也很仓促[1]。Chrome 已经移除了对 server push 的支持。也许应该在这些协议上多花些心思，而不是直接把 Google 想强推给我们的东西换个名字就上线。
sbstp查看英文原文
Even HTTP/2 seems to have been rushed[1]. Chrome has removed support for server push. Maybe more thought should be put into these protocols instead of just rebranding whatever Google is trying to impose on us. [1] https://varnish-cache.org/docs/trunk/phk/h2againagainagain.html
质疑质疑 QUIC 用户态实现这一架构决策本身
也许把连接协议搬到用户态并不是个好主意。
jacob019查看英文原文
Maybe moving the connection protocol into userspace isn't such a great plan.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2024Hacker News 讨论帖664 分 · 326 评
同领域还值得读
Paxos vs. Raft：分布式共识是否已达成共识？
Paxos vs. Raft: Have we reached consensus on distributed consensus?
重新审视了 Paxos 与 Raft 两种分布式共识算法之间的差异，试图在一个统一的框架下比较它们，并论证二者的相似程度远高于通常的认知，许多所谓的差别只是表述层面的。
网络与分布式2020 · 343 分 · 65 评 · 引用 10进阶 · 约 28 分钟编辑精选Stellar 协议：互联网级共识的联邦模型
Stellar Protocol: A Federated Model for Internet-Level Consensus (2016)
提出 Stellar Consensus Protocol（SCP），一种面向互联网级共识的联邦拜占庭协议模型。
网络与分布式2018 · 301 分 · 61 评专业 · 约 90 分钟编辑精选拜占庭将军问题（1982）
The Byzantine Generals Problem (1982)
这篇 1982 年论文提出并形式化了拜占庭将军问题：在分布式系统中，部分节点可能叛变或故障、通信不可完全信任时，忠诚节点如何达成一致行动。
网络与分布式2018 · 290 分 · 77 评进阶 · 约 75 分钟编辑精选Google 变差了吗？对搜索引擎中 SEO 垃圾的纵向调查
Is Google Getting Worse? A Longitudinal Investigation of SEO Spam in Search
对搜索引擎结果中的 SEO 垃圾内容做了纵向追踪：作者团队在一段时间内持续采集 Google、Bing、DuckDuckGo 等引擎针对商品评测类查询的结果，用分类器识别联盟营销…
网络与分布式2024 · 276 分 · 274 评入门 · 约 45 分钟编辑精选使 CRDT 能够容忍拜占庭故障
Making CRDTs Byzantine Fault Tolerant
Martin Kleppmann 等人的论文研究如何让 CRDT（无冲突复制数据类型）抵御拜占庭故障节点，即部分参与者恶意篡改数据时仍能保证一致性。
网络与分布式2022 · 266 分 · 40 评进阶 · 约 90 分钟编辑精选