现实网络世界 多少带宽才会够用

申请免费试用、咨询电话：400-8352-114

“带宽”对于网络管理人员、建筑师和技术人员来说是毫无意义的一个术语，相反，他们使用“数据传输率”、“连接性能”或者甚至“网速”来简单地代替这个术语，这就说明了一个问题，我们对网络有点无知，至少对在OSI模式的7个层次中的第1层是比较无知的。许多人可能使用“带宽”来表示比特每秒，但是这样做就反映了对信号理论和基本物理通信的无知。下面所回顾的术语显示了即使是它们的物理特性也是不一样的。

带宽：以赫兹（Hz）作为测量单位——一个信号或一个传输信号的频道的频谱宽（以往表示为：周期每秒）。

数据传输率：以比特每秒为测量单位（或者可能是兆每两周）。

“带宽”往往被草率地应用于错误的上下文中，或者被用于一些看起来挺怪异的场景中。这是相当糟糕的，因为网络新手们很容易被误导而非受到正确教育。这里有一个适当的解释。在Claude Shannon工作中：“带宽”就如同农田。对这块农田的开垦方式将收获一个特定的数据传输率。

许多前辈，如Dennis Hayes，花费了大量的精力，致力于通过调制解调器实现Shannon的假定的权限（香农极限）来将未经处理的带宽转换为位/秒。他们使用了灵活、明智的信号符号（FSK、SQPSK…）选择——这样就能从任意指定的频道带宽中获取非常好的数据传输率。

一些欧洲国家已经定义的编码与香农极限（Shannon Limit）非常接近。但是，并没有任何情况显示带宽与数据传输率是一样的。相反，它是通过一个精心挑选的传输符号来要求智能开发的机会——甚至Napoleon网络的设计者早在200年前就知道了这个方法：他建立一个跨越欧洲的光纤网络以实现在15分钟之内能将国王命令发回巴黎的通信时，这是使用一个20位符号的代码实现的。瑞典人也在200年前拥有了他们自己的521位符号光纤网络。而当计划与Voyagers通话时，NASA肯定是知道这个的。

那么在网络节点Y和Z之间到底需要多少“X”每秒的速度呢？这要依据具体情况而定的。

网络管理人员、工程师或技术人员最为关注的可能是他们从老板、主管部门、商业伙伴以及最后从用户那听到的投诉。每个网络管理人员都知道“一对一的抱怨”的呼叫：“速度太慢了！我无法连接到服务器ABC!系统Q把我踢掉了！打印机也很慢！今天的网络真是慢！”

哪些问题与网络建筑师、管理人员或技术人员能够改正的参数有关呢？这些都是跟实际情况相关的，能让系统和用户完成工作的是吞吐量，也就是按顺序从发送者到接收者发送的良好的数据位/字节的完整数量。

多少吞吐量才够呢？

那么，我们真正关心的问题是：多少吞吐量才够的呢？在OSI模式的每一层，吞吐量问题都是应用设计师必须指定、架构师必须设置、管理人员必须维护，以及技术人员必须测量和修复的。事实上这也是系统和用户每时每刻都在经历的事情。

延迟和连接是两个关键的可测量网络属性，它们对吞吐量的影响正是服务的系统或用户所体验的。延迟表示请求的响应所耗费的时间长度，而连接则可以简单地认为是一个节点到另一个的可见性。这些都直接地影响着网络的“性能”，而且现实情况是，物理性网络并非总是造成网络性能低下的根源。问题根源可能是一个不正确建造的数据库或一个配置不当的服务器、应用、路由器或防火墙。甚至还可能是节点、客户端或服务器中的配置不当的数据传输协议。这里只是概括了网络故障修复的难题，而这些问题在目前复杂的互联系统和应用中变得更加严重。

如果网络架构得当，那么技术人员对诸如链接数据传输速率、服务器处理器或内存、数据库分区等参数的调整是可以改善性能的。而其中的大多数都应该由用户主动地使用良好的网络/系统管理工具运行网络来实现。

现实世界的网络

