多少带宽才够用

admin管理员组

文章数量:1530817

2024年7月17日发(作者：)

多少带宽才够用

“带宽”关于网络治理人员、建筑师和技术人员来讲是毫无心义的一个术语，

相反，他们利用“数据传输率”、“连接性能”或乃至“网速”来简单地代替那个术语，

这就说明了一个问题，咱们对网络有点无知，至少对在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）

由于传输协议（如，TCP）存在错误恢复的限制，因此第一个参数的重要性

与日俱增。而随着传输数据的增加，第二个参数也愈来愈重要。二者都与传输协

议的行为相互作用。尽管来回延时似乎是直观的，可是它与网络途径和协议参数

之间的关系却往往被漏掉。因此，咱们必需了解哪些网络协议参数可能与网络途

径本身的属性彼此作用。

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

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

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

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

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

I.途径拥塞通知，若是有（第2层和更高层的）

这些是要紧的协议栈参数和相关算法，它们许诺在现实的、不完善的网络途

径和终端性能中实现吞吐量最大化。可是，这并非意味着吞吐量将达到理想的最

大化，而只是表示在一个指定的现实途径，协议性能能够调整（第1层和更高层）

到关于该协议/途径组合的最正确吞吐量——选择一个不同的协议或途径可能会

专门好地提高整体吞吐量。这确实是网络架构师必需具有体会和知识以更好地设

计的缘故，同时也是网络治理人员和技术人员必需精通性能测试和计算的缘故。

下面那个统计图表示在一条现实网络途径中发送成千上万的实际网络数据

包以知足一个用TCP/IP进行简单但大型的文件传输请求：

左上角显示传输的流量花费了大约35秒时刻，因此吞吐量是8 * 1500000 /

35 = 343 KBps，是一个典型的小T1连接速度，如ADSL上传。可是——右下角

显示许多中转包延时仅是8毫秒（MSEC），同时左下角显示所有的数据包是1518

字节——以太网的传统MTU。这两个事实意味着1518字节有时候能够每8毫秒，

或说满T1（）传送。显然，在限制数据传输率（良好的）和实际吞吐量（不太

好的）之间存在着差距。

每一个数据包的协议开销是18B + 20B + 20B (Ethernet + IP + TCP)，因此传

输每一个数据包会折损掉1518 - 58 = 1460字节有效负载，而实现的最高的速度

为8 * 1460 / .008 = ：接近于T1，可是与观看到的平均速度35秒有着专门大的

差距。这是怎么回事呢？咱们的突发吞吐量接近于T1，可是咱们所维持的平均

吞吐量那么还不到四分之一。

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

接收节点的确认时刻散布很普遍，可是大多数速度都超级快（大约200毫秒）

——协议栈大体上都专门快

一些ACK时刻超级长（延时ACK>100毫秒）——是什么缘故呢？

常常显现限制速度，可是更多的是，在右下角显示一个相邻包的普遍传播时

刻，即中转抵达时刻——什么缘故？

多种缘故产生的多种结果

咱们所看到的是多因素致使的多效性，这存在于典型的现实网络。很明显，

“多少（限制的）数据传输率才足够呢？”是一种误导——具体问题要具体分析。

若是咱们的网络总能维持的传输带宽，那么咱们的等待时刻是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必需与空间探测器和登岸车进行通信。在太空飞行时，详细的无

线命令-响应事件和计算模型能够提供精准的航空器跟踪定位。

可是，只有在咱们明白得了万有引力、行星轨道和磁场和其它阻碍，而且在

这些知识的基础上进行预测，咱们才能取得那个精准性。咱们并非明白航天器在

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分钟来下载。

注意上图所示的吞吐量是很稳固的，可是同时也该注意到积存包数据传输

（红色）与拟合线（黑色）之间的小误差。吞吐量仅是217KBps，而且途径上没

有任何线路是低于T1——几乎是一个7：1吞吐量损失。什么缘故呢？对一个缓

慢的客户端和效劳器上的数据包捕捉分析显示：

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

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

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

时。

4.文件是利用TCP分割成大约31KB的SMB块放到21全-MTU（1460字节

有效负载）的数据包上发送出去的。由于每一个块的数据包是奇数的，接收者进

入了延时ACK超时状态，如此它将最终一个块的确认每31KB延迟了150毫秒。

5.尽管速度延时乘积是T1 * 60 ms = ， 1460字节数据包，可是效劳器的传

输窗口只有六个数据包，而且在没有数据包丢失的情形下将再也不增加。因此，

效劳器只利用70%可用的传输窗口。

上述的每一个因素都增加了客户端数据传输的延时。尽管头两个的来源是不一样

的（物理性vs.协议栈），可是用户能够看到它们一路所产生了大量的数据块延时。

第三个观看到的延时是先前所看到的延迟转变，同时可能还增加了一些由路由器

超载所造成的数据包丢失，因此与第二个问题彼此作用。第四个延时来源严格来

讲是接收者的TCP栈配置造成的，它别离在每一个31KB块传输中增加150毫

秒而降低吞吐量。而其实那个进程本来只需花费165毫秒（包括协议总开销）在

T1线路上实现发送。最后一个因素严格来讲也是TCP栈配置的问题，它理论上

在每一个块中浪费了20毫秒，从而降低了吞吐量。可是，这通过强迫接收者在

每一块等待150毫秒ACK而被掩盖了。

本文标签： 网络延时途径