这些单个延时因素一起导致产生变化的性能，这样的性能只能进行统计性建模和估算。我们从上面的数据可以看到最大的延时是由于一个运行T1线路的特定的路由器/网桥的拥塞。如果路由器/网桥可以更快地操作，那么这条链路就够用了，我们并不需要更多的数据传输率。但是如果不能，我们就需要一个更好的或者升级的路由器/网桥。
前面和下面这个都是通过使用专门用于网络性能分析的工具（NetCalibrator和NetPredictor）根据实际的网络数据包生成的。。如果对这里所述的各项原则已经了解，并且可以在路径上捕获数据，那么诸如这样的复杂工具并不总是需要的。显示在另一个更短的路径上如何消除延时来源，它仍然使用了我们已经讨论过的数据。
注意，分配到网络路径（从Percheron 到AFS08）上每个组件的数轴顶部曲线条反映了测量中必然的统计分布——不幸的是，正如我们现在知道的，这个工具的输出显示误用了“带宽”！同样需要注意的是，这个网络图和组件属性（速度，等等）允许我们用一个关键点的测量数据来估算所有的上述信息，如终端节点。我们所需要的是在任何路径上找到延时来源，正是它们导致吞吐量损失的。在上面可以看到服务器本身非常的繁忙，以及最大的延时来源和变化的吞吐量。在这个例子中，网络路径是好的——我们知道这并不是网络的原因。
速率延时乘积
一个重要且派生的路径参数是速率延时产品（或称为“带宽延时乘积”）。这是有限的数据传输率（如T1）与相应路径的RTT的相乘值。从单位上看，我们知道是字节（比特）每秒乘以秒，得到一定的字节（或位）数。这表示在等待收到接收者的响应（如一个ACK）时间内，发送者可以在网络路径中加入多少数据。这是效率——也就是吞吐量——参数。在我们得到响应之前，我们在路径的限制传输率中发送更多的字节，在事务结束后我们就将得到更多的吞吐量。
对这个参数的计算可以让我们知道如何设置发送者的传输窗口，是以数据包或是字节形式。速率延时乘积的概念说明了最终有多少数据包/字节总数会被填充到网络路径中，这样就不会浪费不发送数据（等待）时间。人们通常都无法弄明白这个道理，但是，这是很重要的，如下例所示。
一个沮丧的网络技术员发现安装在同一个用户的笔记本电脑上的相同的应用，在两个不同的公司上运行速率差别达到大约50%。网络上有许多T1-T3线路，其中有一条是特别拥塞的。服务器和客户笔记本电脑之间的距离大约是350到450英里——技术员带着笔记本电脑在各处到处行走！从这些位置出发的路径都是不同的，除非他们在路由器上配置一条T3链路到服务器的位置上，但是RTT都是60毫秒。应用只是简单地（通过TCP/IP）下载一个几MB的销售人员常用（和更新）的文件，但是一半以上的用户都抱怨其缓慢的吞吐量（长时间延时）。在速度缓慢位蒙希笤夹枰ǚ?分钟来下载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都没有拥塞通知功能，而路由器都可以明确地向终端节点发出连接拥塞警告。
可以看到TCP行为的巨大影响：
在快速恢复中，服务器端和客户端的丢失跟踪仅仅显示出极少的尝试。当节点处察觉了丢失后，三次重复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.同时必须热情对待用户
记住，要做好一切的准备，不只是去购买更快速交换机或租借更快的线路！
上一页 [1] [2]
责任编辑：小草
您现在的位置： 