网络带宽设计

简介与吞吐量问题“带宽”对于网络管理人员、建筑师和技术人员来说是毫无意义的一个术语，相反，他们使用“数据传输率”、“连接性能”或者甚至“网速”来简单地代替这个术语，这就说明了一个问题，我们对网络有点无知，至少对在OSI模式的7个层次中的第1层是比较无知的。

许多人可能使用“带宽”来表示比特每秒，但是这样做就反映了对信号理论和基本物理通信的无知。

下面所回顾的术语显示了即使是它们的物理特性也是不一样的。

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

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

“带宽”往往被草率地应用于错误的上下文中，或者被用于一些看起来挺怪异的场景中。

这是相当糟糕的，因为网络新手们很容易被误导而非受到正确教育。

这里有一个适当的解释。

在Claude Shannon工作中：“带宽”就如同农田。

对这块农田的开垦方式将收获一个特定的数据传输率。

许多前辈，如Dennis Hayes，花费了大量的精力，致力于通过调制解调器实现Shannon的假定的权限（香农极限）来将未经处理的带宽转换为位/秒。

他们使用了灵活、明智的信号符号（FSK、SQPSK…）选择——这样就能从任意指定的频道带宽中获取非常好的数据传输率。

一些欧洲国家已经定义的编码与香农极限（Shannon Limit）非常接近。

但是，并没有任何情况显示带宽与数据传输率是一样的。

相反，它是通过一个精心挑选的传输符号来要求智能开发的机会——甚至Napoleon网络的设计者早在200年前就知道了这个方法：他建立一个跨越欧洲的光纤网络以实现在15分钟之内能将国王命令发回巴黎的通信时，这是使用一个20位符号的代码实现的。

瑞典人也在200年前拥有了他们自己的521位符号光纤网络。

而当计划与V oyagers通话时，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，但是我们所维持的平均吞吐量则还不到四分之一。

右边的象限显示了更多关于路径的问题：接收节点的确认时间分布很广泛，但是大多数速度都非常快（大约200毫秒）——协议栈基本上都很快一些ACK时间非常长（延时ACK>100毫秒）——是什么原因呢？经常出现限制速率，但是更多的是，在右下角显示一个相邻包的广泛传播时间，即中转到达时间——为什么？多种原因产生的多种结果我们所看到的是多因素导致的多效性，这存在于典型的现实网络。

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

如果我们的网络总能保持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 必须与空间探测器和登陆车进行通信。