TCP輻輳制御(こうそうせいぎょ)とは

安定しているはずの回線で速度が上下するのは、TCPが裏でネットワークの様子をうかがいながら送信量を調整しているからです。

輻輳制御が必要な理由

インターネットは多数の接続が同じルーターや回線を共有する仕組みです。すべての送信者が最大速度でデータを送り続けると、途中のルーターのバッファがあふれてパケットロスが急増し、再送がさらに増えて全体のスループットが崩壊する「輻輳崩壊」につながりかねません。輻輳制御は、そうなる前に送信速度をネットワークの状態に合わせて自ら調整するTCPの仕組みです。

輻輳ウィンドウ(cwnd)とは

輻輳ウィンドウは、確認応答(ACK)を待たずに送信できるデータ量を表す値です。値が大きいほど一度に多くのデータを送れてスループットが上がりますが、大きすぎるとネットワークが処理しきれずパケットロスが発生します。ほとんどの輻輳制御アルゴリズムは、結局のところこの値を状況に応じて増減させるルールにすぎません。

スロースタート:少しずつ速度を探る

接続が始まったばかりの段階ではネットワークの状態が分からないため、TCPは小さなウィンドウから始め、確認応答が届くたびにウィンドウを倍々に増やしていきます。この指数関数的な増加によって適正な速度をすばやく見つけますが、パケットロスが発生するか、あらかじめ決めたしきい値に達するとスロースタートを終え、より慎重に増やす輻輳回避フェーズに移ります。

輻輳回避:損失が起きたら速度を落とす

従来型のTCPは、パケットロスを「ネットワークが混雑しているサイン」として扱います。損失を検知するとウィンドウを大きく(多くの場合半分に)減らし、その後は損失が起きない限りゆっくりと直線的に増やしていきます。この増減を繰り返すことで、スループットのグラフには特徴的なのこぎり歯状のパターンが現れます。

RenoとNew Reno:損失ベースの古典的アルゴリズム

1990年代に登場したTCP Renoは、スロースタート、輻輳回避、高速再送・高速回復を組み合わせ、損失が起きたらすぐにウィンドウを減らして素早く回復するよう設計されています。New Renoは、1つのウィンドウ内で複数のパケットが失われた場合の回復性能を改善したものです。ただし帯域幅が非常に大きい高速回線では、損失後の回復が遅く、回線を十分に使い切れないという弱点があります。

Cubic:Linuxの標準、高帯域幅向けの改良版

現在のLinuxカーネルの標準アルゴリズムであるCubicは、ウィンドウサイズを時間の3次関数(キュービック)曲線に沿って調整します。損失の直後は素早く以前の水準近くまで回復し、その後は緩やかに増加させ、前回損失が起きた地点付近では再び慎重になります。この方式は、帯域幅と遅延が大きい高速・長距離回線でReno系よりもはるかに効率的に帯域を活用できます。

BBR:損失ではなく帯域幅と遅延を直接測定する新方式

RenoやCubicのような損失ベースのアルゴリズムは「損失が起きて初めて」混雑を判断しますが、これはバッファがすでに満杯になった後にしか反応できないという弱点があります(バッファブロート問題とも関係します)。Googleが開発したBBRは、代わりにボトルネック帯域幅と直近の最小往復遅延時間をリアルタイムで推定し続け、損失が発生する前に最適な送信速度を維持しようとします。Google自身の多くのサービスで採用されており、Linuxカーネルでも選択的に利用できます。

輻輳制御はTCPの信頼性メカニズムの一部にすぎません

輻輳制御に加えて、TCPはシーケンス番号、確認応答、再送タイマーによってデータが欠けることなく順序どおりに届くことを保証しています。輻輳制御が特に扱うのは、ネットワーク全体の公平性と安定性です。これがなければ、一部の強気な送信者が回線を独占し、他の利用者の通信を悪化させてしまいます。

使っているアルゴリズムは確認できても、変更できる場面は限られます

一般消費者向けのOSやブラウザの多くは、輻輳制御アルゴリズムを切り替える設定を公開していません。この設定はクライアント側よりもサーバー側でずっと重要になるためです。Linuxサーバーでは、カーネルのパラメータでCubicやBBRなど利用可能なアルゴリズムを確認・切り替えられることが多く、だからこそアクセスの多いWebサイトや動画配信、CDNの運用者にとって選択が重要になります。

よくある質問

自分のデバイスが使う輻輳制御アルゴリズムを切り替えられますか?

Linuxではカーネルの設定でCubicやBBRなどを選択できます。一方WindowsやmacOS、多くのモバイルOSはこの設定を一般ユーザーに公開しておらず、実際には接続のサーバー側の方が体感速度に与える影響が大きいのが実情です。

UDPで送られる動画通話やゲームの通信にも輻輳制御は関係しますか?

UDP自体には輻輳制御の仕組みがないため、行儀の悪いUDPアプリケーションはネットワークが混雑していてもデータを送り続け、同じ回線を使う他の通信に負担をかけることがあります。QUICのようなUDPの上に構築された最新のプロトコルは、自前の輻輳制御ロジックを実装してより責任ある挙動を実現しています。