Loading article…
伝送制御プロトコル（TCP）は、輻輳回避を実現するために、加算増加/乗算減少（AIMD）方式のさまざまな側面を含む複数の輻輳制御アルゴリズムのいずれかを使用し、スロースタート[ 1 ]や輻輳ウィンドウ（CWND）などの他の方式も使用します。
TCP輻輳回避アルゴリズムは、インターネットにおける輻輳制御の主要な基盤です。[ 2 ] [ 3 ] [ 4 ]エンドツーエンドの原則によれば、輻輳制御は主にインターネットホストの機能であり、ネットワーク自体の機能ではありません。インターネットに接続するコンピュータのオペレーティングシステムのプロトコルスタックに実装されているアルゴリズムには、いくつかのバリエーションとバージョンがあります。
輻輳崩壊を回避するため、TCPは多面的な輻輳制御戦略を採用しています。各接続において、TCPはCWND（Currency Wender Data Number）を保持し、エンドツーエンドで転送中の未確認パケットの総数を制限します。これは、フロー制御に使用されるTCPのスライディングウィンドウとある程度類似しています。
加算増加/乗算減少（AIMD）アルゴリズムは、閉ループ制御アルゴリズムです。AIMDは、輻輳ウィンドウの線形増加と、輻輳発生時の指数関数的減少を組み合わせたものです。AIMD輻輳制御を使用する複数のフローは、最終的に競合リンクを等量使用するように収束します。[ 5 ]
TCPにおいて、輻輳ウィンドウ（CWND）は、一度に送信できるバイト数を決定する要素の一つです。輻輳ウィンドウは送信側によって管理され、送信側と受信側の間のリンクが過負荷状態になるのを防ぐ手段となります。これは、受信側の過負荷を防ぐために存在する、送信側が管理するスライディングウィンドウとは混同しないでください。輻輳ウィンドウは、リンク上の輻輳量を推定することによって計算されます。
接続が確立されると、各ホストで独立して維持される輻輳ウィンドウは、その接続で許可される最大セグメントサイズ（MSS）の小さな倍数に設定されます。輻輳ウィンドウのさらなる変動は、加算増加/乗算減少（AIMD）方式によって決定されます。これは、すべてのセグメントが受信され、確認応答が送信元に時間通りに到達した場合、ウィンドウサイズに定数が加算されることを意味します。この方式は、さまざまなアルゴリズムに従います。
システム管理者は、 TCP チューニングの一環として、最大ウィンドウサイズ制限を調整したり、加算増加時に追加される定数を調整したりすることができます。
TCP接続を介したデータの流れは、受信側が通知する受信ウィンドウの使用によっても制御されます。送信側は、自身の輻輳ウィンドウと受信ウィンドウよりも小さいデータしか送信できません。
RFC 5681 [ 7 ]で定義されているスロースタートは、 TCP が他のアルゴリズムと組み合わせて使用する輻輳制御戦略の一部であり、ネットワークが転送できる以上のデータを送信することを回避する、つまりネットワークの輻輳を引き起こすことを回避するものです。
スロースタートは、最初は輻輳ウィンドウサイズ（CWND）が1、2、4、または10 MSSで始まります。[ 8 ] [ 3 ]： 1輻輳ウィンドウサイズの値は、受信した確認応答（ACK）ごとに1 MSSずつ増加させることができ、各RTTごとにウィンドウサイズが実質的に2倍になります。[ a ]
パケット損失が検出されるか、受信側の通知ウィンドウ (rwnd) が制限要因になるか、スロースタートしきい値 (ssthresh) に達するまで、スロースタートアルゴリズムによって送信レートが増加します。スロースタートしきい値 (ssthresh) は、スロースタートアルゴリズムまたは輻輳回避アルゴリズムのどちらを使用するかを決定するために使用され、スロースタートを制限するために設定されます。
CWNDがssthreshに達すると、TCPは輻輳回避アルゴリズムに切り替わります。これは、RTTごとに最大1 MSSずつ増加させる必要があります。一般的な計算式は、新しいACKが届くたびにCWNDがMSS * MSS / CWNDだけ増加するというものです。これはほぼ線形に増加し、許容できる近似値を提供します。
パケット損失が発生した場合、TCPはそれがネットワークの輻輳によるものと判断し、ネットワークへの負荷を軽減するための措置を講じます。これらの措置は、使用されるTCP輻輳回避アルゴリズムによって異なります。
TCP送信側が再送タイマーを使用してセグメント損失を検出し、指定されたセグメントがまだ再送信されていない場合、ssthreshの値は、送信済みだが累積的に確認応答されていないデータ量の半分以下、または2 * MSSのいずれか大きい値に設定する必要があります。
スロースタートは、未確認セグメントの原因がネットワークの輻輳にあると仮定します。これは多くのネットワークでは妥当な仮定ですが、セグメントはデータリンク層の伝送品質の悪さなど、他の理由で失われる場合もあります。そのため、スロースタートは無線ネットワークなど、受信状態が悪い状況では性能が低下する可能性があります。
スロースタートプロトコルは、短時間の接続でもパフォーマンスが低下します。古いウェブブラウザは、ウェブサーバーへの短時間の接続を連続して多数作成し、要求されたファイルごとに接続を開閉していました。これにより、ほとんどの接続がスロースタートモードのままになり、応答時間が遅くなりました。この問題を回避するために、最新のブラウザは、複数の接続を同時に開くか、特定のウェブサーバーから要求されたすべてのファイルに対して1つの接続を再利用します。ただし、ウェブ広告、ソーシャルネットワーキングサービスの共有機能、[ 9 ] 、およびウェブ分析のカウンタースクリプトを実装するためにウェブサイトで使用される複数のサードパーティサーバーでは、接続を再利用することはできません。
高速再送は、 TCPの機能強化であり、送信側が失われたセグメントを再送するまでの待機時間を短縮します。TCP送信側は通常、単純なタイマーを使用して失われたセグメントを認識します。特定のセグメントに対する確認応答が指定された時間内（推定往復遅延時間の関数）に受信されない場合、送信側はそのセグメントがネットワーク上で失われたと判断し、セグメントを再送します。
重複確認応答は、高速再送メカニズムの基礎となります。パケットを受信すると、受信したデータの最後の順序付きバイトに対して確認応答が送信されます。順序付きパケットの場合、これは実質的に最後のパケットのシーケンス番号と現在のパケットのペイロード長の合計です。シーケンス内の次のパケットが失われ、シーケンス内の3番目のパケットが受信された場合、受信側はデータの最後の順序付きバイトのみを確認応答できます。これは、最初のパケットに対して確認応答された値と同じです。2番目のパケットが失われ、3番目のパケットが順序付きではないため、データの最後の順序付きバイトは以前と同じままです。したがって、重複確認応答が発生します。送信側はパケットの送信を続け、受信側は4番目と5番目のパケットを受信します。ここでも、2番目のパケットがシーケンスから欠落しているため、最後の順序付きバイトは変更されていません。これらの2つのパケットに対して重複確認応答が送信されます。
送信側が重複した確認応答を3回受信した場合、確認応答で指定された最後のインオーダーバイトに続くデータを含むセグメントが失われたと合理的に判断できます。高速再送機能を備えた送信側は、タイムアウトを待たずにこのパケットを直ちに再送します。受信側は再送されたセグメントを受信すると、受信したデータの最後のインオーダーバイトに対して確認応答を行うことができます。上記の例では、これは5番目のパケットのペイロードの末尾までの確認応答となります。TCPはデフォルトで累積確認応答を使用するため、中間パケットに対して確認応答を行う必要はありません。
RenoとTahoeという名前はBSD UNIXオペレーティングシステムのリリース名であり、少なくとも1996年のKevin FallとSally Floydによる論文では、輻輳制御アルゴリズム（CCA）を指すのに使われていました。[ 10 ]
以下は、以下の特性に基づいた分類の一例です。
この分類体系では、よく知られている混雑回避メカニズムを以下のように分類します。
TCP Tahoe および Reno アルゴリズムは、それぞれが最初に登場した4.3BSDオペレーティングシステムのバージョンまたはフレーバーにちなんで後付けで命名されました(バージョン自体も、ネバダ州のタホ湖と近隣の都市リノにちなんで命名されています)。Tahoe アルゴリズムは、4.3BSD-Tahoe ( CCI Power 6/32 "Tahoe" ミニコンピュータをサポートするために作成された) で初めて登場し、その後 4.3BSD Networking Release 1 の一部として AT&T 以外のライセンス所有者にも利用可能になりました。これにより、広く普及し、実装されることになりました。4.3BSD-Reno で改良が加えられ、その後 Networking Release 2、さらに 4.4BSD-Lite として一般に公開されました。
どちらも再送タイムアウト（RTO）と重複ACKをパケット損失イベントとみなしますが、TahoeとRenoの動作は主に重複ACKへの反応の仕方が異なります。
TahoeとRenoの両方において、ACKがタイムアウトした場合（RTOタイムアウト）、スロースタートが使用され、両方のアルゴリズムで輻輳ウィンドウが1 MSSに縮小されます。
TCP New Renoは、RFC 6582 （ RFC 3782およびRFC 2582の以前の定義を廃止するもの）で定義されており、TCP Renoの高速回復フェーズ中の再送信を改善します。
高速復旧時には、送信ウィンドウを常に満たしておくために、重複したACKが返されるたびに、輻輳ウィンドウの末尾から新しい未送信パケットが送信されます。
Renoとの違いは、New Renoではssthreshをすぐに半分にしない点です。これにより、複数のパケット損失が発生した場合にウィンドウが過度に縮小されるのを防ぐことができます。また、すべてのデータを確認するまで、高速リカバリを終了してssthreshをリセットすることはありません。
再送信後、新たに確認されたデータには次の2つのケースがあります。
これは、リカバリーと呼ばれる変数を使用して、リカバリーが必要なデータ量を記録します。再送信タイムアウト後、リカバリー変数に送信された最大のシーケンス番号を記録し、高速リカバリー手順を終了します。このシーケンス番号が確認されると、TCPは輻輳回避状態に戻ります。
New Renoでは、パケット損失が発生していないにもかかわらず、パケットの順序が3つ以上のパケットシーケンス番号分だけ変更される場合に問題が発生します。この場合、New Renoは誤って高速リカバリモードに入ります。順序が変更されたパケットが配信されると、重複した不要な再送信が即座に発生します。
新しいRenoは、パケットエラー率が低い場合はSACKと同等の性能を発揮し、エラー率が高い場合はRenoを大幅に上回る性能を発揮します。[ 19 ]
1990年代半ばまで、TCPのタイムアウト設定と往復遅延の測定はすべて、送信バッファ内の最後に送信されたパケットのみに基づいていました。アリゾナ大学の研究者ラリー・ピーターソンとローレンス・ブラクモは、送信バッファ内のすべてのパケットに対してタイムアウトを設定し、往復遅延を測定するTCP Vegasを導入しました。さらに、TCP Vegasは輻輳ウィンドウの加算増加を使用します。2012年のさまざまなTCP CCAの比較研究では、TCP Vegasが最もスムーズで、次いでTCP CUBICであることがわかりました。[ 20 ]
TCP Vegasはピーターソンの研究室以外では広く普及しなかったが、 DD-WRTファームウェアv24 SP2のデフォルトの輻輳制御方法として選択された。 [ 21 ]
TCP Hybla [ 22 ] [ 23 ]は、高遅延の地上または衛星無線リンクを使用する TCP 接続のペナルティを解消することを目的としています。Hybla の改善は、輻輳ウィンドウのダイナミクスの分析的評価に基づいています。[ 24 ]
バイナリ増加輻輳制御（BIC）は、ロングファットネットワーク（LFN）として知られる、高遅延の高速ネットワーク向けに最適化されたCCAを備えたTCP実装です。 [ 25 ] BICは、 Linuxカーネル2.6.8から2.6.18でデフォルトで使用されています。
CUBICは、BICよりも攻撃性が低く、より体系的な派生アルゴリズムです。ウィンドウは、前回の輻輳イベントからの経過時間の3次関数であり、変曲点はイベント発生前のウィンドウに設定されます。CUBICは、Linuxカーネルバージョン2.6.19以降でデフォルトで使用されています。
Agile-SD は、実際の Linux カーネル向けに設計された Linux ベースの CCA です。受信側アルゴリズムであり、ローカル エリア ネットワークや光ファイバー ネットワークなどの高速かつ短距離のネットワーク (帯域幅遅延積の低いネットワーク) で帯域幅の利用率を高めるために、アジリティファクター(AF) と呼ばれる新しいメカニズムを使用した損失ベースのアプローチを採用しています。特に、適用するバッファ サイズが小さい場合に効果を発揮します。[ 26 ] NS-2 シミュレータを使用して、Compound TCP (MS Windows のデフォルトの CCA) および CUBIC (Linux のデフォルト) とのパフォーマンスを比較して評価されています。平均スループットの観点から、全体のパフォーマンスを最大 55% 向上させます。
Westwood+ は、TCP Reno の送信側のみの改良版であり、有線および無線ネットワークの両方で TCP 輻輳制御のパフォーマンスを最適化します。TCP Westwood+ は、エンドツーエンドの帯域幅推定に基づいて、輻輳発生後（つまり、重複した確認応答が 3 回発生した後、またはタイムアウトが発生した後）に輻輳ウィンドウとスロースタートしきい値を設定します。帯域幅は、応答パケットの返送率を平均することで推定されます。重複した ACK が 3 回発生した後に輻輳ウィンドウを無条件に半分にする TCP Reno とは対照的に、TCP Westwood+ は、輻輳が発生した時点で利用可能な帯域幅の推定値を考慮して、スロースタートしきい値と輻輳ウィンドウを適応的に設定します。Reno および New Reno と比較して、Westwood+ は無線リンクのスループットを大幅に向上させ、有線ネットワークの公平性を改善します。
Compound TCPは、Microsoftが実装したTCPであり、2つの異なる輻輳ウィンドウを同時に維持することで、LFN（低周波ネットワーク）上での良好なパフォーマンスを実現しつつ、公平性を損なうことを防ぎます。Microsoft Windows VistaおよびWindows Server 2008以降のWindowsバージョンで広く採用されており、それ以前のMicrosoft WindowsバージョンやLinuxにも移植されています。
TCP 比例レート削減 (PRR) [ 27 ]は、リカバリ中に送信されるデータの精度を向上させるために設計されたアルゴリズムです。このアルゴリズムは、リカバリ後のウィンドウサイズがスロースタートのしきい値にできるだけ近くなるようにします。Google が行ったテストでは、 PRR により平均レイテンシが 3 ～ 10% 削減され、リカバリタイムアウトが 5% 削減されました。[ 28 ] PRR は、 Linux カーネルのバージョン 3.2 以降で利用可能です。[ 29 ]
ボトルネック帯域幅と往復伝搬時間 (BBR) は、2016 年に Google で開発された CCA です。[ 30 ]ほとんどの CCA はパケット損失に基づいて輻輳や伝送速度の低下を検出するという点で損失ベースですが、BBR はTCP Vegasと同様にモデルベースです。このアルゴリズムは、ネットワークが最新の送信データパケットを配信したときの最大帯域幅と往復時間を使用して、ネットワークのモデルを構築します。パケット配信の累積または選択的確認応答ごとに、データパケットの送信からそのパケットの確認応答までの時間間隔で配信されたデータ量を記録するレートサンプルが生成されます。[ 31 ]
YouTubeで実装されたBBRv1 は、平均で 4% 高いネットワーク スループットを実現し、一部の国では最大 14% 向上しました。[ 32 ] BBR は Linux 4.9 以降、Linux TCP で利用可能です。[ 33 ] QUICでも利用可能です。[ 34 ]
BBR バージョン 1 (BBRv1) の非 BBR ストリームに対する公平性については議論がある。Google のプレゼンテーションでは BBRv1 が CUBIC とうまく共存していることが示されているが、[ 30 ] Geoff Huston や Hock、Bless、Zitterbart などの研究者は、他のストリームに対して不公平であり、スケーラブルではないことを発見した。[ 35 ] Hock らはまた、Linux 4.9 の BBR 実装に「キューイング遅延の増加、不公平、大規模なパケット損失などの深刻な固有の問題」があることを発見した。[ 36 ] Soheil Abbasloo ら (C2TCP の著者) は、BBRv1 がセルラー ネットワークなどの動的な環境ではうまく機能しないことを示している。[ 11 ] [ 12 ]また、BBR には不公平の問題があることも示している。例えば、CUBICフロー（Linux、Android、MacOSのデフォルトのTCP実装）がネットワーク内でBBRフローと共存する場合、BBRフローがCUBICフローを支配し、リンク帯域幅全体を取得する可能性があります（[ 11 ]の図18を参照）。
バージョン 2 では、CUBIC などの損失ベースの輻輳管理と並行して動作する場合の不公平の問題に対処しようとしています。[ 37 ] BBRv2 では、BBRv1 で使用されているモデルが拡張され、パケット損失に関する情報と明示的輻輳通知(ECN) からの情報が含まれるようになっています。[ 38 ] BBRv2 は、BBRv1 よりもスループットが低い場合もありますが、一般的にはグッドプットが優れていると考えられています。Windows 11 バージョン 24H2およびWindows Server 2025は BBRv2 をサポートしていますが、デフォルトでは有効になっていない場合があります。
バージョン 3 (BBRv3) では、BBRv2 の 2 つのバグ (帯域幅プロービングの早期終了、帯域幅の収束) が修正され、パフォーマンスの調整が行われています。また、データセンター内部リンク向けに最適化された BBR.Swift というバリアントもあり、これは network_RTT (受信遅延を除く) を主要な輻輳制御信号として使用します。[ 38 ]
Cellular Controlled Delay TCP (C2TCP) [ 11 ] [ 12 ]は、ネットワーク デバイスに変更を加えることなく、さまざまなアプリケーションのさまざまなQoS要件を満たすことができる柔軟なエンドツーエンド TCP アプローチが不足していることから着想を得ました。C2TCP は、現在のLTEや将来の5Gセルラー ネットワークなどの非常に動的な環境で、仮想現実、ビデオ会議、オンライン ゲーム、車載通信システムなどのアプリケーションの超低遅延と高帯域幅の要件を満たすことを目的としています。C2TCP は、損失ベースの TCP (Reno、NewReno、CUBIC、BICなど) のアドオンとして機能し、サーバー側にインストールするだけで、パケットの平均遅延をアプリケーションによって設定された目的の遅延に制限します。
NYUの研究者[ 39 ]は、C2TCPがさまざまな最先端のTCP方式の遅延と遅延変動性能を上回ることを示しました。たとえば、BBR、CUBIC、およびWestwoodと比較して、C2TCPはさまざまなセルラーネットワーク環境でパケットの平均遅延をそれぞれ約250%、900%、および700%削減することを示しました。[ 11 ]
Elastic-TCPは、クラウドコンピューティングをサポートする高BDPネットワークでの帯域幅利用率を向上させるために、2019年2月に提案されました。これはLinuxカーネル向けに設計されたLinuxベースのCCAです。受信側アルゴリズムであり、ウィンドウ相関重み関数（WWF）と呼ばれる新しいメカニズムを使用して損失遅延ベースのアプローチを採用しています。人間の調整を必要とせずに、さまざまなネットワーク特性に対応できる高いレベルの弾力性を備えています。NS-2シミュレータとテストベッドを使用して、Compound TCP（MS WindowsのデフォルトCCA）、CUBIC（Linuxのデフォルト）、TCP-BBR（Googleが使用するLinux 4.9のデフォルト）とのパフォーマンスを比較して評価されています。Elastic-TCPは、平均スループット、損失率、遅延の観点から、全体的なパフォーマンスを大幅に向上させます。[ 40 ]
Soheil Abbasloo らは、マルチアクセスエッジコンピューティング(MEC) を対象とした議論の多いTCP設計である NATCP (Network-Assisted TCP) [ 13 ]を提案しました。NATCP の重要なアイデアは、ネットワークの特性が事前にわかっていれば、TCP は異なる設計になっていただろうということです。そのため、NATCP は、現在の MEC ベースのセルラーアーキテクチャで利用可能な機能と特性を利用して、TCP のパフォーマンスを最適なパフォーマンスに近づけます。NATCP は、ネットワークから近くのサーバーへの帯域外フィードバックを使用します。セルラーアクセスリンクの容量とネットワークの最小 RTT を含むネットワークからのフィードバックは、サーバーが送信レートを調整するようにガイドします。予備的な結果が示すように、NATCP は最先端の TCP 方式を上回ります。[ 13 ] [ 41 ]
TCP New Renoは最も一般的に実装されているアルゴリズムであり、SACKサポートは非常に一般的で、Reno/New Renoの拡張です。その他のほとんどは、まだ評価が必要な競合提案です。2.6.8以降、Linuxカーネルはデフォルトの実装をNew RenoからBICに切り替えました。デフォルトの実装は、2.6.19バージョンで再びCUBICに変更されました。FreeBSDバージョン14.X以降も、デフォルトのアルゴリズムとしてCUBICを使用しています。[ 53 ]以前のバージョンではNew Renoが使用されていました。ただし、FreeBSDは他の多くの選択肢をサポートしています。[ 54 ]
帯域幅と遅延の積がフローごとに増加すると、キューイング方式に関係なく、TCPは非効率になり、不安定になりやすくなります。これは、インターネットが超高帯域幅の光リンクを取り入れるように進化するにつれて、ますます重要になってきます。
TCPインタラクティブ（iTCP）[ 55 ]は、アプリケーションがTCPイベントを購読し、それに応じて応答することを可能にし、TCPレイヤーの外部からTCPにさまざまな機能拡張を可能にします。ほとんどのTCP輻輳制御方式は内部で動作します。iTCPはさらに、ソース生成レートの制御など、高度なアプリケーションが輻輳制御に直接参加できるようにします。
Zeta-TCPは、遅延と損失率の両方の指標から輻輳を検出します。グッドプットを最大化するために、Zeta-TCPは輻輳の可能性に基づいて異なる輻輳ウィンドウバックオフ戦略を適用します。また、パケット損失を正確に検出し、再送信タイムアウトを回避し、受信（ダウンロード）トラフィックを加速および制御するためのその他の改善も行っています。[ 56 ]
CCAは、ネットワーク認識、つまりこれらのアルゴリズムがネットワークの状態をどの程度認識しているかという点に関連して分類することができます。これは、ブラックボックス、グレーボックス、グリーンボックスの3つの主要なカテゴリで構成されています。[ 57 ]
ブラックボックスアルゴリズムは、ネットワークの輻輳制御において、盲目的な手法を提供する。これらのアルゴリズムは、輻輳発生時に受け取るバイナリフィードバックのみに基づいて動作し、管理対象ネットワークの状態に関するいかなる知識も前提としない。
グレーボックスアルゴリズムは、RTT変動やパケット到着率などの時間ベースの測定値を使用して、帯域幅、フロー競合、およびネットワークの状態に関するその他の情報の測定値と推定値を取得します。
グリーンボックスアルゴリズムは、システム実行中の任意の時点において、各フローに割り当てられるべき総帯域幅の公平な割合を測定する、二峰性の輻輳制御手法を提供する。
以下のアルゴリズムでは、TCPパケット構造にカスタムフィールドを追加する必要があります。
{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）