网络与分布式2024arxiv.org
QUIC 在高速互联网上不够快
QUIC is not quick enough over fast internet
进阶 · 约 60 分钟读完前置知识：TCP/IP 协议基础、QUIC/HTTP3 基础、拥塞控制概念
导读
这篇论文研究 QUIC（UDP+QUIC+HTTP/3）协议栈在高速网络下的传输性能问题。实验发现，在快速互联网环境下，QUIC 相比 TCP+TLS+HTTP/2 的数据传输速率最多下降 45.2%，作者将原因指向 QUIC 把流控等逻辑从内核移到用户空间带来的开销。
HN 关注点：HN 读者长期关注 QUIC/HTTP/3 的实际收益，这篇论文用数据质疑了 QUIC 在高带宽场景的性能优势，引发关于协议设计权衡的讨论。
HN 评论精选
这几条评论里：支持 1 质疑 1 补充 1
支持有 QUIC 相关工程经验者认为结果符合预期，并强调延迟才是实际性能的关键因素
我在 Google 做过纯 JS 的测速工具（当时 Ookla 还是 Flash，无法在 Chromebook 上用），因此对 TCP 如何响应各种因素了解很多。看到这篇文章觉得结果基本符合预期：QUIC 把流控从内核（甚至网卡）移到了用户空间，TCP 的流控和排序由内核处理，QUIC 则要自己管理。这样做有合理动机——TCP 拥塞控制早已跟不上现代网速，催生了 BBR 等新算法——但代价就是这些开销。我最大的体会是：延迟。住在亚洲或澳洲的人都懂，100ms RTT 可能是毁灭性的，它会让完全流畅的应用变得不可用，还会因窗口限制降低单连接可用带宽，并削弱对错误和拥塞控制的响应。强烈建议做网络或 Web 应用测试时随机加入 100ms 延迟来测。
cletus查看英文原文
At Google, I worked on a pure JS Speedtest. At the time, Ookla was still Flash-based so wouldn't work on Chromebooks. That was a problem for installers to verify an installation. I learned a lot about how TCP (I realize QUIC is UDP) responds to various factors. I look at this article and consider the result pretty much as expected. Why? Because it pushes the flow control out of the kernel (and possibly network adapters) into userspace. TCP has flow-control and sequencing. QUICK makes you manage that yourself (sort of). Now there can be good reasons to do that. TCP congestion control is famously out-of-date with modern connection speeds, leading to newer algorithms like BRR [1] but it comes at a cost. But here's my biggest takeaway from all that and it's something so rarely accounted for in network testing, testing Web applications and so on: latency. Anyone who lives in Asia or Australia should relate to this. 100ms RTT latency can be devastating. It can take something that is completely responsive to utterly unusable. It slows down the bandwidth a connection can support (because of the windows) and make it less responsive to errors and congestion control efforts (both up and down). I would strongly urge anyone testing a network or Web application to run tests where they randomly add 100ms to the latency [2]. My point in bringing this up is that the overhead of QUIC may not practically matter because your effective bandwidth over a single TCP connection (or QUICK stream) may be MUCH lower than your actual raw bandwidth. Put another way, 45% extra data may still be a win because managing your own congestion control might give you higher effective speed over between two parties. [1]: https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-control-84c9c11dc3a9 [2]: https://bencane.com/simulating-network-latency-for-testing-in-linux-environments-29daad98efcc
补充指出论文对“快速网络”的定义门槛（600 Mbit/s 以上）
论文摘要指出：在快速互联网下，UDP+QUIC+HTTP/3 相比 TCP+TLS+HTTP/2 数据速率最多降低 45.2%。还没读完全文，但引言暗示低于 600 Mbit/s 就算“慢速互联网”了。
lysace查看英文原文
> We find that over fast Internet, the UDP+QUIC+HTTP/3 stack suffers a data rate reduction of up to 45.2% compared to the TCP+TLS+HTTP/2 counterpart. Haven't read the whole paper yet, but below 600 Mbit/s is implied as being "Slow Internet" in the intro.
质疑质疑业界方向：与其优化协议，不如把网页做轻量
除了把网站做轻量之外，业界什么都愿意做。90 年代末如果运气好有快连接，上网体验是即时的——页面很小，几乎没有 JavaScript。今天仍能找到这种轻量页面，加载体验近乎超现实：鼠标还没松开页面就加载完了。可惜用户体验并没有因此更好，否则还能接受。
tjoff查看英文原文
Industry will do absolutely anything, except making lightweight sites. We had instant internet in the late 90s, if you were lucky enough to have a fast connection. The pages were small and there were barely any javascript. You can still find such fast loading lightweight pages today and the experience is almost surreal. It feels like the page has completely loaded before you even released the mousebutton. If only the user experience were better it might have been tolerable but we didn't get that either.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2024Hacker News 讨论帖313 分 · 280 评
同领域还值得读
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 分钟编辑精选