輻輳とは｜ネットミリしら

輻輳とは

輻輳は、ネットワークへ処理能力以上の通信が集中し、待ち時間や損失が増える状態です。英語はcongestion（コンジェスチョン）です。道路の渋滞に似ていますが、ネットワークではパケットが送信キューへ並びます。

ある出口が1秒に処理できる量より、流入する量が継続して多ければキューは増え続けます。バッファーが満杯になると新しいパケットを廃棄し、AQMでは満杯前に廃棄・ECN通知して送信側へ減速を促します。

輻輳は回線が完全に切れた状態ではなく、通信が通っていても待ち時間・揺らぎ・損失が増え、送りすぎるほど有効仕事が減ることのある過負荷状態です。

負荷増加から回復までを、キュー・信号・送信制御の連鎖として追う廃棄だけでなく、増え始めた遅延を早い警告として観測する

図2具体的な増減方法はTCP・QUIC等の輻輳制御アルゴリズムで異なります。互換性と公平性を評価します。

キュー用バッファーは瞬間的な到着の偏りを吸収し、すぐ廃棄せず送出できます。しかし継続的に容量を超える負荷はバッファーだけでは解決せず、いずれ満杯になります。

非常に大きいFIFOキューは損失を遅らせる一方、秒単位の待ち時間を作るbufferbloatを起こします。無負荷RTTと負荷時RTTの差を測り、損失が少ないだけで健全と判断しません。

受信ウィンドウは宛先バッファーをあふれさせないためのflow control（フロー・コントロール）です。輻輳ウィンドウは経路へ過剰なデータを入れないためのcongestion control（コンジェスチョン・コントロール）です。

送信可能量は通常、両方の厳しい側で決まります。受信側が余裕でも経路が混雑すれば減速し、経路が空いていても受信側が遅ければ送れません。

新しいTCP接続は、輻輳ウィンドウを制御しながら確認応答に応じて飛行中データを増やします。最初から公称帯域いっぱいを送り、キューを一気にあふれさせないためです。

損失やECNなどの信号を受けると増加を止め、ウィンドウを減らします。具体的なCUBIC、BBRなどのアルゴリズムは帯域・RTT・損失への反応が異なりますが、過負荷と公平性へ配慮する責任があります。

ECN（Explicit Congestion Notification／エクスプリシット・コンジェスチョン・ノーティフィケーション）では、対応するIPパケットへルーターがCongestion Experiencedを印し、受信側から送信側へ通知します。

送信側は損失時と同様に輻輳へ応答します。両端と経路が対応する必要があり、ECNが有効でもすべての損失をなくすものではありません。非輻輳の物理エラーも別に残ります。

UDP自体はTCPのような輻輳ウィンドウを持ちません。しかし音声・映像・ゲームが損失時に送信量を増やし続ければ、他通信を圧迫し自分の品質も悪化させます。

WebRTCやQUICなどUDP上のプロトコルは、受信報告、帯域推定、損失・遅延信号からビットレートや飛行量を調整します。「UDPだから輻輳制御不要」ではありません。

廃棄されるパケットや不要な再送が下流の希少帯域を使うと、投入量を増やしても宛先へ届く有効量が減ります。これが輻輳 collapseの基本像です。

エンドツーエンド輻輳制御、AQM、公平な queuing、適切なシェーピング、容量増強で防ぎます。単にバッファーを増やす、特定フローだけ無制限に優先する対策は全体を悪化させる場合があります。

クラウド同期や配信で上り回線を満たすと、DNS・ゲーム・通話の小さなパケットもWAN出口で待ちます。下り通信のTCP ACKも遅れ、ダウンロードまで不安定になることがあります。

有線直結で無負荷・上り負荷・下り負荷のRTT、損失、スループットを測り、ルーターのキュー制御とリンク別カウンターを確認します。Wi‑Fiだけ悪いならチャンネル競合と再送を別に調べます。