2009年4月15日
第7卷，第3期

对抗物理学：一场艰难的战斗

考虑长期进行IPC吗？再想想。物理定律告诉你，你没戏了。

Jonathan M. Smith，宾夕法尼亚大学

在过去的几年里，SaaS（软件即服务）已成为公司节省资金和简化其计算基础设施的有吸引力的选择。SaaS是一组有趣的技术，用于将计算从桌面转移到云端；然而，随着它越来越受欢迎，工程师应该意识到在开发这些类型的分布式应用程序时面临的一些基本限制——特别是，光速是有限的。

考虑一家公司想要构建一个分布式应用程序，该应用程序在长距离上进行IPC（进程间通信）。显而易见的建议是“直接拒绝”——不要这样做。如果你要远远超出本地网络环境，距离物理学和光速，再加上来自互联网路由基础设施的延迟，都告诉我们这将太慢了。然而，这些概念通常不被理解，即使被理解了，有时也会被遗忘。

那么，所有软件开发人员都需要熟悉的与光速和网络跃点相关的基本原则到底是什么呢？本文通过首先通过一个例子来阐述一些定量的初步知识，然后转向网络影响，最后涵盖应用程序来回答这个问题。最后，它提供了一些经验法则，以便在应用程序和架构随着新的网络能力和不变的物理学而演变时牢记在心。

预备知识：物理学

真空中光速正好是 299,792,458 米/秒。¹ 这是您可以移动一位数据的最快速度，并且根据我们目前对物理学的理解，这是我们所处宇宙的基本约束。在光纤中，光速为 2.14×10⁸ 米/秒，约为真空中光速的 70%。如果将光纤直线拉伸从纽约到旧金山，大约长 4,125 公里，光单向传输需要大约 19 毫秒（4,125 ÷ 214）。假设使用 8,250 公里的光纤长度，您可以将此时间加倍以获得最小往返时间的估计值。

乍一看，19 毫秒似乎是很短的时间，当然在人类尺度上是这样。然而，作为计算机科学家，我们通常关注不同的时间尺度：计算机的时间尺度。在这里，我们可以用指令来计算 19 毫秒，指令是计算机工作基本单位。例如，我们可以使用 2003 年的单核机器：英特尔奔腾 4 极限版，它的时钟频率为 3.2 GHz，额定速度为每秒 9726 百万条指令：9,726 × 0.019 是 1.84 亿条指令——例如，足以搜索或排序数百万个名称。

始终重要的是要记住，计算机联网的目的是互连计算机，而计算机在非常短的时间尺度上运行。此外，单个人工操作有时会转化为许多计算机操作（即，往返）。例如，打开一个网页通常需要多次往返，即使您只获得一个大型对象（例如，一张大图片），这将在本文稍后进一步讨论。

传播、带宽、延迟和跃点

纽约和旧金山之间的光纤环路遍历假定数据传输单位为单个编码的二进制信息位。该遍历的下限将是 2×19，即 38 毫秒（或 3.68 亿条指令）。该位从其源到其目的地再返回所需的时间称为其传播延迟。

传播延迟很重要，但与更常见的带宽指标（以比特/秒为单位测量）相比，它很少被引用为性能指标。至少部分原因是观察到的传播延迟取决于上下文，而带宽（例如光纤传输系统的带宽）可以单独测量。带宽也可以通过工程技术来提高（例如，通过用于传输系统的编码方案，该方案对每个符号编码多个比特），因此对于那些构建传输系统的人来说，它作为性能指标更具吸引力。最后，带宽是衡量工作量的指标，这对购买者具有吸引力。

带宽也会影响延迟，在我看来，延迟与传播延迟不同；传播延迟是第一个比特的指标，而延迟是整个数据单元的指标，其中可能包含多个比特。一般来说

延迟 = 传播延迟 + 数据单元大小 ÷ 带宽

这基本上表明传播延迟只是整个情况的一部分，带宽也会影响性能。查看示例系统中带宽的影响，可以显示为什么传播延迟如此重要。考虑一个 10 Gbps 的传输系统和一个 1,250 字节（或等效地，10 Kbit，选择它既是为了反映以太网合理的 MTU，也是为了使算术更容易！）的数据单元。纽约/旧金山环路中第一个比特的传播时间为 38 毫秒，最后一个比特在一微秒 (10K/10G) 后到达，使总延迟为 38.001 毫秒。延迟的大部分是传播延迟。一个有趣的算术练习是计算传输系统的延迟是传播延迟两倍的距离。对于 10 Gbps 的传输系统和 10 Kbit 的数据单元大小，这大约是 214 米，或几个街区。对于较小的数据单元或更长的距离，传播延迟是延迟的大部分。（John Shaffer 和我在之前的一篇论文中提供了关于传播延迟与延迟的更多详细信息。⁴）

