帯域遅延積（BDP）・TCPウィンドウサイズ計算機

帯域（Kbps〜Gbps）とRTT（ミリ秒）から帯域遅延積（BDP）をバイト・KiB・MiBで即時計算。フル活用に必要なTCPウィンドウサイズ、RFC 1323のウィンドウスケール係数、64KiB固定時の最大スループットも表示します。

回線は100Mbps出ているはずなのに、遠くのサーバーとの転送だけ妙に遅い。帯域は足りているのに速度が出ないなら、それはRTTとTCPウィンドウの組み合わせが原因かもしれません。このツールは、帯域とRTTから帯域遅延積（BDP）と、それを埋めるのに必要なTCPウィンドウサイズを計算します。

使い方

帯域（Kbps/Mbps/Gbps）を選びます。
RTT（往復遅延, ミリ秒）を入力します。pingコマンドの結果でだいたい分かります。
BDPと、フル活用に必要なウィンドウサイズ、ウィンドウスケール係数が下に出ます。

仕組み・計算式

BDP（Bandwidth-Delay Product）は「帯域[bps] × RTT[秒] ÷ 8」で、通信路上に同時に存在できるデータ量をバイト単位で表したものです。TCPがこの量を上回るデータを送るには、受信側のウィンドウサイズがBDP以上必要になります。これはTCPの輻輳制御・フロー制御の基本的な考え方で、多くの教科書やRFC 1323（TCP Extensions for High Performance）のウィンドウスケールオプションの説明で前提とされています。

TCPヘッダのウィンドウフィールドは16ビットなので、スケールなしでは最大65,535バイトしか表現できません。RFC 1323のウィンドウスケールオプションは、この値に2の n 乗（n は0〜14）を掛けて広げる仕組みです。このツールは、65,535 × 2^n がBDP以上になる最小の n を表示します。試しに帯域100Mbps・RTT 50msで計算すると、BDPは約625,000バイト（約610KiB）で、n=4（16倍、最大ウィンドウ約1MiB）が必要という結果になりました。

現場の落とし穴として、ウィンドウスケールはTCPのハンドシェイク（SYN）でオプションが両者一致していないと有効になりません。途中の古いファイアウォールやロードバランサーがこのオプションを落とすと、ウィンドウは65,535バイトに固定されたまま動きます。そうなると、さきほどの例では64KiB固定時の最大スループットの欄が示すとおり、実測は10Mbps程度で頭打ちになります。帯域を上げても速度が変わらないときは、まずここを疑ってみてはいかがでしょうか。

よくある質問

Q. なぜ65,536ではなく65,535が基準なのですか？

A. TCPヘッダのウィンドウフィールドが16ビット符号なし整数（0〜65535）だからです。一方で「64KiB固定時の最大スループット」の行は、慣用的に使われる65,536（64×1024）バイトで計算しています。1バイトの差なので実用上の影響はほぼありません。

Q. RTTはどう測ればいいですか？

A. 通信相手のホストに対してpingを数回打ち、往復時間の平均値を使うのが簡単です。経路がTCPと異なる場合はtracerouteなどで確認してください。

Q. ウィンドウスケールを大きくすればするほど速くなりますか？

A. 必要な分だけあれば十分です。過大なウィンドウは受信側のメモリを無駄に使うだけで、実効速度が伸びるわけではありません。