我试图计算各种主机之间的带宽延迟产品，并阅读这篇wiki文章 ，我很困惑。
从动作
住宅ADSL2 +：20 Mbit / s（从DSLAM到住宅调制解调器），50 ms RTT
B×D = 20×106b / s×50×10-3s = 106b，或者1Mb或125kB。
我正在testing的一个连接到testing主机，是ADSL2 +连接。 它具有“11006 kbps”的下行同步速率，我估计10000Kbps是一个合理的理论最大吞吐量。 当从ADSL2 +线路“ping”testing主机时，我得到29ms的RTT。 testing主机通过100Mbps以太网连接连接到“Internet”。
现在，这是令人困惑的部分 。 对服务器进行速度testing（正在运行一个speedtest.net的迷你速度testing应用程序的副本），我得到9.23Mbps的下游。 根据那篇Wiki文章，10000000bps * 0.029s = 290000bps（290 Kbps），这远远低于我的9.23Mbps。
我错过了一些显而易见的东西，还是文章错了？
我试图计算不同主机之间的带宽延迟产品…我错过了明显的东西，还是文章错了？
你只是想念单位; 当你以秒为单位乘以bps时，你得到的位数为单位：
10Mbps * .029s = 2900000.0位（362500字节）
文章的要点是，它突出了你的（缩放的）TCP窗口所需要的，以避免由于“长胖networking”而导致的延迟。 引用RFC 1072 ：
最近有关TCP性能的工作表明，TCP可以在800 Mbit / sec I / O通道到300 bit / sec拨号调制解调器[Jacobson88]等各种Internetpath上运行良好。 但是，对于一种传输机制，仍然存在基本的TCP性能瓶颈：高带宽和往返延迟较长的path。 重要参数是带宽（比特每秒）和往返延迟（以秒为单位的RTT）的乘积; 这个产品是“填充pipe道”所需要的位数，也就是TCP为了保持pipe道充满而必须处理的未确认的数据量。 当产品很大时，TCP性能问题就会出现，例如，显着超过10 ** 5位。 我们将把在这个地区运行的互联网path称为“长pipe”，将这条path称为“LFN”（发音为“elephan（t）”）。
在这种情况下，TCP需要给你一个大小为362KB的缩放窗口大小。 现代TCP实现（正确实现RFC 1323的实现）不会遇到与LFN相关的问题。