网络与分布式2020arxiv.org
必须、应该、不在乎：真实环境中的 TCP 一致性
Must, Should, Don't Care: TCP Conformance in the Wild
进阶 · 约 50 分钟读完前置知识：TCP 协议基础、RFC 规范用语（MUST/SHOULD/MAY）、网络测量方法
导读
这篇论文（arXiv 2020）系统测量了现实网络中 TCP 实现的一致性问题：作者构造探测手段，检测各操作系统/中间件在哪些 TCP 规范要求（MUST）、建议（SHOULD）和可选（MAY）行为上做得不对或选择不做。结论大致是：强制项大体被遵守，但建议项和可选行为差异很大，说明 RFC 里大量 SHOULD/MAY 让互操作性变得脆弱。
HN 关注点：RFC 中 MUST/SHOULD/MAY 的模糊性如何导致现实实现分歧，以及这些不一致如何迫使开发者写兼容性 workaround。
HN 评论精选
这几条评论里：支持 1 补充 2 亲历 1
亲历亲历者回顾早期 TCP 一致性排查，并解释 urgent 选项的历史用途、认为可以废弃。
这让我回想起 TCP 早期，我当时就在做这种事。我的实现里有个"bit bucket"，凡是拒绝的包、或没能推进连接的包（比如重复包）都记录下来，然后给其他开发者发邮件："你在 T 时刻发的包不符合规范，见第……段。"慢慢地情况就好转了。urgent 选项可以废弃了。它原本的用途是 TELNET 往慢速打印终端（如 Teletype）送数据时想取消输出：TCP 连接因流控被打印机拖住，输入方向也可能因为提前输入而被卡住。用户按下 BREAK，TCP 发出 urgent 消息绕过排队数据，服务器收到后停止发送并清空输出队列。本世纪几乎没人需要这个功能了，但某处可能还有人在用古董嵌入式设备，比如收银机打印机。
Animats查看英文原文
This takes me back to the early days of TCP, when I used to do this. I had a TCP implementation with a "bit bucket"; every packet that was either rejected or didn't advance the connection (such as a duplicate) was logged. Then I'd send out emails to other developers; "Your packet sent at T did not conform to spec, per para..." Gradually, things got better. The "urgent" option could be deprecated. The original purpose was for when a TELNET connection was sending data to a slow printing terminal such as a Teletype, and you wanted to cancel the output. The TCP connection was being held back by flow control waiting for the printer on output, and might be held back on input if you'd typed ahead but the server wouldn't take another line until the output was done. The user would push BREAK, the TCP connection would send an urgent message, bypassing any queued data, and the server would get this, stop sending, and clear its output queue. Almost nobody has needed that feature in this century. But there's probably someone, somewhere, with some ancient embedded device like a cash register printer, using it.
支持批评 RFC 中 SHOULD/MAY 造成互操作负担，主张把可选部分剥离到扩展。
实现 RFC 时遇到"Should"和"May"这些词实在太痛苦了。有时候，为那些只实现"Must"的对端写 workaround，比直接把整个 RFC 都当强制项实现还难。我认为 RFC 应该尽量减少规范中的可选部分，剩下的挪到扩展文档里。
Eikon查看英文原文
"Should" and "May" are such horrible words to encounter when implementing an RFC. Sometimes, implementing workarounds for ends that only implements "Must" is harder than just implementing the RFC as if everything was just mandatory. In my opinion, RFCs should strive to limit the optional parts of a specification at a minimum and, maybe, put the remaining in extensions.
补充用 Hyrum 定律说明实现者会依赖可观察行为（包括未规定的），加剧一致性问题的现实影响。
这让我想起"Hyrum 定律"：当一个 API 有足够多的使用者，无论你在契约里承诺什么，系统的所有可观察行为都会有人依赖。人们可能会为 API 的 bug 写 workaround，而底层 bug 一旦修好，这些 workaround 反而会坏掉；或者软件只实现刚好能让它和某个特定实现配合工作的最小集合。
iwalton3查看英文原文
This reminds me of "Hyrum's Law": "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." People might implement work-arounds for bugs in an API that could break when the underlying bug is fixed. Or software might implement the absolute bare minimum for it to "work" with some specific implementation.
补充询问是否存在公开的 TCP 一致性/测试向量基准。
有没有什么标准化的 TCP "测试向量"？哪怕是像 TLS 领域 SSLLabs 那种非正式的事实标准测试也行。
oconnor663查看英文原文
Is there a standardized set of TCP "test vectors" anywhere? Even an informal de facto standard test like what SSLLabs is for TLS?
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2020Hacker News 讨论帖155 分 · 52 评
同领域还值得读
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 分钟编辑精选