其实你不知道什么是网络性能

2017 年 7 月 20 日 Python程序员

Python部落(python.freelycode.com)组织翻译，禁止转载，欢迎转发。

带宽只是问题的一部分

为何一个在局域网上运行良好的应用程序在广域网中陷入瘫痪状态？当你试图从远程文件共享中打开文档或通过VPN远程登录到总部运行的应用程序时，你可能已经亲身体验到了这一点。为什么一个在你的办公室里运行良好的应用程序在广域网上几乎毫无用处？如果你认为这仅仅是因为广域网没有足够的带宽，那么你是就不了解什么是网络性能了。

思考一下如果这家总部设在欧洲的大型银行，但是他们业务在北美洲的场景。这家银行的首席信息官从业务部门得知了一个一流热点事件，同时欧洲的用户正跨越大西洋尝试访问一个重要的应用程序。性能非常差劲。在压力之下，首席信息官指示他信任的网络管理员师来解决这个问题。网络管理员负责地调查，测量跨大西洋链路利用率和路由器队列统计数据。他报告说，网络绝对没有问题，因为只有3%的网络被利用。但首席信息官命令道，我不管，拓宽带宽到两倍，网络管理员照做了，又安装了一个OC-3链接。然后，猜猜怎么样了，网络利用度变成了1.5%，但是程序的性能依旧很差。那个首席信息官并不知道网络性能是什么。

在这个经常可能发生的案例中，信息技术经理们将广域网差的程序性能归因于带宽不足，因为他们通常认为带宽等同于网速。但是，即便带宽在对整体数据最大量的限制上起到重要的作用，这些数据在指定时间内从一个地方转移到另一个地方，但它仅仅是几个影响程序性能因素中的一个。其他关键的因素有网络延迟、传输协议缓冲区管理、拥塞控制动态以及应用程序协议本身的设计，这些因素都非常影响性能以至于它们可以完全消除通过提升带宽或者“性能”来升级网络带来的有益影响。

滑动窗口协议

为了理解为什么性能不仅仅是带宽的问题，让我们从分解传输协议的底层工作原理开始。你可能知道，一个典型的网络应用程序会使用TCP/IP协议来传递数据。TCP是一种先进的滑动窗口协议。发射端传送一个或者多个信息包给接收端，它通过这种方式工作。当包成功发送并到达后，接收端会发送一个回复确认包回来发送端来表明它已经成功收到发送端发送的消息。在滑动窗口协议中，窗口大小指的是在没有接收到确认包之前发送端所允许在网络中拥有的数据量。

考虑到大多数数据通过因特网或者公司广域网通过滑动窗口协议进行传输，那我们能对这种传输的表现有什么思考呢？假设包始终是固定大小的，含p级字节。我们可以用包的数量k来表示窗口的尺寸。窗口的尺寸w，就是简单的k与p的乘积。现在，如果我们关心我们在某一时间段内可以通过网络传递多少的信息，那么我们实际关心的就是在一段时间内窗口滑动的距离。

因此，为了确定传输率，我们需要计算那个窗口数据在网络中传输的比率，那是什么意思呢，就是我们需要理解传输w比特数据需要花费多少时间。这相应的需要知道在发送端和接收端之间传输信息的时间，这也被叫做网络延迟或者延期。尽管延迟可以被测量为单向（源到目的地）或者双向（源到目的地并返回）但是我们通常关心的是双向延迟。这个值被称作RTT（往返时延）。注意这个RTT一直随时间变换，它很少时间是单向延迟的两倍，但是通常上与那样测量相近。

延迟从几个不同的源中产生。首先，存在传播时延，由自然因素控制。对于同轴电缆，比特信息以60%到90%的光速传播，而对于射频和光，它们实际上以光速传播。

另一个影响延迟的因素是发送时延，它源于底层通信链的带宽。比如，通过一个100比特每秒的网络链发送一个100比特的包需要1秒将完整的包注入网络。注意发送时延仅仅是注入包所需的时间，但它没有说包到达目的地的额外时间。

延迟的最后一个组成部分是队列延迟，它表示一个包必须在等待区域（例如路由器中的队列）中等待的时间，而同时其他数据包被发送，直到该数据包的第一位到达通信链路。在许多情况下，包括互联网，排队延迟不容易测量并会迅速变化。

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位，可能的最大窗口被限制在65535比特中，对所谓的“大而胖的网络”（那些有大带宽延迟产品）的性能有显著的损害。幸运的是，在1992年，这个问题通过RFC1323以有趣的方式得到了提出和解决。该技术包括将TCP报头中的窗口值乘以2n，其中n是被称为窗口规模的一个新变量。在连接建立时间内，两个TCP端点之间的n值被交换。当n允许的最大值为14时，TCP在窗口缩放时所能代表的最大窗口是230bytes（1 GB），比原来的65535字节大很多。这种功能通常称为有“大窗口”的TCP，现在由现代TCP自动协商实现。

程序性能