进行一些测量以了解情况是很有启发意义的。使用 ping 实用程序发送 ICMP ECHO 数据包，我测量了宾夕法尼亚大学 (klondike.cis.upenn.edu) 和斯坦福大学 (cs.stanford.edu) 两个连接良好的站点之间的往返延迟，约为 87.5 毫秒。将此四舍五入为 88 毫秒，并减去 38 毫秒的光纤传播时间，剩下 50 毫秒的差异。（请注意，纽约-旧金山的数据被认为大致相当于费城到帕洛阿尔托的数据。）由于这些数据单元只有大约 500 比特长，因此宾夕法尼亚大学和斯坦福大学之间的带宽必须非常差（50 毫秒内 500 比特约为 10 Kbps！）才能解释延迟。那么原因可能是什么呢？

至少有两个可能的因素，这两个因素都可以用跃点的概念来解释。要理解跃点，了解网络与我们 8,250 公里的光纤环路有何不同很有帮助。一个真正的网络是由许多互连的部分构建的——例如，局域网和广域网。图 1 表示真实的物理网络拓扑，具有多种类型的网络和多个设备。主机标记为 H，路由器标记为 R，网络类型显示为多种性质。

正在使用许多不同的数据包格式和数据单元，而互联网的巧妙之处在于它有一个解决方案使它们协同工作。此互操作性层由数据包格式和地址组成，这些地址由称为 IP 路由器的设备解释。互连路由器的子网可以使用他们选择的任何技术，只要他们可以在路由器之间传输封装的 IP 数据包即可。每个路由器-路由器路径称为一个跃点。与之前的 ping 一样，获得测量结果是有启发意义的，我使用 traceroute 在我之前使用的两个主机之间获得了测量结果。报告有 17 个跃点。我们对畅通无阻的光纤的分析没有考虑这些路由器，也没有考虑数据包没有“直线”地在源和目的地之间传输的可能性。那么，通过此网络的总传播延迟等于每个子网上的传播时间之和，加上通过路由器所需的时间。

现代路由器（如 Cisco CRS-1）的平均延迟约为 100 微秒。² 我们的费城-帕洛阿尔托示例将在往返路径中包含大约 30 个路由器，使总路由器延迟约为 3 毫秒。其他延迟原因更难衡量。路由器尝试优化两点之间的路径，但这可能很困难，因此除了通过路由器的延迟之外，我们还可以预期由偏离直线的路径选择引起的某些延迟。其他可能的延迟来源包括较慢的路由器和其他中间设备（例如防火墙）、排队（等待访问繁忙的共享链路）、不良的路由选择和慢速链路。尽管如此，令人印象深刻的是，IP 路由基础设施仅比光纤中的光速“慢”大约两倍：88 毫秒对 38 毫秒。

铅笔和纸上计算的结果与实际测量结果之间的这种差异导致了系统吞吐量的定义，即在考虑所有实际限制（传播延迟、带宽、延迟和跃点）之后，您每秒可以发送多少比特。

进程间通信和协议

在分布式系统中，需要通信的进程通过一种或多种 IPC 方案进行通信。³ 示例方案包括消息、可靠流和远程过程调用。将 IPC 视为消息（有时称为 ADU（应用程序数据单元））是最容易的，因为它们是构建其他 IPC 机制（包括可靠字节流）的基础构建块。消息可能需要多个 IP 数据包。套接字 API 是访问消息和可靠字节流服务的一种方式的示例。它类似于输入/输出，支持读/写风格的接口。IPC 软件对单个消息延迟的影响通常很低；klondike.cis.upenn.edu 上本地环回接口的 ping 测量显示延迟时间约为 20 微秒。IPC 中传播延迟的最大原因是协议。

协议是用于通信的规则，旨在提供所需的属性，例如高应用程序吞吐量、可靠性或排序。可靠的消息传递是一个常见的应用程序要求，通常需要接收者向发送者确认，因此暗示了往返。需要比单个数据包更多数据的通信必须使用多个数据包，这意味着多个往返时间。要了解物理学对幼稚协议的影响，请想象一个 IPC 系统，该系统使用 10 Kbit 的数据包，并且必须在美国境内移动 100 Kbit（10 个数据包的数据），正如我们所见（对于单根洲际光纤），这应该需要大约 19 毫秒。如果仅在前一个数据包被确认后才发送新数据包，则每 38 毫秒发送一个数据包，并且通信将需要 380 毫秒，或几乎半秒，这与网络的带宽无关。然而，很明显，使用高吞吐量网络，可以连续发送所有 10 个数据包，并等待确认所有 10 个数据包都已到达，这可以在 38 毫秒内完成。

