分布式计算的八大谬误:21年持续影响(2025)

Hacker News Top 新闻

摘要

对最初由Sun Microsystems工程师提出的分布式计算八大谬误的回顾,探讨21年后这些谬误对网络运营商和开发者的持续相关性。

暂无内容
查看原文
查看缓存全文

缓存时间: 2026/06/15 08:57

# 分布式计算的八个谬误——21年,仍在延续 | APNIC 博客 来源:https://blog.apnic.net/2025/12/08/21-years-and-counting-of-eight-fallacies-of-distributed-computing/ 分布式计算的八个谬误。 你可能会以为,到了今天,网络已经被人们充分理解,大家不会再去做那些从网络诞生之初就知道是错误的前提假设了。然而,作为用户、开发者和网络管理员,我们似乎仍然无法摆脱一些长期以来的信念。 也许最著名的一组关于网络的错误观念,就是**分布式计算的八个谬误**([来源](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing))。 1. [网络](https://en.wikipedia.org/wiki/Computer_network)是可靠的 2. [延迟](https://en.wikipedia.org/wiki/Latency_(engineering))为零 3. [带宽](https://en.wikipedia.org/wiki/Throughput)是无限的 4. 网络是[安全的](https://en.wikipedia.org/wiki/Computer_security) 5. [拓扑](https://en.wikipedia.org/wiki/Network_topology)不会改变 6. 只有一个[管理员](https://en.wikipedia.org/wiki/Network_administrator) 7. 传输成本为零 8. 网络是同质的 ## 这份清单从何而来? 最初只有四个谬误(即清单中的前四个),由 Bill Joy 和 Tom Lyon 收集整理,两人是 Sun Microsystems 最初八位创始人和员工中的两位。 Sun 整合了高速图形、UNIX 操作系统和一套可用的互联网协议栈,这推动了桌面计算的爆发、它们的迅速崛起,以及最终被 Oracle 收购。当你使用 Berkeley Software Distribution (BSD) 变体、Linux 发行版,甚至 Android 时,你都在使用源自 Sun Microsystems 的技术。想想 [ZFS](https://en.wikipedia.org/wiki/ZFS) 文件系统、用于网络文件存储的 [Network File System (NFS)](https://en.wikipedia.org/wiki/Network_File_System) 协议,以及 Java,仅举几例。 后来,L. Peter Deutsch 扩充了这个列表,在 Sun 时又添加了三个谬误。最后一个谬误由 James Gosling 提出——他同样曾在 Sun 工作——最终形成了我们现在熟知并喜爱的八个谬误。 随着时间的推移,这些观念被沉淀下来,并启发了其他谬误清单,例如有关[日期和时间](https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca)的谬误,或者[人们关于名字的假错误观念](https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/)。我相信还有更多。我们在填写表单、与网页或应用中的资产交互时,几乎每天都在遇到这些日期和名字相关的错误。 底层的这八个分布式计算谬误,埋藏在我们对网络的使用中,成了“恒量”。作为网络运营者,无论是在协议和软件设计中,还是思考它们如何影响用户的日常生活,都值得将这些谬误铭记在心。通过牢记它们,我们可以在日常线上遇到这些谬误引发的行为时,更好地应对。 这份清单旨在针对编写网络软件的人:那些调用网络服务的应用、被网络调用的服务,以及网络协议。它提供了实用的指导——尽管以抽象方式呈现——关于如何思考通过网络发送数据,以及你应该提出的问题。例如: - 数据真的发送出去了吗? - 它被接收了吗? - 你怎么知道? - 你能重新发送吗,还是数据已经丢失? - 它甚至需要重新发送吗? - 你有时间处理这些数据吗?它会如何影响你程序的其余部分? - 尽管网络很复杂,它的行为是否以你真正理解的方式在运作? ## 逐个审视这些谬误 以下是我个人对这八个分布式计算谬误含义的理解,它们与我及我的服务与网络交互的方式相关。其他人有不同的看法,我也可能有一些错误。 **图 1 — 分布式计算的八个谬误**([图片来源](https://blog.apnic.net/wp-content/uploads/2025/11/image-25.png)) ### 1. 网络是可靠的 从整体来看,互联网可能随时在某些地方、对某些用户而言是失效的。我们个人能体验到它的可靠可用,是希望战胜经验的结果。所谓的“五个九”([99.999%](https://www.splunk.com/en_us/blog/learn/five-nines-availability.html))可靠性说法,常常让我们以为“这不会发生在我身上”。 更具体地说,人们往往假设一旦一个数据包被发送出去,它就会被接收到。大多数情况下确实如此。但我们仍然必须设计协议来处理那些未能正常接收的情况。 想想衡量网络行为的三个经典指标中的第一个:丢包、延迟和抖动。“丢包”只不过是“不可靠”的另一种说法。如果你的协议不考虑数据可能丢失的事实,那么它迟早会遇到问题。TCP 和 QUIC 协议层的大部分设计,正是为了识别数据包丢失并处理它。 互联网协议(IP)——无论是第四版还是第六版——并不保证交付。这个责任需要由上层协议来承担(如果它们有能力的话)。 ### 2. 延迟为零 延迟包含了上面提到的另外两个网络问题:延迟和抖动。延迟有时仅仅是距离的函数,受限于光速——但即使这一点也可能被误解,因为光纤中的光速比真空中慢。 此外,当信号从铜缆转换为光纤并沿光纤链路传输时,也会产生额外的延迟。因此,通过微波、无线电甚至卫星之间的激光发送数据,有时可能比通过光纤更快。 抖动,即延迟的变化,是游戏和流媒体协议面临的主要挑战。延迟和丢失正是像 Netflix 这样的服务既进行数据缓冲又使用纠错编码的原因。这些技术补偿了延迟的波动,提供了平滑可靠的播放体验。 ### 3. 带宽是无限的 人们很容易认为,在现代互联网中,对于大多数实际用途,带宽可以被视为近乎无限。然而现实是,系统中的许多链路都有比可用空间更多的用户发送数据包。 应对“非无限”带宽的后果会引入排队,进而产生延迟。有延迟就会带来抖动,在极端条件下还会导致丢包。有限带宽的限制直接影响着每个受此约束的网络流量。 在今天的网络中,数据通常通过内容分发网络(CDN)“就近”存放,我们很少注意到这一点。从带宽角度看,网络的限制往往离我们很远——只有一个例外:我们本地的家庭链路。 我们可能使用千兆级设备,但本地链路速度通常只有几百兆比特。我们能超过家庭路由器的容量吗?几乎轻而易举。我们能否超过家庭 Wi-Fi 网络的速度?当然可以。一部现代手机可以维持 400 Mbit/秒或更高的速率,但五年前购买的 Wi-Fi 网络可能只能支持 100 Mbit/秒。 投资网络带宽以匹配期望,就像建造道路来应对高峰时段的交通:你可以让拥塞看起来不存在,但成本可能超出预期。在升级家庭路由器以匹配新的光纤到户速度时,我们面临同样的问题:我们真正需要多少带宽? ### 4. 网络是安全的 在电信垄断的时代,当单一运营商在整个经济体系内运行网络时,主要风险只有一个:运营商可能无法确保我们数据的隐私。通常他们控制着所有基础设施,入侵虽然并非闻所未闻,但也很少见。编码开销很小,执法部门可以通过单一渠道访问数据。 今天,网络跨越多个运营商和与我们没有关系的中间商运行。继续相信没有人会“看到”我们的数据包是幼稚的。我们能做的是确保数据包本身只包含保密、受保护的数据。设计协议来提供这种保护——无论是现在还是未来——既昂贵又耗时。随着量子计算对公钥-私钥加密的威胁逐渐显现,即使是这种保护也可能不像我们期望的那样有保障。 然而,即使是受保护的数据包也会暴露信息。流量分析可以暴露模式,而先进的机器学习仅凭数据包定时和大小就能区分流媒体、文件存储和交互式流量。永远不要认为网络本质上是安全的,也永远不要依赖 HTTPS 或传输层安全(TLS)连接以下层来让你对他人隐藏。 ### 5. 拓扑不会改变 拓扑变化来自多种来源。当你的手机连接到不同的基站时,或当你通信对方的手机切换基站时,拓扑就会发生变化。当你的提供商为了效率或利润优化流量,以不同于你预期的方式路由数据包时,也会发生变化。我们体验到这些拓扑变化时,表现为丢包、延迟和抖动。 像是 QUIC 和 TCP 这样的传输协议,保护我们免受网络“中间”变化以及由此对数据包从源到目的地的路径造成的影响。然而,管理这些变化的流程——例如虚拟路由器冗余协议(VRRP)、通用地址冗余协议(CARP)、边界网关协议(BGP)或多路径 TCP——并非没有代价。这些开销意味着,像无丢包、无延迟或无重复数据这样的假设,是不可靠的。 ### 6. 只有一个管理员 有时候,感觉甚至连一个管理员都没有。另一些时候,似乎只有一个管理员反而比我们遇到的多个管理员更好。即使是在一个网络运营中心(NOC)内部,也可能有多双不同的手、多种模型和多个流程在运作。现代网络如此复杂,以至于你与之交谈的管理员很可能并不是实际在系统中进行变更的人。 ### 7. 传输成本为零 成本是多维度的。以短消息服务(SMS)协议为例。如果你把通过 SMS 发送几个数据包的成本乘以发送一部电影所需的数据包数量,总成本将达到数千美元。但这能反映实际成本吗? 成本在网络中来自哪里?是发送数据包所需的电力?硬件?支持系统、业务逻辑、会计和风险管理?所有这些都贡献了现实世界的成本,使得数据传输成为可能。仅仅因为成本没有在协议中直接暴露,并不意味着成本不存在——它意味着成本已被社会其他地方吸收了。 有些成本永远不会被直接收回,而是成为“商业成本”总额的一部分。其他一些成本,比如从 Amazon S3 长期存储中发送和检索数据所收取的不对称费用,则是刻意设计来鼓励只在必要时才取回数据。 ### 8. 网络是同质的 BGP 路由中一个很大的谬误是认为“成本”等于 AS 路径长度。如果你忽略所有其他因素,你可能会倾向于选择 AS 跳数最少的路径。但这真的明智吗? 考虑一下将欧洲节点通过一条缓慢、昂贵、低容量的链路连接到亚洲节点,同时将你所有欧洲对等体暴露给你的亚洲对等体。那条纤细且昂贵的链路很快就会变得拥塞。延迟、带宽和负载能力的不一致性几乎会立刻显现出来。 即使在简单的家庭网络中,Wi-Fi 设备与以太网设备之间的差异也很明显。一台通过 Wi-Fi 流式传输视频的电视会与同一信道上的其他设备争夺空中时间,而使用以太网交换机时这个根本问题就不存在了。 延迟和重传的成本在很大程度上被过度供应、缓冲和编码所掩盖。然而,如果你仔细观察网络行为,差异是很明显的。IP 掩盖了本地与远程、慢速与快速、可靠与不可靠连接之间的许多细微差别。但高层协议必须处理这些现实——平衡时间、缓冲区使用和计算开销——以便在当时条件下提供尽可能最好的服务。 ## 关于谬误清单,我们相信的谬误 如果关于网络谬误的列表本身不包含一个谬误,那网络就不是我们熟知和喜爱的样子了。网上对这些谬误的几次讨论错误地将 Tom Lyon 称为 Dave Lyon。看来,随着时间的推移,就连事实也不能指望始终不变了。 也许有一天,这八个谬误的列表会增加到九个或十个。我认为它不太可能减少到七个。 --- 本文作者表达的观点仅代表其个人,并不一定反映 APNIC 的观点。请注意,本文适用[行为准则](https://blog.apnic.net/?p=395)。

相似文章

未来并非均匀分布

Lobsters Hottest

一篇反思性文章,讨论一个25年历史的Perl CGI脚本的支持请求,借此探讨技术进步分布不均的问题,以及大多数企业只想要可靠的解决方案。

Unix 2038年问题与低估的艺术

Lobsters Hottest

这篇文章讨论了Unix 2038年问题和各种历史上的溢出和日期相关技术漏洞,强调了工程权衡和可维护软件的重要性。