私の理解では、帯域幅遅延積は、2つのエンドポイント間の任意の時点での「転送中」のデータの最大量を指します。
私が得られないのは、なぜ帯域幅にRTTを掛けるのかということです。帯域幅は、銅線、消防光学系などの基盤となるメディアの関数であり、RTTは、中間ノードのビジー状態、中間ノードで適用されるスケジューリング、距離などの関数です。RTTは変更できますが、実用的な帯域幅を考慮することができます。修正済み。では、一定値（容量、別名帯域幅）に変動値（RTT）を掛けると、転送中のデータの総量をどのように表すのでしょうか。
これに基づいて、本当に本当に遅いのは非常に大きな容量を持つのでしょうか？RTTの「原因」が低下し始める可能性があります。
単位を見てください：
[データ量]=[帯域幅]*[ラウンドトリップ時間]。
ユニットに関しては、それは正しいです。意味的には、
帯域幅*ラウンドトリップ時間とは何ですか？これは、送信者が最初の確認応答を受信する前に送信者を離れたデータの量です。つまり、帯域幅*ラウンドトリップ時間=完全な条件下での望ましいウィンドウサイズです。
ラウンドトリップ時間が最後のパケットから測定され、送信者のアウトバウンド帯域幅が完全に安定していて完全に使用されている場合、測定されたウィンドウサイズは、転送中のパケット（データとACKを合わせたもの）の数を正確に計算します。一方向のみが必要な場合は、数量を2で割ります。
往復時間は測定量であるため、自然に変動します（そして滑らかになります）。測定された帯域幅も変動する可能性があるため、転送中のデータの推定総量も変動します。
転送中のデータの量は、データ転送速度によって異なる可能性があることに注意してください。ボトルネックがワイヤ遅延である場合、RTTは一定であると見なすことができ、転送中のデータの量は、ネットワークに送信される速度に比例します。
もちろん、往復時間が突然劇的に増加した場合、推定最大値。転送中のデータ量も増加しますが、それは正しいです。付随するパケット損失がない場合は、スライディングウィンドウを拡張する必要があります。パケット損失がある場合は、帯域幅の見積もりを再検討する必要があります（それに応じて帯域幅遅延積が低下します）。
Jan Dvorakの答えに追加すると、「大きな太いパイプ」をガーデンホースと考えることができます。パイプ内の水量に関心があります。したがって、その「帯域幅」、つまりホースの場合は断面積によって決定される水を供給することができる速度を取り、RTTに対応する長さ、つまり水滴の「長さ」を掛けます。一方の端からもう一方の端に移動するのにかかります。結果は、ホースの体積、パイプの体積、「パイプ内の」データの量です。
まず、BDPは、パフォーマンスチューニングで使用される計算値であり、未処理/未確認の可能性があるデータの上限を決定します。これは、ほとんどの場合、「転送中」のデータの量を表すのではなく、チューニングパラメータが適用されるターゲットを表します。それが「転送中」のデータを表す場合、常に、パフォーマンスを調整する余地はありません。
RTTは実際には変動します。これが、予想される最悪の場合のRTTが計算に使用される理由です。最悪の場合に調整することにより、RTTが最も低いときにスループット効率が最大になります。RTTが改善されると、すぐに優れたAcksが得られ、パイプは満杯のままで、最大のスループット（効率）が維持されます。
「フルパイプ」は誤称です。Rxには通常送信されたパケットよりも小さいAckパケットが含まれているため、目標はTx側をフルに保つことです。
RTTは、非対称のアップストリームおよびダウンストリーム帯域幅（ADSL、衛星モデム、ケーブルモデムなど）も集約しました。