TCP は「信頼性」を実現するために、送信したデータに対して ACK(確認応答)が返ってくるまで、送信ウィンドウを大きく進められない仕組みになっています。 この構造そのものが、RTT(往復遅延時間)によってスループットを制限する理由になります。
RTT が大きくなるほど ACK を待つ時間が長くなり、結果として ウィンドウが進まず、送信量が増えにくくなる のです。 この制約は実験でも明確に観測されており、RTT が増えるほど TCP のスループットが急激に低下することが確認されています。
1. TCP の本質:ACK を待つプロトコル
TCP は信頼性を保証するために、以下の仕組みを持っています。
- 受信側は 受信バッファ(rwnd) を持つ
- 送信側は 輻輳ウィンドウ(cwnd) を持つ
- 送信側は min(cwnd, rwnd) の範囲でしか送信できない
- データを送った後、ACK が返ってきて初めてウィンドウが前に進む
つまり TCP は、ACK が返ってこない限り、次のデータを大きく送れない構造になっています。 この ACK の往復時間が RTT であり、RTT が大きいほどウィンドウの進みが遅くなります。
2. RTT が大きいとスループットが落ちる理由
実験では、RTT が増えると TCP のスループットが次のように低下することが確認されています。
| RTT | TCP スループット |
|---|---|
| 0ms | 65.6 Gbps |
| 1ms | 21.9 Gbps |
| 10ms | 2.33 Gbps |
| 100ms | 224 Mbps |
| 1000ms | 5.23 Mbps |
この落ち方は極端に見えますが、TCP の構造を考えると自然な結果です。
3. 理論式:TCP スループットは RTT の逆数に比例
一般的に、TCP のスループットは次の式で近似されます。
ウィンドウサイズが大きいほど送信できますが、RTT が大きいと ACK を待つ時間が長くなり、ウィンドウが進まなくなります。 そのため、RTT が大きいほどスループットは必ず低下します。
4. なぜ UDP は RTT の影響を受けないのか
同じ実験では、UDP は RTT が増えてもスループットがほとんど変わりません。 これは UDP が ACK を待たないプロトコルであるためです。
- TCP:確認応答を待つ
- UDP:送りっぱなし
この構造の違いが、RTT の影響の差として現れます。
5. TCP が RTT に制限される“深い理由”
TCP は信頼性を実現するために、世界中どこにいても ACK を待つという構造を持っています。 これは TCP の強みであると同時に、弱点でもあります。
- パケットロスがあっても再送できる
- 順序が保証される
- しかし RTT が大きいと極端に遅くなる
TCP の遅さは、ネットワークの物理距離そのものが性能を決めるという根源的な制約から生まれています。
6. RTT の制限を緩和する技術
TCP が RTT に制限されることは避けられませんが、その影響を軽減する技術は存在します。
- ウィンドウスケール(RFC1323):ウィンドウを最大 1GB まで拡張
- CUBIC:RTT が大きい環境でもウィンドウを積極的に拡大
- BBR:帯域と RTT を推定し、輻輳ウィンドウを RTT 非依存に近づける
- 受信バッファのチューニング:rwnd を大きくして制限を緩和
ただし、RTT の影響を完全に消すことはできません。 TCP の構造上、ACK の往復は必ず必要だからです。
まとめ:TCP は RTT によって制限される

TCP が RTT に制限される理由は、ACK を待つというプロトコルの本質にあります。
- ACK が返るまでウィンドウが進まない
- RTT が大きいほど ACK 待ちが長くなる
- その結果、スループットが低下する
- 実験でも RTT の増加に伴いスループットが急激に低下することが確認されている
TCP の遅さは欠点ではなく、信頼性を守るための代償といえます。

HR