不幸的是，在其它的现实网络参数中有着更多潜在的影响是上述调整所无法改善的。了解这些问题，既是科学的一部分也是艺术的一部分。其中有两个一样重要和关键的参数影响了在任意路径进行互换的网络吞吐量，即便终端系统是完美的：

A.往返延时（往返时间或者TCP语法中的RTT）

B.数据传输率限制

由于传输协议（如，TCP）存在错误恢复的限制，因此第一个参数的重要性与日俱增。而随着传输数据的增加，第二个参数也越来越重要。两者都与传输协议的行为互相作用。虽然往返延时似乎是直观的，但是它与网络路径和协议参数之间的关系却往往被漏掉。因此，我们必须了解哪些网络协议参数可能与网络路径本身的属性相互作用。

C.发送者的传输窗口（未确认数据，第4层及以上）

D.发送者和接收者最大传送单元（或“最大传输单元”——MTU，帧大小）

E.发送者的传输（第4层）超时时间和重传策略

F.接收者的窗口（包缓冲大小）

G.接收者的确认（ACK）策略（第4层及以上）

H.误差检查/纠正

I.路径拥塞通知，如果有（第2层和更高层的）

J.资源负荷

这些是主要的协议栈参数和相关算法，它们允许在现实的、不完善的网络路径和终端性能中实现吞吐量最大化。但是，这并不意味着吞吐量将达到理想的最大化，而只是表示在一个指定的现实路径，协议性能能够调整（第1层和更高层）到对于该协议/路径组合的最佳吞吐量——选择一个不同的协议或路径可能会很好地提高总体吞吐量。这就是网络架构师必须具备经验和知识以更好地设计的原因，同时也是网络管理人员和技术人员必须精通性能测试和计算的原因。

下面这个统计图表示在一条现实网络路径中发送成千上万的实际网络数据包以满足一个用TCP/IP进行简单但大型的文件传输请求：

左上角显示传输1.5MB的流量花费了大约35秒时间，因此吞吐量是8 * 1500000 / 35 = 343 KBps，是一个典型的小T1连接速度，如ADSL上传。但是——右下角显示许多中转包延时仅是8毫秒（MSEC），同时左下角显示所有的数据包是1518字节——以太网的传统MTU。这两个事实意味着1518字节有时候可以每8毫秒，或者说满T1（1.5MBps）传送。显然，在限制数据传输率（良好的）和实际吞吐量（不太好的）之间存在着差距。

每个数据包的协议开销是18B + 20B + 20B （Ethernet + IP + TCP），因此传输每个数据包会折损掉1518 - 58 = 1460字节有效负载，而实现的最高的速度为8 * 1460 / .008 = 1.46Mbps：接近于T1，但是与观察到的平均速度35秒有着很大的差距。这是怎么回事呢？我们的突发吞吐量接近于T1，但是我们所维持的平均吞吐量则还不到四分之一。

右边的象限显示了更多关于路径的问题：

1.接收节点的确认时间分布很广泛，但是大多数速度都非常快（大约200毫秒）——协议栈基本上都很快

2.一些ACK时间非常长（延时ACK>100毫秒）——是什么原因呢？

3.经常出现限制速率，但是更多的是，在右下角显示一个相邻包的广泛传播时间，即中转到达时间——为什么？

网络如何拥堵&延迟确认字符（ACK）对网络性能的影响

多种原因产生的多种结果

我们所看到的是多因素导致的多效性，这存在于典型的现实网络。很明显，“多少（限制的）数据传输率才足够呢？”是一种误导——具体问题要具体分析。如果我们的网络总能保持1.5MB的传输带宽，那么我们的等待时间是8秒而非35秒。但是，显然，它并不总是这么大的，如右下角的测量结果。

原因1：网络路径拥塞。我们将路径的T1部分共享给其它的流量，而且在此处的路由器/网桥会进行缓冲并延迟我们的数据包，有时候延迟会超过100毫秒。而且这种延时是非常多变的，因为相对应的流量本身是可变的。显然，统计分析是在这些情况下进行性能评估的唯一方法。

原因2：这是一个较简单的问题——右上象限的延迟ACK。它们总和仅大于100毫秒。这是一个协议问题，是出现在接收者的TCP-栈参数设置的问题，但是这也与发送者发送TCP数据包的方式相关。这听起来有点复杂，但实际上这是由于TCP是很老的协议，它仍带有当初为低速网络设计的特性，那时消除“不必要”的数据包被认为是很有用的。

