RTT80ms・64KBウィンドウで6.4Mbpsに制限されたTCP転送の改善
本社と支社を結ぶ100Mbpsの専用線がある。片道の遅延は40ms、RTTは80msである。社内のあるファイル転送アプリは、TCPウィンドウサイズを64KBに固定し、ウィンドウスケーリングオプションを使用していない。20MBのファイルを転送したところ、実測スループットは6.4Mbpsであった。回線のパケット損失率は0.01%であり、輻輳は観測されていない。支社側の受信バッファは64KB、本社側の送信バッファも64KBである。回線の契約帯域は100Mbpsで、実測の物理帯域は95Mbpsである。アプリは1日に約300ファイルを転送し、業務時間内に完了する必要がある。現在、1ファイルあたりの転送に約25秒かかっており、業務時間の終わりに待ちが発生している。本社側のOSはウィンドウスケーリングに対応しているが、支社側の古いファイアウォールがTCPオプションを書き換える可能性がある。過去の測定では、ウィンドウサイズを256KBにするとスループットが約80Mbpsまで向上したという報告がある。ネットワーク管理者は、帯域増強、TCPパラメータ変更、アプリの圧縮導入を検討している。
1. 実測スループットが6.4Mbpsにとどまる理由を、BDPとTCPウィンドウサイズから計算して説明せよ。
Read the worked answer
BDP = 100Mbps × 80ms = 100,000,000 × 0.08 = 8,000,000ビット = 1MBである。ウィンドウサイズ64KBでは、1 RTTあたり64KBしか送れないため、最大スループット = 64KB / 80ms = 65,536×8 / 0.08 ≒ 6.55Mbpsとなる。実測6.4Mbpsはこれにほぼ一致する。したがって、ボトルネックは帯域やパケット損失ではなく、ウィンドウサイズがBDPに比べて小さいことである。損失0.01%はTCPの輻輳制御に大きな影響を与える水準ではない。
2. 帯域増強、TCPウィンドウスケーリング有効化、アプリ圧縮のうち、最も費用対効果が高い対策を選び、理由を述べよ。対策後の理論スループットと20MBファイルの転送時間も概算せよ。
Read the worked answer
最も費用対効果が高いのは、TCPウィンドウスケーリングの有効化とウィンドウサイズの拡大である。帯域を1Gbpsに増やしても、ウィンドウが64KBのままならスループットは約6.4Mbpsのままで、投資効果がない。圧縮はデータ量を減らせるが、CPU負荷と圧縮率に依存し、根本的なRTT制約は残る。ウィンドウをBDP相当の1MB以上に設定すれば、理論上は回線帯域の95Mbps近くまで出る。20MB=160Mビットを95Mbpsで割ると約1.7秒、プロトコル overhead を考慮して2秒程度となる。ただし、支社側ファイアウォールがTCPオプションを書き換える場合は、通過確認と装置更新が必要である。
3. ウィンドウスケーリングを有効にできない場合の代替策を2つ挙げ、それぞれの限界を述べよ。
Read the worked answer
代替策の1つは、アプリケーションで複数のTCPコネクションを並列に張り、ファイルを分割転送する方法である。合計スループットは接続数に比例して増やせるが、アプリの改修が必要で、回線上の公平性やサーバ負荷、再送時の管理が複雑になる。もう1つは、圧縮や差分転送、キャッシュを導入して転送データ量そのものを減らす方法である。テキストやログには有効だが、既に圧縮済みのファイルには効果が薄い。RTTを短縮するために支社側にキャッシュサーバを置く方法も考えられるが、初期コストとデータ整合性の運用が必要である。