多种原因产生的多种结果

我们所看到的是多因素导致的多效性，这存在于典型的现实网络。很明显，“多少（限制的）数据传输率才足够呢？”是一种误导——具体问题要具体分析。如果我们的网络总能保持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）上每个组件的数轴顶部曲线条反映了测量中必然的统计分布——不幸的是，正如我们现在知道的，这个工具的输出显示误用了“带宽”！同样需要注意的是，这个网络图和组件属性（速度，等等）允许我们用一个关键点的测量数据来估算所有的上述信息，如终端节点。我们所需要的是在任何路径上找到延时来源，正是它们导致吞吐量损失的。在上面的图中，我们可以看到服务器本身非常的繁忙，以及最大的延时来源和变化的吞吐量。在这个例子中，网络路径是好的——我们知道这并不是网络的原因。