到目前为止，已经讨论过的所有关于窗口大小的限制都是在终端系统中传输协议实现的结果。当我们查看应用程序性能时，会出现更多问题。例如，虽然应用程序通常可以自由选择发送和接收缓冲区大小，但它们通常不简单地依赖于操作系统提供的默认值大小。控制缓冲区大小的“旋钮”通常隐藏在应用程序开发人员无法控制的软件或中间件层的后面。即使应用程序有意配置缓冲区，程序员也必须选择一些先验值，但在开发时不能知道最佳大小，因为不同的终端主机在不同的网络路径上进行通信，每个都需要一个不同的最优值。此外，关于应用程序如何以及何时设置这些缓冲区大小与其他连接设置功能的深奥细节可能会导致大窗口协商以程序员可能无法察觉的细微方式失败。最后，针对特定的应用程序，使缓冲区不必要的加大大，会增加程序整体的端到端延迟和伤害，这对应用程序的性能并非帮助。这样做也会增加繁忙服务器上的内存压力，所以不应鼓励应用程序程序员使用如此大的缓冲区。

即使所有的缓冲区都是最佳设置，当网络有足够的带宽，TCP拥塞控制是完美工作的，应用程序大面积的应用性能仍会明显因为应用程序协议本身受损。每个基于TCP的应用程序必须通过在可靠的TCP连接之上一些高级消息传递协议形式来实现。想象一下，当这种应用程序协议停止为网络上的传输提供数据时，TCP是如何运行的。当然，TCP本身停止发送。

尽管TCP具有克服窗口限制的各种技术和选择，但它在应用程序中无法克服类似的问题。如果一个应用程序的协议涉及的请求和响应，并且如果不实施任何方式的“保持网络充满状态”（例如，允许多个未完成的请求存在），它可以被转化为一种情况，这种情况下一个RTT的时间中它只能处理一个请求。这种“闲聊式”的应用程序行为会导致主机之间许多低效的来回交流，也导致了性能随着RTT增加像双曲线一样减少，就像一个滑动窗口协议的流率。这是一个严重的后果，确实，用户被迫使用不是为大RTT设计的应用程序，或者更普遍的，为大带宽环境设计的程序。

很容易看出这些应用程序是如何变成通用的东西。简而言之，很难构建一个在局域网上不好用的的应用程序协议。想想基于100 Mbps以太网的局域网。局域网一般只在有限的范围内运行，并引起有限的总延迟。假设在一个以太网的往返时延是0.1毫秒（0.0001秒）。BDP有大约0.01 MB = 1.3 KB。对于1500字节的以太网包，1.3 KB表示大约一个包。它不用窗口缩放，很容易用TCP来表示，而且几乎可以肯定它为默认缓冲区大小分配提供了充分的支持。事实上，因为最佳窗口的大小对于小的RTT而言只有一包大小，所以即便应用程序设计的不好，他还是能工作得很流畅。这种类型的应用程序在某些方面是最麻烦的，因为当他们从局域网到广域网，RTT变大时，性能会显著恶化。

局域网 vs 广域网

如果我们将局域网方案与高速WAN方案进行比较，情况看起来有些不同。假设现在是80毫秒RTT、带宽1 Gbps，我们有一个BDP约10 MB。用1500字节的以太网包架构，大约有7100包。在这种情况下，除非在每个层（通过传输应用程序）采取谨慎措施，以确保充分利用网络的传输能力，否则，想要充分利用网络可能是具有挑战性的。

您可以使用以太网或者您最喜爱的包抓取分析工具来检查这些概念。设置它来查找TCP端口445上的流量，它允许您在操作中观看Windows文件共享协议。然后做一些简单的事情，就像用微软Word软件从网络文件共享中打开文档。返回以太网，它将解码文件系统协议命令，并查看踪迹。您所看到的可能会使您感到惊讶：在Word应用程序和文件服务器之间来回运行的数百个命令，如果不是数千个的话，然后只需要打开并加载文件。根据该文件，你会看到Word打开和关闭几次，以不连续的顺序读取文件的不同部分，读取相同的数据超过一次，将数据复制到一个临时文件，多次检索相同文件的元信息和目录等等。

每一个操作中都连续执行，它们需要在网络上来回往返。在局域网上这没什么大不了的：每次往返1000次，每次0.1次，是十秒。然而，在80毫秒的广域网线路上，1000次往返超过一分钟。即使你升级广域网线路到45 Mbps的DS3或155 Mbps 的OC-3，它仍需要超过一分钟的时间去打开文件。

如果你从本文中只取出一个概念，请记住网络性能而不是带宽。毕竟开发具有良好流量性能的应用程序看似简单但并不简单。出现不好的表现有许多不同的原因：物理因素（RTT，包的丢失）、传输协议（有限的缓冲能力、有限编码大窗口的能力，有限的接收应用程序运行速度）和应用层协议的动态。传输层或应用层执行得不够好，很容易导致性能不佳。进一步挫败我们的是，整个系统可能出现在局域网环境中运行的很好，但是在广域网或其他高延迟环境中出现让人难以忍受的慢速的情况。

本文旨在帮助人们弄清楚这些有时复杂的交互，以便终端用户能够从应用程序和中间件软件开发人员对这些问题的深入理解中获益。如果有的话，你现在可以说你知道什么是网络性能了。