PDF你不懂网络性能
带宽只是问题的一部分。
KEVIN FALL，英特尔研究，STEVE MCCANNE，河床公司
为什么在局域网上运行良好的应用程序在广域网上会突然停止运行？当您尝试从远程文件共享打开文档或通过 VPN 远程登录到总部运行的应用程序时，您可能已经亲身经历过这种情况。为什么在您办公室运行良好的应用程序在广域网上会变得几乎毫无用处？如果您认为这仅仅是因为广域网带宽不足，那么你不懂网络性能。
考虑一下这个真实案例，一家大型银行总部位于欧洲，业务遍及北美。该银行的首席信息官受到了来自业务部门的巨大压力，欧洲用户试图从大西洋彼岸访问一个重要的应用程序。性能非常糟糕。在压力下，首席信息官命令他信任的网络运营经理解决这个问题。网络经理尽职尽责地进行了调查，测量了跨大西洋链路的利用率和路由器队列统计信息。他报告说网络绝对没有问题，因为网络利用率只有 3%。 “我不在乎，带宽翻倍！”首席信息官命令道。网络经理照做了，安装了第二条 OC-3 链路。结果，你猜怎么着？网络利用率从 3% 降至 1.5%，但应用程序性能仍然很糟糕。那位首席信息官不懂网络性能。
在这个例子中，而且也经常是这样，IT 经理将广域网上应用程序性能不佳归因于带宽不足，因为带宽通常等同于网络的“速度”。然而，虽然带宽在限制在固定时间内可以从一个地方移动到另一个地方的数据总量方面起着重要作用，但它只是影响应用程序性能的几个重要因素之一。其他关键因素——网络延迟、传输协议缓冲区管理、拥塞控制动态以及应用程序协议本身的设计——会对性能产生如此大的影响，以至于它们可以完全消除升级网络以获得更大带宽或“容量”的有用好处。
滑动窗口协议
为了理解为什么性能不仅仅是带宽问题，让我们首先分解一下底层传输协议的工作原理。您可能知道，互联网上的典型应用程序将以某种方式使用 TCP/IP 来移动数据。TCP 是一种高级形式的滑动窗口协议。它的工作原理是从发送者向接收者发送一个或多个信息包。当数据包成功传递后，接收者会向发送者发回一个回复 ACK（确认包），以表明它已成功接收到发送者发送的内容。在滑动窗口协议中，窗口大小是发送者允许在网络中“存在”但尚未收到确认的数据量。
鉴于互联网或企业广域网上的大多数数据传输都使用滑动窗口协议，我们如何推断此类传输的性能？假设数据包始终是固定大小 p 字节。我们可以用数据包的数量 k 来表示窗口大小。窗口大小 w 只是这两者的乘积：w=kp。现在，如果我们担心在一定时间内可以通过网络移动多少数据，我们真正担心的是在一定时间内可以移动多少个窗口。
因此，为了确定传输速率，我们需要计算数据窗口在网络中传输的速率——也就是说，我们需要了解移动 w 位数据所需的时间。这反过来又需要了解在发送者和接收者之间移动任何信息（甚至一位）所需的时间，这称为网络延迟或延迟。虽然延迟可以测量为单向（从源到目的地）或双向（从源到目的地再返回），但我们通常关心的是双向延迟。此值称为 RTT（往返时间）。请注意，RTT 可能会随时间变化，很少是单向延迟时间的两倍，但通常以此方式近似。
延迟来自几个不同的来源。首先是传播延迟，通常由自然规律控制。对于同轴电缆，比特的传播速度在光速的 60% 到 90% 之间，而对于射频和光纤，比特的传播速度实际上是光速。
延迟的另一个组成部分是传输延迟，它直接来自底层通信链路的带宽。例如，在每秒 100 字节的网络链路上发送 100 字节的数据包需要一秒钟才能将整个数据包注入网络。请注意，传输延迟只是数据包注入时间；它没有说明数据包到达目的地所需的额外时间。
延迟的最后一个组成部分是排队延迟，它表示数据包必须在保持区域（例如，路由器中的队列）中等待的时间，直到传输其他数据包，直到该数据包的第一位进入通信链路。在许多情况下，包括互联网，排队延迟不易测量且变化迅速。
RTT 是所有这些延迟分量的总和——传播延迟、排队延迟和传输延迟——对于发送者和接收者之间正向和反向路径上的每个通信链路。
现在我们了解了 RTT 的所有组成部分，我们可以看看它如何影响数据传输的性能。鉴于 TCP 在可能丢包的 IP 网络层之上提供可靠的通信，因此必须有一种方法可以从意外的数据包丢失中恢复。为了处理此类丢失，TCP 使用数据包重传，其中发送者重传在网络中丢失的数据包。为了实现重传，TCP 必须保留它已注入网络但尚不知道已被接收者正确接收的任何数据的副本。换句话说，TCP 必须缓冲窗口大小的数据副本（在我们的术语中为 w），直到它收到该数据的确认。因此，窗口大小永远不允许大于发送者可用的缓冲区空间（即内存）量。在实际系统中，通常为每个 TCP 连接保留一个固定的内存池（通常称为套接字缓冲区，应用程序可以修改该值）。
TCP 性能
考虑到重传窗口和 RTT 的概念，我们现在可以推断 TCP 滑动窗口通信方案的性能。假设发送者使用的窗口大小为 100 字节。因此，发送者能够将 100 字节注入网络，但随后必须等待直到收到该数据的相应 ACK。至少，发送者必须等待一个 RTT 才能发生这种情况，因为它不可能在消息到达目的地并返回的时间之前收到发往目的地的消息的 ACK。在那时，发送者可以向网络注入另外 100 字节。
这种行为如何转化为吞吐量？在稳态下，该方案每 RTT 时间移动 w 字节的信息，这在简单的数学术语中意味着吞吐量为 w / RTT。您可能还记得高中代数学中的函数 y=1/x 定义了一条双曲线，这意味着吞吐量随着 RTT 的增加呈双曲线衰减。换句话说，随着 RTT 变大，吞吐量会迅速下降。
那么，为什么不通过增加数据包大小 (p) 或数据包数量 (k) 将窗口大小 (w) 设置为相应更大的值，以实现更好的吞吐量呢？协议设计者很久以前就解决了这个问题，并得出结论，实际上，对于给定的网络环境，存在一个“最佳”窗口大小，可以最大化网络吞吐量。事实证明，最佳窗口大小是使发送者完全“填满管道”的窗口大小。如果我们把发送者和接收者之间的路径想象成一条管道，我们想通过取它的“宽度”（它的吞吐量，实际上更像是它的横截面积，以比特/秒为单位）乘以它的“长度”（单向延迟，以秒为单位）来计算它的体积。这将产生 BDP（带宽延迟乘积），以比特为单位进行测量。换句话说，管道大小表示物理上“在线”发送者和接收者之间传输的比特数。
最佳窗口大小允许发送者持续发送，从而使网络繁忙且充满，始终携带数据（因此，永远不会空闲和浪费时间）。事实证明，这是一个充满比特的正向管道，然后是另一个充满管道，等待窗口中第一个数据包的 ACK 返回。一旦第一个 ACK 到达，发送者就会向前滑动其窗口，因此可以发送另一个数据包。如果窗口足够大，ACK 将继续及时返回到发送者，以便持续发送正确数量的数据包以维持最佳吞吐量。您可以将此视为数据包在满载的传送带顶部移动，而 ACK 在底部返回。
因此，实现最佳吞吐量仅需要发送者将其窗口设置为 RTT 乘以网络带宽。这应该很容易，对吧？不幸的是，发送者经常最终使用次优窗口的原因有很多。例如，如前所述，发送者的缓冲区可能小于此最佳大小，从而施加操作限制。
次优窗口的另一个原因是发送者可能对自己施加拥塞控制。这是 TCP 中一个长期存在的研究领域，并且定期出现新方法。可以说，拥塞控制程序是一种算法，它将 TCP 窗口大小（通过减小我们方程中的 k）限制为小于它原本会使用的值，以避免网络过载或拥塞。当网络变得过载并丢弃数据包时，TCP 会响应地减小其窗口大小，从而有效降低其总体发送速率。对于数据包丢失是拥塞强烈指标的网络，此过程效果良好，并使每个发送者调整其窗口，使其获得网络带宽的某些份额。对于其他网络（例如，无线或卫星），其中丢失可能是数据损坏而不是拥塞的结果，此技术可能会人为地限制 TCP 的吞吐量。这个问题也一直是人们强烈关注的研究领域。
接收端可能会出现另一个潜在的瓶颈。即使发送者能够使用最佳窗口大小，接收者也可能没有足够的内存来一次性保存和处理所有这些数据。为了处理这个流量控制问题，TCP 在每个数据包中都包含一个名为窗口通告的值，该值本质上向发送者发出信号，表明接收者愿意接受多少额外数据。如果接收者的缓冲区已满或太小，则接收者会将窗口通告中发信号的值减小到可管理级别。此值最终可能小于最佳窗口大小，从而降低性能。
此外，原始 TCP 设计的一个特点可能会导致通告窗口小于所需窗口。由于 TCP 标头中的窗口通告字段仅分配了 16 位，因此最大可能的窗口被限制为 65,535 字节，这严重损害了所谓的“大型、胖网络”（那些具有大带宽延迟乘积的网络）的性能。幸运的是，在 1992 年，RFC 1323 以一种有趣的方式解决了这个问题。该技术涉及通过将 TCP 标头中携带的窗口值乘以 2n（对于某个值 n，称为窗口比例）来缩放窗口值。n 的值在连接建立时在两个 TCP 端点之间交换。由于 n 允许的最大值为 14，因此使用窗口缩放时 TCP 可以表示的最大窗口为 230 字节（1 GB），远大于原始的 65,535 字节最大值。此功能通常称为具有“大窗口”的 TCP，现在由现代 TCP 实现自动协商。
应用程序性能
到目前为止讨论的所有窗口大小限制都是终端系统中实现的传输协议的结果。当我们查看应用程序性能时，会出现更多问题。例如，虽然应用程序通常可以自由选择发送和接收缓冲区大小，但它们通常不会这样做，而只是依赖操作系统提供的默认大小。“旋钮”控制缓冲区大小通常隐藏在应用程序程序员无法控制的软件或中间件层之后。即使应用程序有意配置缓冲区，程序员也必须选择一些先验值，但是最佳大小在开发时是无法知道的，因为通过不同网络路径通信的不同终端主机都需要不同的最佳值。此外，关于应用程序设置这些缓冲区大小的时间和方式与其他连接设置功能相比的深奥细节可能会导致大窗口协商以程序员可能无法察觉的微妙方式失败。最后，根据特定应用程序，使缓冲区不必要地大可能会增加整体端到端延迟并损害应用程序性能，而不是帮助应用程序性能。这样做还会增加繁忙服务器上的内存压力，从而阻止应用程序程序员使用如此大的缓冲区。
即使所有缓冲区都设置为最佳状态，当网络带宽充足，并且 TCP 拥塞控制完美运行时，广域网上的应用程序性能仍然可能因应用程序协议本身而受到严重影响。每个基于 TCP 的应用程序都必须在可靠的 TCP 连接之上实现某种形式的更高级别消息传递协议。想象一下，当这样的应用程序协议停止在网络上提供数据以进行传输时，TCP 会如何工作。自然，TCP 本身会停止发送。
尽管 TCP 具有各种技术和选项来克服窗口限制，但它无力克服应用程序中的类似问题。如果应用程序的协议涉及请求和响应，并且如果它未能实现任何“保持网络满载”（例如，通过允许多个未完成的请求）的方式，则可能会被驱动到一种只能处理每个 RTT 一个请求的条件。这种“喋喋不休”的应用程序行为会导致终端主机之间许多低效的来回交换，并导致性能随着 RTT 的增加呈双曲线下降，就像滑动窗口协议的吞吐量一样。对于被迫使用从未为大 RTT 或更普遍的大 BDP 环境设计的应用程序的用户来说，这确实可能是一个严重的后果。
很容易看出这些应用程序是如何变得司空见惯的。简而言之，很难构建一个在局域网上运行不佳的应用程序协议。考虑一个基于 100-Mbps 以太网的局域网。局域网通常仅跨越有限的区域，并且总体延迟有限。假设以太网网络上的 RTT 为 0.1 毫秒（0.0001 秒）。则 BDP 约为 0.01 MB = 1.3 KB。对于 1,500 字节的以太网数据包，1.3 KB 大约代表一个数据包。它可以轻松地由 TCP 表示，而无需窗口缩放，并且几乎肯定可以通过默认缓冲区大小分配充分提供。事实上，由于对于这个小 RTT，最佳窗口大小仅约为一个数据包，因此即使是设计不佳的应用程序也可能表现良好。这类应用程序在某些方面是最令人担忧的，因为当从局域网移动到 RTT 较大的广域网时，它们的性能会明显下降。
局域网与广域网
如果我们将局域网场景与高速广域网场景进行比较，情况看起来有些不同。假设现在的 RTT 为 80 毫秒，带宽为 1 Gbps，则我们的 BDP 约为 10 MB。使用以太网 1,500 字节数据包帧，大约是 7,100 个数据包。在这种情况下，除非在每一层（从应用程序到传输层）都采取措施来确保充分利用网络的吞吐量容量，否则充分利用网络可能具有挑战性。
您可以使用 Ethereal 或您喜欢的抓包和分析工具来检查所有这些概念。将其设置为查找 TCP 端口 445 上的流量，这允许您观看 Windows 文件共享协议的运行情况。然后，执行一些简单的操作，例如使用 Microsoft Word 从网络文件共享中打开文档。返回 Ethereal，它将解码文件系统协议命令，并查看跟踪。您可能会惊讶地看到：Word 应用程序和文件服务器之间来回发送了数百甚至数千条命令，只是为了打开和加载文件。根据文档的不同，您可能会看到 Word 多次打开和关闭文档，以非顺序方式读取文件的不同部分，多次读取相同的数据，将数据复制到临时文件，多次检索有关文件和目录的相同元信息，等等。
每个操作都是按顺序执行的，需要在网络上往返一次。在您的局域网上，这没什么大不了的：1,000 次往返乘以每次往返 0.1 毫秒是十分之一秒。但是，在 80 毫秒的广域网链路上，1,000 次往返超过一分钟。即使您将广域网电路升级到 45-Mbps DS3 或 155-Mbps OC-3，打开该文档仍然需要一分钟以上。
如果您只能从本文中带走一个概念，请记住网络性能不仅仅是带宽。开发具有良好吞吐量性能的应用程序这个看似简单的问题可能并非如此简单。糟糕的性能会因许多不同的原因悄然而至：物理因素（RTT、数据包丢失）、传输协议因素（有限的缓冲区、编码大窗口的能力有限、接收应用程序运行速率有限）和应用层协议动态。传输层或应用层的糟糕实现很容易导致性能不佳。更让我们沮丧的是，整个系统可能在局域网环境中运行良好，但在广域网或其他高延迟环境中却慢得令人难以忍受。
本文旨在帮助阐明这些有时很复杂的交互，以便最终用户可以从应用程序和中间件软件开发人员对这些问题的更深入理解中受益。如果有什么的话，您现在可以说您确实了解网络性能。
KEVIN FALL 曾在加利福尼亚大学圣地亚哥分校、伯克利分校和圣克鲁斯分校、麻省理工学院和劳伦斯伯克利国家实验室担任过许多网络研究和教学职位。他是 NetBoost Corporation（现为英特尔公司）的联合创始人。自 2000 年以来，他领导了英特尔的延迟容忍网络 (DTN) 研究工作，并担任互联网研究任务组（互联网工程任务组的配套组织）延迟容忍网络研究组 (DTNRG) 的主席。作为 DTNRG 的主席，他参与了 DARPA 的中断容忍网络计划的制定。他获得了加利福尼亚大学伯克利分校的计算机科学学士学位，以及加州大学圣地亚哥分校的计算机科学硕士和博士学位。
STEVE McCANNE 于 2002 年共同创立了 Riverbed Technology，并担任其 CTO。在 Riverbed 之前，他共同创立了 FastForward Networks，后来将其出售给了 Inktomi Corporation。在开始他的商业生涯之前，McCanne 曾在加利福尼亚大学伯克利分校的电气工程和计算机科学系任教，在那里他教授和研究互联网协议和系统。他因其在加州大学伯克利分校关于分层多播视频压缩和传输的博士学位工作而获得了 1997 年 博士论文奖。2002 年，麻省理工学院的《技术评论》杂志将他评为互联网相关贡献的 100 位顶尖年轻技术创新者之一。从 1988 年到 1996 年，他是劳伦斯伯克利国家实验室网络研究小组的成员，在那里他开发了许多广泛使用的技术。这项工作包括协议开发，现在构成了当今流媒体互联网标准的基础。
最初发表于 Queue vol. 3, no. 4—
在 数字图书馆 中评论本文
更多相关文章
David Collier-Brown - 你不懂带宽
当您的员工或客户说他们的互联网性能很差时，带宽可能不是问题。一旦他们拥有 50 到 100 Mbps 范围内的带宽，问题就是延迟，即 ISP 的路由器处理他们的流量需要多长时间。如果您是 ISP 并且所有客户都讨厌您，请振作起来。这现在是一个可以解决的问题，这要归功于一群执着的人，他们追踪到了这个问题，解决了它，然后在家庭路由器中验证了他们的解决方案。
Geoffrey H. Cooper - 使用 FDO 和不受信任的安装程序模型进行设备入职
设备的自动入职是处理正在安装的越来越多的“边缘”和物联网设备的重要技术。设备的入职与大多数设备管理功能不同，因为设备的信任从工厂和供应链过渡到目标应用程序。为了通过自动入职加快流程，必须在设备中形式化供应链中的信任关系，以允许自动化过渡。
Brian Eaton, Jeff Stewart, Jon Tedesco, N. Cihan Tas - 通过关键路径跟踪进行分布式延迟分析
低延迟是许多 Google 应用程序（如搜索）的重要功能，延迟分析工具在维持大规模低延迟方面起着关键作用。对于包括不断发展功能和数据的服务在内的复杂分布式系统，将总体延迟保持在最低水平是一项具有挑战性的任务。在大型真实世界的分布式系统中，现有的工具（如 RPC 遥测、CPU 分析和分布式跟踪）对于理解整个系统的子组件很有价值，但在实践中不足以执行端到端延迟分析。
David Crawshaw - 一切 VPN 都焕然一新
VPN（虚拟专用网络）已经有 24 年的历史了。这个概念是为与我们今天所知的互联网截然不同的互联网而创建的。随着互联网的增长和变化，VPN 用户和应用程序也随之增长和变化。VPN 在 2000 年代的互联网中度过了尴尬的青春期，与其他广泛流行的抽象概念交互不良。在过去的十年中，互联网再次发生了变化，这个新的互联网为 VPN 提供了新的用途。一种全新的协议 WireGuard 的开发为构建这些新的 VPN 提供了技术基础。
© 保留所有权利。