因此，TCP仍然允许接收者只对每一个后续的数据包发送ACK（右上象限的点数量大约只有左上象限的一半）。当然，接收到第N个数据包并不表示第N+1个也会出现，因此如果第N个没有ACK，那么发送者将无法知道接收者是否收到了所有的数据。TCP中的解决方案（或kludge）是让接收者在接收到每一个（如，奇数）没有马上ACK的数据包时开启一个计时器。如果第N+1个数据包到达了，那么计时器就停止。如果计时器过期了，那么接收者将为最后一个接收的数据包发送一个ACK。

我们应该给这个延时的ACK计时器参数赋一个什么值呢？其实，我们并不想让发送者花费太长的时间等待延时ACK，因为这可能会导致它超时并转到重发模式，这样就会真正导致速度变慢。默认的TCP参数值通常是100-150毫秒，并且不幸的是网络技术人员往往无法达到这样的要求。事情就这样结束了吗？不，增加的延时来源可能不被认同，因为发送者的传输窗口可以设置为不发送一个奇数的数据包——通常参数都是可以调整的（后面会出现更多的类似情形）。

原因3的影响并不明显，如右上象限所显示：从200微秒到100毫秒的ACK延时的范围。我们知道上下边界不是网络产生的，而是它们范围内的是又只是ACK路径拥塞。这些延时与原因2有着相似的效果，但是因为ACK通常是小的数据包，而且在TCP中发送频率只有数据发送一半，所以这些延时的效果是明显的但并不算太糟糕。

这些单个延时因素一起导致产生变化的性能，这样的性能只能进行统计性建模和估算。我们从上面的数据可以看到最大的延时是由于一个运行T1线路的特定的路由器/网桥的拥塞。如果路由器/网桥可以更快地操作，那么这条链路就够用了，我们并不需要更多的数据传输率。但是如果不能，我们就需要一个更好的或者升级的路由器/网桥。

（NetCalibrator和NetPredictor）根据实际的网络数据包生成的……如果对这里所述的各项原则已经了解，并且可以在路径上捕获数据，那么诸如这样的复杂工具并不总是需要的。

注意，分配到网络路径（从Percheron 到AFS08）上每个组件的数轴顶部曲线条反映了测量中必然的统计分布——不幸的是，正如我们现在知道的，这个工具的输出显示误用了“带宽”！同样需要注意的是，这个网络图和组件属性（速度，等等）允许我们用一个关键点的测量数据来估算所有的上述信息，如终端节点。我们所需要的是在任何路径上找到延时来源，正是它们导致吞吐量损失的。

在这个例子中，网络路径是好的——我们知道这并不是网络的原因。

NASA空间探测器、吞吐量&错误误差率

NASA空间探测器与吞吐量

在我们更详细地探讨参数是如何影响吞吐量之前，让我们先来考虑一个极端的例子：NASA必须与空间探测器和登陆车进行通信。在太空飞行时，详细的无线命令-响应事件和计算模型可以提供精确的航空器跟踪定位。

但是，只有在我们理解了万有引力、行星轨道和磁场以及其它影响，并且在这些知识的基础上进行预测，我们才能获得这个精确性。我们并不知道航天器在T时刻的所在位置，我们只能推测出T-t时刻它所在的位置以及状态，这个时间是它向我们发出响应的时刻。历史数据，外加一个模型的输出，这就是我们“现在”所谈论的航天器所在的位置。对于火星航天器，t值大约是三分钟：命令-响应信号事件的RTT的一半。而对于木星，t值可能接近一个小时。

这样也就不奇怪NASA登陆车没有使用类似于视频游戏的显示和操纵杆来驾驶了。NASA工程师必须制造一个精确的模型，它使机器人才可以执行他们发送的任何命令，同时他们还必须在同一时间将许多命令集合起来一起发出，这样机器人才可以在我们的期限中准确地完成任务。有一些发往火星的命令在过了6分钟之后可能就“OK”了，但是毫无疑问Titan上的命令返回确认需要2个小时的等待就不可行了。在这个极端的命令-响应延迟环境中的关键是远距离智能（如，导航），以及命令序列缓冲和我们终端上的远距离建模。对这种情况的明智设计意味着我们将仍然必须等待，看机器人是否已经到达岩石X并采取了该岩石的表层样本，但是我们将不必发送更多的命令包脉冲来在一个RTT内获取到结果。