这个例子以及图 2 说明了通常所谓的带宽-延迟乘积，它是源和目的地之间路径容量的度量，单位为比特。图 2 显示，可能存在未使用的可用容量，此处由数据包之间的空间说明。如果网络被充分利用，那么所有容量都将被飞行中的数据包完全占用。当网络被数据包完全占用时，源和目的地之间将有带宽-延迟乘积的比特在飞行中。挑战在于估计任何给定时间的可用容量，因为网络动态可能会使此估计值高度可变。如果我们高估了容量，则会将过多的数据包推入网络，从而导致拥塞。如果我们低估了容量，则飞行中的数据包将太少，并且性能将受到影响。

优化协议以适应可用的带宽-延迟乘积一直是网络社区长期关注的问题，从而产生了许多用于流量控制和拥塞控制的算法。例如，TCP/IP 使用来自接收者的确认来调节发送者的速度，打开和关闭未确认数据包的窗口，该窗口是带宽-延迟乘积的度量。如果发生数据包丢失，TCP/IP 会假定它是拥塞并关闭窗口。否则，它会继续尝试打开窗口以发现新的带宽，因为它变得可用。

图 3 显示了 TCP/IP 如何尝试发现网络路径的正确窗口大小。该线表示可用的内容，重要的是，这会随着时间而变化，因为竞争连接来来往往，并且容量会随着路由更改而变化。当新的容量变得可用时，协议会尝试通过将更多的数据包推入网络直到丢失表明使用了过多的容量来发现它；在这种情况下，协议会快速减小窗口大小以保护网络免受过度使用。随着时间的推移，如图所示的“锯齿”产生，因为该算法尝试学习网络容量。

TCP/IP 的一个主要“物理学”挑战是它是在往返时间尺度上学习的，因此会受到距离的影响。一些基于路由器定期估计可用容量的新方法不受往返时间变化的影响，并且可能更适合在高带宽-延迟路径中实现高吞吐量。

对分布式系统的影响

许多现代分布式系统的构建方式就好像所有网络位置大致相同一样。正如我们所见，即使存在连接，延迟也可能比其他应用程序和协议影响更大。在请求/响应类型的 IPC 中，例如远程过程调用，数据的远程副本会大大延迟应用程序的执行，因为过程调用被阻塞等待响应。早期的 Web 应用程序速度很慢，因为原始 HTTP 为每个获取的对象打开一个新的 TCP/IP 连接，这意味着新连接对带宽-延迟的估计几乎总是低估的。较新的 HTTP 表现出对带宽-延迟估计的持久学习，并且性能更好。

对分布式系统的影响是，一种尺寸并不适合所有情况。例如，使用集中式数据存储将创建大量主机，如果这些主机远离数据存储，则不可能表现良好。在某些情况下，如果数据或服务的副本可行，则可以缓存数据并使其位于应用程序本地。例如，这是 Web 缓存系统的逻辑作用。然而，在其他情况下，例如证券交易所，数据是实时的，这种情况下的延迟特性具有重大的财务影响，因此缓存对于计算机化交易等应用程序无效。虽然原则上，可以构建考虑到这种延迟的分布式系统，但在实践中，已证明将处理移近市场更容易。

与物理学对抗的经验法则

以下是一些可能帮助软件开发人员适应物理定律的建议。

带宽有助于延迟，但无助于传播延迟。如果分布式应用程序可以移动更少、更大的消息，那么这可以帮助应用程序，因为总延迟成本会降低，因为引入的往返延迟更少。对于远距离和小数据对象，带宽的影响很快就会消失。对于越来越常见的无线链路，噪声也可能是一个大问题，在无线链路中，较短的数据包每个数据包的误码风险较低。应用程序软件设计师的教训是仔细考虑设计对延迟的假设。假设存在较大的延迟，使其在这种情况下工作，并在延迟较低时利用较低的延迟。例如，使用 Web 嵌入式缓存方案来确保应用程序在延迟较长时响应迅速，但在不必要时不进行缓存。

花费可用资源（例如吞吐量和存储容量）来节省宝贵的资源（例如响应时间）。这可能是这些规则中最重要的一条。一个例子是缓存的使用，包括数据的抢占式缓存。原则上，缓存可以复制到应用程序本地，从而导致存储和吞吐量（维护缓存）方面的一些成本。在实践中，当可以制作副本时，这几乎总是一个不错的选择，因为存储容量和网络吞吐量的增长似乎呈稳定的指数增长。用可能使用的数据预填充缓存意味着某些容量将被浪费（获取但不需要的内容），但当对需要的内容的预测良好时，某些延迟的影响将得到缓解。

