高速化技術を理解するには,基本となるもともとのTCP/IP技術を押さえておく必要がある。TCP/IPのスループットは理論上,「1パケットで受信できるデータ量(RWIN)÷1パケットの受信が完了するまでの遅延時間(RTT)」で求められる。LinuxやWindows 2000 SP3以降の主要なOSは,TCP仕様の最大値64Kバイト(512kビット)をRWINとして設定する。RTTが20ミリ秒だとすると,スループットは最大約25Mビット/秒となる。

 この環境で100Mビット/秒の帯域を占有できるとすれば,約25Mビット/秒では遅い。つまり,もともとのTCP/IPでは力不足というわけだ。その最大の理由は,TCP通信の「フロー制御」と「輻輳制御」の仕組みにある。

大量データをまとめて送信

 フロー制御から説明しよう。これは確実にデータを送信する機構のことで,TCP通信の基本である。TCPは,送信データを確実に届けるため,送信データを「セグメント」に分割し,セグメントをパケットに格納して送信する。受信側では,パケットからセグメントを受け取るたびに,到達通知(ACK)を送り返す。この往復1回の通信にかかる時間がRTTである。

 ただ,一つのセグメントを送るたびにACKの受信を待たねばならないのは非効率なので,TCPではセグメントをまとめて送る。つまり,複数のセグメントを連続送信した後,各セグメントに対応するACKを待つ。

 しかし,むやみに多数のセグメントをまとめ送りすると輻輳しかねないし,受信側で受けきれないかもしれない。そこでTCPでは,まとめ送りするセグメント数を徐々に増やす仕組みになっている(図1左)。最初はセグメントを1個しか送らないが,無事にACKが返ってきたら,次は2個。成功したら今度は倍の4個を送る。これを繰り返し,まとめ送りするセグメント数を増やしていく(この一連の動作を「スロー・スタート」と呼ぶ)。

図1●送信を開始した後の動き
図1●送信を開始した後の動き
もともとのTCPは,送信データを確実に,かつ効率よく届けるために,まとめ送りする送信データ量を少しずつ増やしていく。このため,動作イメージは緩やかに速くなる。最初からたくさんのデータを(大容量初期ウインドウ),一気に送り込む(ウインドウ・スケーリング・オプション)ことで,スループットを上げる

 まとめて送信できるセグメント数の最大値は,受信側で用意している受信バッファのサイズ(RWIN)までとなる。RWINのサイズは,TCPコネクションを確立する際などに送信側に通知し,RWINのサイズを超えないように送信側が制御する。

 この仕組み上,RWINが大きいほどRWINに達するには時間がかかり,長距離通信で遅延(RTT)が大きいほど平均スループットは低下する。

 この問題を改善するのが,「大容量初期ウインドウ」(RFC3390)や「ウインドウ・スケーリング・オプション」(RFC1323)である。大容量初期ウインドウは,最初に送るセグメント数を増やす(図1右上)。もともとのTCPは1460バイトで,それを4380バイトに拡大する。さらにウインドウ・スケーリング・オプションは,RWINの最大値を従来の64Kバイトから1Gバイトに拡張する(図1右下)。より多くのデータをまとめ送りできるので,スループット向上を期待できる。

 大容量初期ウインドウやウインドウ・スケーリング・オプションはすでに標準化されており,主要なOSやルーター装置が対応済みである。ただし,帯域が狭い場合やネットワークの信頼性が低い(エラー率や損失率が高いなど)場合にウインドウ・スケーリング・オプションを使うと,大容量データが頻繁に再送されてしまい,逆効果になりかねないので注意したい。

出典:日経SYSTEMS 2007年1月号 109ページより
記事は執筆時の情報に基づいており、現在では異なる場合があります。