一个重要且派生的路径参数是速率延时产品（或称为“带宽延时乘积”）。这是有限的数据传输率（如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而被掩盖了。