对于地球环境，我们最大的物理性延迟就是地球同步卫星连接——1/4秒RTT。相比之下，一个跨越美国的租用地面连线所发出的命令响应时间可能少于40毫秒。十年前，Bell Lab科学家们深入地研究了人们在电话通话时可以容忍多长时间，结果显示50毫秒的延时是被认为可以接受的。而更长的RTT将影响交谈。对于计算机与计算机交换而言，大的RTT意味着更糟糕。

了解误差概率

通过集合命令和数据、了解远节点如何工作、以及认知如何使用最佳协议（不是TCP/IP）来编码数据以实现成功的外层空间传输，NASA解决了其吞吐量需求的问题。这里我们跳过了错误，但是吞吐量上未发现的和未改正的错误的影响仍然是重大的并且是协议无关的。为了减少错误意外的发生，NASA一直以来都使用纠错代码来保护价值数亿——或数十亿——美元的命令和数据。

我们的最后一个例子，在此包括基本协议和路径属性，如窗口、计时器、RTT、MTU和位/数据传输率，同时还添加了错误概率（误码率（BER））。不管网络路径是否达到1GBps非拥塞的数据传输率，如果10%的发送数据包丢失，那么吞吐量会变差。

在这种情况下，每秒钟实际通过路径的应用数据数是受所选择的传输协议（TCP、UDP、SCP、RTP……）以及配置的参数影响的。如果协议无法恢复丢失（如，UDP、VoIP），那么终端应用必须进行恢复，这通常是非常缓慢或者基本不动。如果传输协议无法区分拥塞数据包丢失（如路由超载）和物理性错误丢失（如CRC错误），那么它将出现错误操作，包括使用错误的恢复算法和大规模减缓吞吐量。

速率延时乘积

一个重要且派生的路径参数是速率延时产品（或称为“带宽延时乘积”）。这是有限的数据传输率（如T1）与相应路径的RTT的相乘值。从单位上看，我们知道是字节（比特）每秒乘以秒，得到一定的字节（或位）数。这表示在等待收到接收者的响应（如一个ACK）时间内，发送者可以在网络路径中加入多少数据。这是效率——也就是吞吐量——参数。在我们得到响应之前，我们在路径的限制传输率中发送更多的字节，在事务结束后我们就将得到更多的吞吐量。

对这个参数的计算可以让我们知道如何设置发送者的传输窗口，是以数据包或是字节形式。速率延时乘积的概念说明了最终有多少数据包/字节总数会被填充到网络路径中，这样就不会浪费不发送数据（等待）时间。人们通常都无法弄明白这个道理，但是，这是很重要的，如下例所示。

一个沮丧的网络技术员发现安装在同一个用户的笔记本电脑上的相同的应用，在两个不同的公司上运行速率差别达到大约50%。网络上有许多T1-T3线路，其中有一条是特别拥塞的。服务器和客户笔记本电脑之间的距离大约是350到450英里——技术员带着笔记本电脑在各处到处行走！从这些位置出发的路径都是不同的，除非他们在路由器上配置一条T3链路到服务器的位置上，但是RTT都是60毫秒。应用只是简单地（通过TCP/IP）下载一个几MB的销售人员常用（和更新）的文件，但是一半以上的用户都抱怨其缓慢的吞吐量（长时间延时）。在速度缓慢位置上，大约需要花费2分钟来下载3.3MB。

注意上图所示的吞吐量是很稳定的，但是同时也该注意到累积包数据传输（红色）与拟合线（黑色）之间的小偏差。吞吐量仅是217KBps，并且路径上没有任何线路是低于T1——几乎是一个7：1吞吐量损失。为什么呢？对一个缓慢的客户端和服务器上的数据包捕捉分析显示：

