TCP 輻輳制御は、変化する接続をどのように決定するかを決定します。 ネットワーク負荷 データレートを調整し、実際のホスティング設定でアルゴリズムがどのように機能するかを検証します。この比較では、スループット、遅延、公平性に対する具体的な影響を示します。 ウェブホスティング, 、ストリーミング、クラウドワークロード。.
中心点
この記事を効果的に読むために、重要な点を簡単にまとめて、後で全部を文脈で説明します。損失ベースの手法とモデルベースの手法は、反応が大きく違うから、はっきり区別します。cwnd、RTT、ペーシングが、パフォーマンスや 公平性 決定する。測定結果を整理して、直感で判断しないようにします。ホスティング、コンテナ、グローバルについて、実用的な推奨事項をまとめて締めくくります。 ユーザー.
- AIMD cwnd を制御し、損失に対応します。
- CUBIC 大きなRTTでも安定したパフォーマンスを発揮
- ブートレコード モデルを活用し、キューと遅延を削減
- BIC ドロップでネット上でポイントを獲得
- ハイブラ 長い回線（衛星）の速度を上げる
輻輳制御が制御するもの：cwnd、RTT、損失信号
基礎から始めましょう。基礎は、その後の選択すべてに影響を与えるからです。輻輳ウィンドウ (cwnd) 確認のないバイト数を制限し、AIMD は損失が発生するまで cwnd を段階的に拡大します。RTT は、確認が返ってくる速度と、アルゴリズムがどれだけ積極的に拡大できるかを決定します。以前は、タイムアウトとトリプル重複 ACK から損失信号が発生していましたが、現在では、キューの深さ、最小 RTT、測定されたボトルネック帯域幅も考慮されます。 cwnd、RTT、および損失の解釈を理解すれば、スループット、遅延、および ジッター すぐに良くなる。.
振り返り：リノ、ニューリノ、そしてベガスの日常
Reno は、開始時にスロースタートを使用し、その後直線的な増加に移行しますが、損失が発生するとウィンドウサイズを大幅に半減させます。NewReno は、ウィンドウごとの複数の損失をより効率的に修復するため、エラー率が中程度の場合に特に有効です。 Vegas は、RTT を通じて予想スループットと実際のスループットを比較し、損失を防ぐために早期に減速します。この慎重な対応によりキューは小さくなりますが、損失ベースのフローが並行してより積極的に送信する場合、スループットが低下します。説明のつかないタイムアウトや重複 ACK が発生した場合は、まず パケット損失の分析 そして、アルゴリズムを トポロジー 適切に選択する。.
High-BW-RTT：BIC と CUBIC の比較
BIC は、損失のない最高の cwnd にバイナリで近づき、わずかなエラーがあってもそのレートを驚くほど安定に保ちます。低レイテンシでドロップレートが 10^-4 程度のラボでは、BIC は 8 Gbit/s 以上のスループット値を達成しましたが、従来のアルゴリズムは変動が見られました。 CUBIC は、cwnd を立方関数で制御し、長い RTT をより有効に活用するため、BIC に代わって標準アルゴリズムとなりました。この曲線は、損失イベント発生後、最初は緩やかに上昇し、その後顕著に加速し、最終的な最大レート付近で再び緩やかになります。長い経路を持つネットワークでは、CUBIC を使用することで、良好なスループットを維持しながら、より高い利用率を達成できる場合が多くあります。 計画性 レイテンシー。.
モデルベース：BBR、ペーシング、バッファブロート
BBR は、最小 RTT と測定されたボトルネック帯域幅のモデルを使用し、cwnd を帯域幅遅延積の約 2 倍に設定し、パケットを均等にペース調整します。この戦略により、キューの過負荷が防止され、わずかな損失が発生した場合でも遅延が短く抑えられます。 無線品質が不安定な設定や混合パスでは、BBR はドロップごとに反射的に反応しないため、グッドプットは高いまま維持されます。バージョン 1 は非常に高速ですが、小さなバッファでは CUBIC と競合し、やや不公平な分配を示す場合があります。私は BBR を BBR CUBIC ホスティング プライマリフローにはランドスケープを好み、互換性のあるフォールバックとして CUBIC を実行します。.
衛星と無線：Hybla、Westwood、PCC
Hybla は、短い基準 RTT があるかのように cwnd をスケーリングすることで、高い RTT の欠点を補います。これにより、衛星などの長距離通信は、より迅速に利用可能な速度に上昇し、その速度を確実に維持することができます。 Westwood は、ACK レートから利用可能な帯域幅を推定し、損失後の cwnd の削減幅を小さくすることで、ランダムエラーが発生する無線ネットワークで効果を発揮します。PCC はさらに一歩進んで、短い実験を通じて効用値を最適化し、高いグッドプットとレイテンシの組み合わせを実現します。異種ネットワークでは モビリティ 複雑な QoS ルールに取り組む前に、Hybla と Westwood を優先的にテストします。.
性能比較：測定値と公平性
比較すると、レイテンシとエラー率が異なる場合、プロファイルが大きく異なることがわかります。RTT が低い場合、BIC は純粋なスループット競争でしばしば優位に立ち、CUBIC は時間経過に伴うレートと動作の信頼性の高い組み合わせを提供します。 RTT が非常に長い場合、CUBIC は待機時間を成長にうまく変換するため、Reno や NewReno よりも明らかに優れています。BBR はキューを空に保ち、常に低い遅延を実現しますが、バッファサイズに応じて再送信が増えます。並列フローの場合、CUBIC は通常、公平な分割を示し、BIC は回線を 定員.
| アルゴリズム | 原則 | 強さ | 弱さ | こんな人におすすめ |
|---|---|---|---|---|
| リノ / ニューリノ | 損失ベース、AIMD | 単純な行動 | 高いRTTでは低速 | レガシースタック、, トラブルシューティング |
| ベガス | RTTベース | 早期の渋滞回避 | スループットの低下 | 定常的なレイテンシー |
| BIC | バイナリ検索 | ドロップ時の高いグッドプット | 他者に対して攻撃的 | 低いRTT、エラー率 |
| CUBIC | 立方時間関数 | 公正さ | ドロップのばらつき | 長い道、データセンター |
| ブートレコード | モデルベース、ペーシング | 低遅延 | 小さなバッファでは不公平 | ホスティング、グローバルユーザー |
| ハイブラ | RTT補償 | 迅速な立ち上げ | 特殊なケースの性質 | 衛星、, 海事 |
実践ガイド：レイテンシ、損失、目標による選択
私は、低レイテンシ、最大グッドプット、または多数のフローのバランスという明確な目標を掲げて、あらゆる決定を開始します。バッファサイズに厳しい制限があり、レイテンシの要件が厳しい場合は、まず BBR を採用します。長いパスが主流で、複数のホストが共存している場合は、CUBIC 以外には選択肢がありません。 ドロップパターンが明確に観察できるネットワークでは、公平性が二次的な問題である限り、BIC は引き続き印象的なレートを実現します。衛星および非常に高い RTT パスコストの場合、Hybla は典型的なランプアップの欠点を解消し、高速な ペイロード.
Linux、Windows、コンテナ：アクティベーションとチューニング
Linux では、sysctl net.ipv4.tcp_congestion_control を使用してアクティブなアルゴリズムを確認し、sysctl net.ipv4.tcp_congestion_control=bbr を使用して意図的に設定します。CUBIC の場合、カーネルのデフォルト設定に注意しますが、ホストキューを緩和する場合は net.core.default_qdisc およびペーシングパラメータを調整します。 コンテナでは、ネームスペースがすべてのキューを分離するわけではないため、設定をホストに転送します。Windows の最新バージョンでは、適切なエディションで BBR を有効にできますが、古いシステムでは引き続き CUBIC または Compound を使用します。堅牢なシステムと キュー設定を変更すると、どのアルゴリズムも効果が著しく低下します。.
ウェブホスティングの展望：マルチフローの公平性とグッドプット
ホスティングクラスタでは、単一の転送の最高値ではなく、多数の同時フローの合計が重要です。CUBIC は接続を予測可能にし、ほとんどの場合、容量を公平に分配するため、高密度のマルチテナントシナリオに有利です。BBR はキューを削減し、API や動的 Web サイトの応答時間を短縮します。 プロトコルのオーバーヘッドを考慮する場合は、HTTP バージョンでトランスポートをテストしてください。私の出発点は HTTP/3とHTTP/2の比較 選択したCC方式との相互作用において。グローバルユーザーにとっては、反応時間が知覚に直接影響するため、低レイテンシのピークを好みます。 スピード 特徴づけられる。.
QUIC と BBR：TCP を超えた影響力
QUIC は、UDP ベース独自の輻輳制御機能を備え、BBR と同様の原則、たとえばペーシングや RTT 監視などを利用しています。これにより、最新のスタックでは、パフォーマンスが TCP からアプリケーション層へと徐々に移行しています。これにより自由度は高まりますが、パス、ホスト、アプリケーションレベルでの正確な測定が必要となります。計画を立てる際には、以下をお勧めします。 QUICプロトコル 実際の負荷プロファイルで CUBIC/BBR‑TCP と比較します。これにより、キューの形成が発生している場所や、ペーシングや シェーピング 滑らかさ。.
AQM、ECN、バッファ規律：アルゴリズムとの相互作用
スタック制御は、ネットワークデバイスのキュー管理と連動することで、その効果を最大限に発揮します。従来のテールドロップは、バッファをいっぱいに満たしてからパケットを突然破棄するため、レイテンシのピークや同期効果が生じます。 CoDel や FQ‑CoDel などのアクティブキュー管理 (AQM) は、パケットを早期にマークまたは破棄し、フロー間で容量をより公平に分配します。これは、すべてのプロセスにメリットがあります。CUBIC はバーストドロップによる cwnd の損失が少なくなり、BBR はその ペース設定キューが「爆発」しないため、戦略がより安定する。.
ECN（Explicit Congestion Notification）がこの状況を補完します。パケットを廃棄する代わりに、ルーターは CE ビットで輻輳をマークし、エンドポイントは再送信を必要とせずにスロットリングを行います。これにより、損失ベースのアルゴリズムはより早く、より穏やかに反応し、BBR などのモデルベースの手法は、最小 RTT のコンテキストで信号を解釈します。 データセンターでは、一貫した ECN による DCTCP により、高負荷時でも非常に低いキューイング遅延を実現しています。WAN では、ECN を選択的に使用しています。つまり、パスがマークを一貫して通過し、ミドルボックスが介入しない場合にのみ使用しています。混合パブリックネットワークでは、バッファを単に拡大するのではなく、AQM を適切に構成することが依然として重要です。.
バースト、オフロード、ホスト側のペーシング
パフォーマンスの低下は、ホストでの送信バーストによって発生することが多い。大規模なオフロード（TSO/GSO）は、セグメントを非常に大きなフレームにまとめます。 ペース設定 これらのパケットは短いピークで放出され、スイッチキューを埋めます。そのため、Linux では、デフォルトの qdisc として sch_fq または FQ‑CoDel を設定し、CC アルゴリズムが指定するペーシングレートを使用しています。BBR は特にこの恩恵を受けていますが、CUBIC も安定しています。 NIC リングバッファが大きすぎたり、txqueuelen が高すぎたりすると、ホストのキューが長くなります。私は適度な値を選択し、tc -s qdisc を使用して、ドロップや ECN マークが発生していないかを監視しています。.
受信側では、GRO/LRO が小さなフローのレイテンシに影響を与えます。API を多用するワークロードでは、NIC やカーネルに応じてこれらのオフロードをテストまたは抑制し、ACK の処理を高速化することをお勧めします。コンテナ設定では、veth ペアとホスト Qdisc を確認します。キューはネームスペースではなく、ホストインターフェース上に存在します。 帯域幅管理に cgroups を使用する場合は、CC および AQM と一貫した制限を設定する必要があります。そうしないと、フロー間で予測不可能な干渉が発生します。.
ワークロードプロファイル：短いフロー、エレファント、ストリーミング
すべてのアプリケーションが同じような輻輳制御を必要とするわけではありません。「Mice」フロー（小規模な転送）は、Web API や動的なページで主流です。ここでは、接続が使用段階に入るまでの速度と、テールレイテンシがどれだけ低く抑えられるかが重要になります。BBR はキューを平坦に保ち、短命のフローを優先しますが、CUBIC は公平な容量分配で安定した平均値を提供します。 初期ウィンドウサイズ (initcwnd) および遅延 ACK 設定は、最初の RTT に影響を与えます。保守的なデフォルト設定はバーストから保護しますが、最初の数キロバイトの速度を過度に低下させてはなりません。.
„「エレファント」フロー（バックアップ、レプリケーション、大容量ダウンロード）は、長期間にわたる安定した負荷を必要とします。CUBIC は、さまざまな RTT で堅牢にスケーリングし、並列フローと公平に分割します。BIC は、既知のドロップパターンを持つ制御されたネットワークで最大レートを提供しますが、共存には欠点があります。 ライブストリーミングやリアルタイムの対話（VoIP、ゲーム）では、私は常にスタンディングキューを避けています。バッファが小さく、AQM が機能している場合は、BBR が第一選択肢です。ナグル対話（TCP_NODELAY）とアプリケーションのバッチ処理が影響します。多くの小さな書き込みを生成する場合は、ナグルを意図的に無効にし、ペーシングを細かい粒度で処理すべきです。.
測定方法：現実的なテストと意味のある指標
良い決定には再現性のある測定が必要です。私は、合成負荷と実際の経路条件（テストリンクなどでの RTT、ジッター、損失の制御されたエミュレーション）および実際の宛先ロケーションを組み合わせています。帯域幅はグッドプットとして測定し、RTT の推移、再送信、順不同の割合と相関させます。 P50/P95/P99 レイテンシは、平均値よりも多くの情報を提供します。特に API 応答時間と対話性に関してはそうです。TCP については、cwnd の推移と pacing_rate を確認し、ホスト側の Qdisc 統計と CPU 飽和度をチェックして、ボトルネックを正しく特定します。.
個別のテストは誤解を招きやすい：ホストごとの並列フローとクロストラフィックは、現実的な競合状況を作り出す。 時間帯、ピアリング経路、電波状態は変化するため、私は時系列で測定を繰り返し、わずかなドロップ率に対する感度を検証します。QUIC については、アプリケーション層とトランスポート層を明確に分離して評価するために、TCP に対して同一のワークロードを反映しています。測定値が障害下でも安定している場合にのみ、私は本番環境での選択を決定します。.
よくあるエラーと迅速な対処法
負荷時のRTTが絶えず上昇し、同時にグッドプットが急落している場合は、以下のことを示唆しています。 バッファブロート 解決策：AQM を有効にし、ホストペーシングを強化し、必要に応じて BBR を使用します。 明確なドロップパターンがない多くの再送信は、再順序付けまたは ACK 圧縮を意味します。FQ ベースの Qdisc およびクリーンなペース設定が有効です。ACK が届かない突然のハングは、多くの場合、パス MTU 問題を示しています。MTU プローブを有効にし、関連するトランジションで MSS クランプを設定します。.
河川間の不公平な分配は、個々の接続が恒久的に有利である場合に発生します。CUBIC は、従来のロスアルゴリズムに比べて RTT の公平性を改善しますが、BBR は厳格なバッファの規律を必要とします。バッファが小さい場合、より細かいペース調整を行うか、CUBIC に戻すことで共存を図ることができます。 コンテナ環境では、veth エンドに「隠れた」キューが発生します。Qdisc および cgroup の制限が調整されていない場合、輻輳はアプリケーションから遠く離れたホストに移動します。.
運用上のガイドライン：チームおよびプラットフォームに関する決定
私は、プラットフォームの標準にスタック制御を組み込んでいます。統一された Qdisc デフォルト、クラスタごとに定義された CC プロファイル、および例外のためのプレイブックです。グローバルな ユーザー 私は、レイテンシの感度に応じてワークロードを分類しています。フロントエンド API は BBR と厳格な AQM を優先し、バルク転送は CUBIC を優先します。テレメトリは必須です。RTT 分布、グッドプット、再送信、ECN 比率を時系列で記録します。 チームは、パーセンテージ実験によって変更を展開し、平均値だけでなく P95/P99 も比較します。これにより、CC の決定は再現性があり、理解可能になり、直感的な判断ではなくなります。.
決定のためのチェックリスト
まず、RTT スパンとエラー率をチェックするよ。これらは動作を左右するからね。それから、レイテンシとスループットのどちらを優先するかを決めて、その指標に合わせてテストするんだ。次のステップでは、並行フローを使って公平性を測定して、運用中に予期せぬ事態が起こらないようにするよ。それから、ホストとゲートウェイのバッファサイズ、AQM 手法、ペース設定をチェックするんだ。 最後に、負荷がかかった状態で、実際のユーザーと実際の ルート 運ぶ。.
ショートバランスシート
Reno と NewReno は明確な基準動作を提供しますが、長いパスでは速度が低下します。CUBIC は、長い RTT をうまく活用し、公平に動作するため、ほぼすべての Linux ホスティングの標準として採用されています。BIC は、近隣よりも最大スループットが重要な、顕著なドロップが発生するネットワークで優れた性能を発揮します。 BBR は低遅延と安定した応答時間を実現しますが、バッファと共存に注意を払う必要があります。目標、パスの特性、ホストキューを適切に調整すれば、輻輳制御を真の レバー ユーザーエクスペリエンスとコストのために。.
