TCPの重要な要素として、輻輳制御アルゴリズムがある。TCPはシーケンス番号を使った応答確認によってデータの確実な到達を担保している。応答確認が行われないパケットについては、再度同じデータを送信するように、受信側から送信側へ再送要求が行われる。

 ところが、ネットワークが輻輳して遅延が大きくなると、同じデータを何度も再送してしまい、無駄なトラフィックが発生して輻輳がさらに悪化する。そこで転送量を制御して輻輳状態を抑える「輻輳制御」が重要となる。

 輻輳制御を行うアルゴリズムの歴史は、TCPの歴史と言っても過言ではない。ここで簡単に発展経緯をひもといてみよう。

TCPの輻輳制御アルゴリズムの進化
地味で目立たず発展していないように見えるTCPだが、2000年代に入ってむしろ新しいアルゴリズム実装が続々登場していることがわかる。
[画像のクリックで拡大表示]

 1988年に初登場した輻輳制御アルゴリズム「Tahoe」は、後に登場するアルゴリズムに多くの影響を与えた。段階的にウインドウサイズを増加させて帯域流量を増加させる「スロースタート」、再送タイムアウトを待たずにパケットを送信する「高速再送アルゴリズム」などがここで実装された。また、次に登場した「Reno」はTahoeを改良した「高速回避アルゴリズム」を取り入れた。

 その後の数々のアルゴリズムは統計や数学的なロジックを採用して進化を重ねてきた。特に2000年以降、特定の物理ネットワークや通信環境に合わせたアルゴリズムが続々登場している。例えば、高遅延・広帯域(ロングファットパイプ)で効率が高い「BIC」「CUBIC」「H-TCP」「Fast TCP」「Illinois」、低遅延・広帯域であるデータセンターに向けて最適化された「DCTCP」、モバイル回線やWi-Fiなど無線環境に適している「Veno」や「Westwood」などだ。いろいろなアルゴリズムを用途に合わせて使い分けられるようになった。

▼ウインドウサイズ
TCPで、受信側からの確認応答を待たずに一度に送信できるデータのサイズ。このサイズを調整してデータの流量(フロー)を制御する。
▼高速回避アルゴリズム
輻輳の程度が小さい場合、送信速度を下げ過ぎないように改良したアルゴリズム。
▼BIC
Binary Increase Congestion controlの略。
▼H-TCP
Hamilton TCPの略。
▼DCTCP
Datacenter TCPの略。データセンターTCP。

実装は3種類に分けられる

 これらTCPの輻輳制御アルゴリズムは大きく、(1)パケットロスを観測するロスベース方式、(2)RTTを指標とする遅延ベース方式、(3)両方の方式を使い分けるハイブリッド方式──の3方式に分けられる。

 (1)のロスベース方式は、パケットのロスを観測し、ロスが増えれば輻輳が発生したと見なして送信量を抑えるという方法である。代表例として、Reno、Renoの改良版である「NewReno」、H-TCP、BIC、CUBICなどがある。

 (2)の遅延ベース方式は、パケットのRTTを観測し、RTTが増えたら輻輳状態になったと判断して送信量を減らす。主要な実装では、1994年に提案された「Vegas」が最初に採用している。このほかには、Westwood、Fast TCPなどが挙げられる。

 (3)の代表例としては、Illinois、DCTCPに加え、「CTCP」や「YeAH」などがある。

 どの輻輳制御アルゴリズムを使えるかは、OSによって異なる。デフォルトでは、LinuxやAndroidはCUBICが、OS XではNewRenoが使われている。Windowsでは、CTCPとDCTCPを切り替えて使える。

▼CTCP
Compound TCPの略。Windows VistaとWindows Server 2008で初採用された。
▼YeAH
Yet Another Highspeed TCPの略。

次ページ以降はITpro Active会員(無料)の方のみお読みいただけます。