頻寬*延遲積
我正在嘗試計算各個主機之間的頻寬延遲產品，並且閱讀這篇 wiki 文章，我很困惑。
從文章；
住宅 ADSL2+：20 Mbit/s（從 DSLAM 到住宅調製解調器），50 ms RTT
B×D = 20×106 b/s × 50×10-3 s = 106 b，或 1 Mb，或 125 kB。
我正在測試的到測試主機的連接之一是 ADSL2+ 連接。它的下行同步速率為“11006 kbps”，我猜測 10000Kbps 是一個合理的理論最大吞吐量。當從 ADSL2+ 線路“ping”測試主機時，我得到 29 毫秒的 RTT。測試主機通過 100Mbps 乙太網連接連接到“Internet”。
現在，這是令人困惑的部分；對伺服器執行速度測試（它正在執行 speedtest.net 的迷你速度測試應用程序的副本），我得到 9.23Mbps 的下行速度。根據那篇 Wiki 文章，10000000bps * 0.029s = 290000bps（290 Kbps），這比我的 9.23Mbps 小得多。
我錯過了一些明顯的東西，還是文章有誤？
我正在嘗試計算各個主機之間的頻寬延遲積……我錯過了一些明顯的東西，還是文章有誤？
您只是缺少單位；當您將 bps 乘以秒時，您會得到位作為單位：
10Mbps * .029s = 2900000.0 位（362500 字節）
這篇文章的重點是它強調了你的（縮放的）TCP 視窗需要什麼，以避免由於“長胖網路”而導致的延遲。引用RFC 1072：
最近關於 TCP 性能的研究表明，TCP 可以在各種 Internet 路徑上很好地工作，範圍從 800 Mbit/sec I/O 通道到 300 bit/sec 撥號調製解調器
$$ Jacobson88 $$. 然而，對於一種傳輸機制，仍然存在一個基本的 TCP 性能瓶頸：具有高頻寬和長往返延遲的路徑。重要的參數是頻寬（比特每秒）和往返延遲（RTT，以秒為單位）的乘積；該乘積是“填充管道”所需的位數，即 TCP 必須處理的未確認數據量，以保持管道充滿。當該乘積很大時會出現 TCP 性能問題，例如，顯著超過 10**5 位。我們將在該區域中執行的 Internet 路徑稱為“長而肥的管道”，將包含該路徑的網路稱為“LFN”（發音為“elephan(t)”）。
在這種特殊情況下，TCP 需要為您提供大約 362KB 的縮放視窗大小。現代 TCP 實現（那些正確實現RFC 1323的實現）不會遇到與 LFN 相關的問題。