1.在缓慢位置上，普遍有大约0.25%的数据包（2.5每1000）丢失在路径上。

2.相应这些丢失的重传延时比典型的TCP栈还要长——大约每次2.5秒

3.在一个或两个共享的T1连接上的负载过重且出现瓶颈，它们造成拥塞延时。

4.文件是使用TCP分割成大约31KB的SMB块放到21全-MTU（1460字节有效负载）的数据包上发送出去的。由于每个块的数据包是奇数的，接收者进入了延时ACK超时状态，这样它将最终一个块的确认每31KB延迟了150毫秒。

5.虽然速率延时乘积是T1 * 60 ms = 8.5， 1460字节数据包，但是服务器的传输窗口只有六个数据包，并且在没有数据包丢失的情况下将不再增加。因此，服务器只使用70%可用的传输窗口。

上述的每一个因素都增加了客户端数据传输的延时。虽然头两个的来源是不一样的（物理性vs.协议栈），但是用户可以看到它们一起所产生了大量的数据块延时。第三个观察到的延时是先前所看到的延迟变化，同时可能还增加了一些由路由器超载所造成的数据包丢失，因此与第二个问题相互作用。第四个延时来源严格来说是接收者的TCP栈配置造成的，它分别在每个31KB块传输中增加150毫秒而降低吞吐量。而其实这个过程原本只需花费165毫秒（包括协议总开销）在T1线路上实现发送。最后一个因素严格来讲也是TCP栈配置的问题，它理论上在每个块中浪费了20毫秒，从而降低了吞吐量。但是，这通过强迫接收者在每一块等待150毫秒ACK而被掩盖了。

麻烦的TCP行为

当终端跟踪比较显示物理数据包丢失发生时，网络技术员将沿着与缓慢用户位置相邻的路径检查每个路由器接口的端口统计。果然，因为租用线路有缺陷，其中的一个接口出现了CRC错误。纠正这个问题可以消除最大的一个延时组件，同时因为TCP并不能确定数据包丢失是因为错误还是拥塞引起的，因此TCP只是减缓了发送者的速度，而不考虑数据包是如何丢失的。这是因为不管是TCP还是IP都没有拥塞通知功能，而路由器都可以明确地向终端节点发出连接拥塞警告。

在快速恢复中，服务器端和客户端的丢失跟踪仅仅显示出极少的尝试。当节点处察觉了丢失后，三次重复ACK仅仅发生了两次，并且服务器却并没有做出快速重传。结果是这样的，不管服务器丢失了多少个数据包，它往往都需要花费2.5秒来恢复一个丢失。

这个图绘制了上面吞吐量图中的线之间的差（红色=黑色-红色），并且显示（红色）它与任何一秒上的平均吞吐量的差别。这样提供了更好地流解析。蓝色标记只是表示每个21-数据包（31KB）SMB块终止的位置（此处，延时ACK损失时间是150毫秒）。

如果不存在延时ACK，那么蓝色标记将会更紧密，红色的曲线则是直线向下，而图的长度将变短

蓝色标记之间的差距是由数据包丢失造成的。在160秒中存在14处1到2秒的差距。

向下斜的红色曲线部分显示吞吐量在丢失恢复后正在追赶——或超过——平均值。

红色向下斜的部分大约比平均值快6，200Bps。因此，当不存在数据包丢失时，每秒将传输27 KB + 6.2 KB = 33.2 KB数据。这将提高23%的吞吐量。需要明确的是：如果0.25%数据包丢失率可以减少20%吞吐量，要么重新配置TCP使用更新的恢复规则（通过Repeated Acks实现Fast Retransmission），要么考虑使用正确的传输协议，所以必须对每个传输流量的网络接口保持高度的警惕性。

这些例子都说明了，作为一名建筑师、管理人员和技术人员都必须非常的细心：

1.了解备用物理网络组件和链接的各个方面

2.了解备用网络协议的各个方面

3.了解哪些工具可以用来查看网络参数

4.了解在默认和可配置参数上，供应商的产品提供哪些协议栈

5.同时必须热情对待用户

记住，要做好一切的准备，不只是去购买更快速交换机或租借更快的线路！（比特网）