坚持不懈地思考分布式应用程序的架构。一个关键的观察是，分布式系统可以基于功能进行分布。为了回到具有实时数据存储（例如股票市场）的系统设计，我们可以将股票的程序化交易放在相关的交易所附近，同时将用户交互功能、帐户管理、合规性日志记录等远程放置在不太靠近交易所的房地产中。这种功能分解练习的一部分是确定延迟在何处产生影响，以及在何处必须直接而不是通过缓存技术来解决延迟问题。

在可能的情况下，适应变化的延迟。通过适应带宽-延迟容量来最大化吞吐量的协议示例显示了如何适应广泛的延迟。对于分布式应用程序，这可以通过动态重定位系统的元素（例如，通过进程迁移或远程评估）来完成。

这些建议都无法让您克服物理学，尽管在最佳情况下预取可能会提供这种错觉。然而，通过仔细的设计，可以架构和实施响应迅速的分布式应用程序，以在长距离上运行。

总结

传播延迟是一个重要的物理限制。在系统设计随着应用程序架构的演进而发展时，这种度量标准通常被忽视，但与网络最常用的性能指标带宽相比，它可能对真实的分布式应用程序产生更大的性能影响。现代分布式应用程序需要遵守一些经验法则，以在广泛的传播延迟范围内保持其响应能力。
问

致谢

感谢编辑委员会（特别是 Eric Allman）和 Craig Partridge 的评论，他们极大地改进了本文。

参考文献

Mohr, P. J., Taylor, B. N. 2005. CODATA 推荐的基本物理常数值。《现代物理评论》77(1): 1-107。
40-gig 路由器测试结果。2004. Light Reading; http://www.lightreading.com/document.asp?doc_id=63606&page_number=4&image_number=9。
Partridge, C. 1994. 《千兆位网络》。Addison-Wesley Professional。
Shaffer, J. H., Smith, J. M. 1996. 带宽延迟权衡的新视角。宾夕法尼亚大学，CIS TR MS-CIS-96-10；http://repository.upenn.edu/cgi/viewcontent.cgi?article=1192&context=cis_reports。

喜欢还是讨厌？请告诉我们

[email protected]

JONATHAN M. SMITH 是 Olga 和 Alberico Pompa 工程与应用科学教授，以及宾夕法尼亚大学计算机与信息科学教授。他于 2004 年至 2006 年在 DARPA 担任项目经理，并于 2006 年被授予 OSD（国防部长办公室）杰出公共服务奖章。他是 IEEE 会士。他目前的研究兴趣范围从可编程网络基础设施和认知无线电到虚假信息理论和计算机增强免疫反应的架构。

最初发表于 Queue vol. 7, no. 3—
在数字图书馆中评论本文

更多相关文章

David Collier-Brown - 你对带宽一窍不通
当您的员工或客户说他们的互联网性能很差时，带宽可能不是问题。一旦他们拥有 50 到 100 Mbps 的范围，问题就是延迟，即 ISP 的路由器处理其流量所需的时间。如果您是一家 ISP，并且所有客户都讨厌您，请振作起来。这现在是一个可解决的问题，这要归功于一群专注的人，他们追捕它、消灭它，然后在家庭路由器中验证了他们的解决方案。

Geoffrey H. Cooper - 使用 FDO 和不受信任的安装程序模型的设备入职
设备的自动入职是处理正在安装的越来越多的“边缘”和 IoT 设备的重要技术。设备的入职与大多数设备管理功能不同，因为设备的信任从工厂和供应链转移到目标应用程序。为了加快自动入职的流程，供应链中的信任关系必须在设备中正式化，以允许自动化过渡。

Brian Eaton, Jeff Stewart, Jon Tedesco, N. Cihan Tas - 通过关键路径跟踪的分布式延迟分析
低延迟是许多 Google 应用程序（如搜索）的重要功能，延迟分析工具在维持大规模低延迟方面发挥着关键作用。对于复杂的分布式系统（包括不断发展功能和数据的服务），将总体延迟保持在最低水平是一项具有挑战性的任务。在大型、真实的分布式系统中，现有的工具（如 RPC 遥测、CPU 分析和分布式跟踪）对于理解整个系统的子组件很有价值，但在实践中不足以执行端到端延迟分析。

David Crawshaw - 一切 VPN 又焕然一新
VPN（虚拟专用网络）已有 24 年的历史。这个概念是为与我们今天所知的互联网完全不同的互联网而创建的。随着互联网的增长和变化，VPN 用户和应用程序也在增长和变化。VPN 在 2000 年代的互联网中经历了尴尬的青春期，与其他广泛流行的抽象概念交互不良。在过去的十年中，互联网再次发生了变化，这个新的互联网为 VPN 提供了新的用途。一种全新的协议 WireGuard 的开发提供了一种技术，可以在此基础上构建这些新的 VPN。