公開2026.07.14更新2026.09.04 24 人が閲覧（直近 30 日）インフラ・クラウド

輻輳とは？ネットワーク混雑の仕組み・原因・TCP輻輳制御から対策の判断まで実装者向けに解説

輻輳（ふくそう）とは、ネットワークの特定の経路にトラフィックが集中し、ルータやスイッチが処理しきれずにバッファ（順番待ちの一時保管領域）が溢れ、パケットロスや遅延が起きている状態を指します。道路の渋滞と同じで、流したいデータ量がリンクの通せる帯域を超えると、余ったパケットは待ち行列に積まれ、待ち行列が満杯になれば捨てられます。この記事では、輻輳がどういう仕組みで起きるのか、帯域幅やレイテンシーと輻輳がどう結びつくのか、TCPがスロースタートやCUBIC/BBRといったアルゴリズムでどのように送信量を加減しているのかを実装者の解像度で整理する構成です。加えて、手元のLinuxでss・sysctl・tcを叩いて輻輳の実態を採取する手順と、RFCなど一次情報の該当箇所も示します。そのうえで、実務で最も誤解されがちな「帯域を増やせば輻輳は消える」「バッファは大きいほど安心」という前提を否定し、QoS・リンク束ね・監視をどの順番で入れるべきかを、採用する場面と見送る場面に分けて言い切ります。

まとめ：輻輳の仕組みと原因・TCP輻輳制御・対策の判断を先に整理した結論

輻輳の本質は「ある区間に流れ込むトラフィックが、その区間の通せる帯域とバッファの容量を超えた状態」です。超過ぶんは待ち行列に積まれて遅延（キューイング遅延）となり、行列が満杯になるとパケットが捨てられます。捨てられたパケットは送信側が再送するため、対処を誤ると再送がさらにトラフィックを増やし、輻輳が輻輳を呼ぶ悪循環（輻輳崩壊）に陥るのが厄介な点です。これを防ぐ主役がTCPの輻輳制御で、送信側はネットワークの空き容量を直接知らないまま、パケットロスや遅延の増加を手がかりに送信量（ウィンドウ）を増減させ、使える帯域を推測しながら流します。基本動作はRFC 5681「TCP Congestion Control」に標準として定義されており、スロースタート・輻輳回避・高速再転送・高速回復の4つが挙動の骨格です。

設計判断の勘所は3つあります。第一に、帯域増強は万能ではありません。バッファが過大な機器では、帯域を足してもキューが深く積まれ続けるバッファブロートが起き、パケットは落ちないのに遅延だけが悪化します。第二に、輻輳制御アルゴリズムには性格差があるという事実です。パケットロスを合図に速度を落とすLossベース（Linuxの既定であるcubic系）と、遅延や推定帯域を手がかりにするBBR系では、ロスの多い無線回線や高遅延回線での挙動が変わります。第三に、対策には順序がある点です。まず監視で「どこが・どのくらい・いつ詰まるか」を可視化し、恒常的な帯域不足ならリンク束ね（LAG）や回線増速、瞬間的な競合なら優先制御（QoS）、というふうに原因に合った手を選びます。可視化の指標設計そのものに迷うなら、メトリクス監視の4種のメトリック型とアラート閾値の設計を土台にすると、リンク使用率・再送率・キュー破棄をどの型で取るかの判断軸が明確です。オンプレの機器からクラウド側の帯域・QoS設計までを一体で組みたい場合は、インフラ構築（AWS/GCP/Azure）の相談窓口で構成方針から相談すると、帯域と遅延のどちらがボトルネックかを取り違えたまま投資する事故を避けられます。

輻輳の仕組み：帯域超過でバッファが溢れパケットロスと遅延が起きる構造

輻輳を「なんとなく混んでいる状態」で捉えると対策がぶれます。まず、トラフィックがどこで待たされ、どこで捨てられるのかという物理的な流れを押さえると、後段の輻輳制御や対策が一本の線でつながります。

輻輳とは何か：リンク帯域を超えた超過分が待ち行列に積まれる状態

ネットワークの各リンクには、1秒あたりに通せるデータ量の上限（帯域幅）があります。ルータやスイッチは、出口のリンクが空くまでパケットを一時的にバッファへ積んで順番待ちさせます。到着するパケットの合計がリンクの帯域を下回っている間は、待ち行列は短く、遅延もわずかです。到着が帯域を上回り始めると、処理しきれないパケットがバッファに溜まり続け、待ち行列が長くなります。バッファが満杯になった時点で、それ以上入ってきたパケットは行き場を失って破棄されます。これがパケットロスであり、輻輳が「起きている」と言える状態です。輻輳は回線そのものが壊れる現象ではなく、需要（流したい量）が供給（通せる量）を超えたときに必ず起こる、確率的で日常的な現象だと捉えるのが出発点になります。輻輳が観測されるのはIP・TCPの層であるため、どの階層の話をしているのかを見失いそうなときはTCP/IPの4階層モデルとOSI参照モデルの違いで位置を確かめておくと、機器側の対処と端末側の対処を混同せずに済みます。

帯域幅・スループット・レイテンシーと輻輳が同時に結びつく相互関係

輻輳は、実測できる3つの指標に同時に影響します。帯域幅は理論上の通せる量、スループットは実際に通った量で、輻輳が起きるとロスと再送でスループットは帯域幅より低く沈むのが実態です。そしてレイテンシー（遅延）は、待ち行列が伸びるぶんだけ増えます。ここが実装者にとって肝で、輻輳の初期症状はパケットロスより先に「遅延の増加」として現れることが多いのです。バッファに積まれて待つ時間そのものがキューイング遅延として応答時間に上乗せされるため、ロスが出ていなくても体感が悪化します。輻輳による遅延の膨らみを応答時間の観点から切り分けたい場合は、レイテンシーの原因と目安・改善方法を併せて押さえると、どこまでが伝送距離由来で、どこからが輻輳（キューイング）由来かを分けた診断が可能です。もう一つ覚えておきたいのが帯域遅延積（BDP）で、帯域とRTTの積が「経路に同時に置いておけるデータ量」に相当します。送信側のウィンドウがBDPより小さければ帯域を使い切れず、BDPを大きく超えればバッファに積まれるだけで遅延が伸びる、という見取り図になります。

輻輳崩壊：再送が再送を呼び全体のスループットが急落する悪循環

輻輳が厄介なのは、放置すると自己増幅する点です。パケットが捨てられると、送信側は「届かなかった」とみなして再送します。ところが元の輻輳が解消していないところへ再送ぶんが上乗せされると、待ち行列はさらに伸び、より多くのパケットが捨てられ、さらに再送が増えるという二次災害です。この連鎖が進むと、リンクは満杯なのに有効に届くデータはほとんど無い、という状態に落ち込みます。この状態が、いわゆる輻輳崩壊（congestion collapse）です。現象そのものは1984年のRFC 896「Congestion Control in IP/TCP Internetworks」で既に報告されており、輻輳制御をインターネット全体の前提として位置づけたRFC 2914「Congestion Control Principles」（BCP 41）が、崩壊を避けるために送信側が守るべき原則をまとめています。再送のたびに待ち時間を伸ばしていくバックオフや、後述の輻輳制御は、この悪循環を断ち切るために設計された仕組みです。アプリケーション側で「失敗したら即リトライ」を素朴に書くと、この崩壊を人為的に再現してしまう点に注意します。

輻輳の原因：トラフィック集中とバッファ設計・再送設計が招く混雑

輻輳の対策を効かせるには、詰まりの発生源を取り違えないことが先決です。原因を「帯域が足りない」の一言で片づけず、集中の仕方・バッファの設計・上位層の振る舞いに分けて見ていきます。

ボトルネックリンクへの集中とマイクロバーストによる瞬間的な溢れ

輻輳は、経路の中で最も細いリンク（ボトルネック）に需要が集まったときに生じます。典型は、多数のクライアントを収容するアクセススイッチから上位へ向かうアップリンクや、拠点間を結ぶWAN回線、データセンターの南北トラフィックが集まる境界です。平均帯域には余裕があっても、ミリ秒未満の短時間に送信が重なるマイクロバーストで瞬間的にバッファが溢れることもあり、この場合は分単位の平均グラフを見ても原因が見えません。マイクロバーストを疑うなら、機器の出力キューの破棄カウンタ（output drops）やマイクロバースト計測に対応した監視で、秒未満の粒度を把握する必要があります。「平均使用率は50%なのにロスが出る」ときは、平均ではなくピークの重なりを疑うのが定石です。

バッファブロート：過大なバッファがロスを隠して遅延だけを膨らませる

「バッファは大きいほど安心」という直感は、しばしば裏目に出ます。バッファが過大な機器では、輻輳時にパケットが捨てられずに延々と待ち行列へ積まれ続け、パケットロスは見かけ上減る一方で、キューイング遅延が数百ミリ秒から秒単位まで膨らむのが特徴です。この状態をバッファブロート（bufferbloat）と呼びます。TCPの多くのアルゴリズムはロスを輻輳の合図に使うため、ロスが出ない過大バッファではブレーキが利かず、遅延だけが悪化してオンライン会議や対話型通信の体感を壊します。対処は、バッファをむやみに増やさず、後述のAQM（能動的キュー管理）で待ち行列が伸びる前に早めにパケットを落とすかECNで通知することです。バッファブロートは、帯域を足しても消えない典型的な「設計由来の輻輳」であり、機器のバッファ設定を見直すまで解決しません。

アプリケーション層の再送・並列接続が輻輳を悪化させる典型パターン

輻輳を悪化させる原因が、ネットワーク機器ではなくアプリケーション側にあることも珍しくありません。タイムアウトを短く設定しすぎたクライアントが、応答が遅いだけのサーバへ次々と再送・リトライを投げると、輻輳で遅れているところへさらに負荷を重ねます。多数のコネクションを同時に張る並列ダウンロードや、指数バックオフを入れないリトライループも同様です。マイクロサービス間で「失敗したら即再試行」を素朴に実装すると、一部の輻輳が連鎖的なリトライ嵐（retry storm）を生み、システム全体を巻き込む障害へ発展します。実務では、リトライパターンの指数バックオフ・ジッター・リトライ予算を先に決め、同時再送が同期しないようにするのが基本線です。連鎖が始まってしまう経路には、サーキットブレーカーで障害連鎖を止める実装を組み合わせ、輻輳中の相手へ呼び出しを流し続けない設計にします。輻輳対策はネットワーク層だけの話ではなく、上位のタイムアウト・再送設計とセットで考える必要があります。

TCP輻輳制御：送信量を推測で加減しネットワークを崩壊させない仕組み

輻輳制御の主役はTCPです。送信側はネットワークの空き容量を直接教えてもらえないため、ロスや遅延の変化を手がかりに送信量を探り当てます。その基本動作と、アルゴリズムごとの性格差を押さえます。

スロースタートと輻輳回避：ウィンドウで送信量を増減させる基本動作

TCPは、一度に送って応答待ちにできるデータ量を輻輳ウィンドウ（cwnd）として持ち、これを状況に応じて伸縮させます。通信の開始直後はネットワークの空きが分からないため、スロースタートでウィンドウを1往復ごとに倍々で急拡大し、使える帯域を素早く探るのがこの段階です。スロースタート閾値（ssthresh）を超えると輻輳回避に移り、増やし方を1往復あたり1セグメントぶん程度へ緩めて、そっと上限を探ります。そしてパケットロスを検知すると「詰まった」と判断してウィンドウを大きく絞り、再び慎重に増やし直します。この一連の状態遷移と、重複ACKを合図にした高速再転送・高速回復の扱いはRFC 5681の本文に条文として書かれているので、実装やチューニングで迷ったら規定そのものに当たるのが早道です。TCPの輻輳制御はトランスポート層（L4）で完結する制御で、OSI参照モデルにおける各層の役割のうちL4の責務だと位置づけると、下位のイーサネットやIPには手を入れずに送信量だけを加減している構造が見えます。

LossベースとDelay/帯域ベース：CUBICとBBRの考え方の違い

輻輳の「合図」を何に置くかで、アルゴリズムは大きく2系統に分かれます。Lossベースは、パケットロスを輻輳の合図とみなして速度を落とす方式で、Linuxカーネルが既定に採るcubic系がこれにあたります。CUBICはウィンドウの増やし方を3次関数で定義し、高帯域・長距離の経路でも従来方式より速く帯域を取り戻せるよう設計された方式で、RFC 9438「CUBIC for Fast and Long-Distance Networks」として標準化されています（同RFCは旧仕様のRFC 8312を置き換えたもの）。実装が枯れていて公平性も安定する一方、ロスが輻輳以外の理由でも起きる無線回線では、混んでいないのに速度を落として損をしがちです。もう一方の帯域・遅延ベースは、往復遅延（RTT）の増加や推定した帯域を手がかりにする方式で、Googleが公開したbbr系が代表です。実装とパッチはgoogleのbbrリポジトリで公開され、仕様の標準化はIETF ccwgのBBRドラフトとして進行中という状態なので、採用時はその時点の版を確認します。ロスを待たずに遅延の膨らみで輻輳を察知するため、バッファブロートや高遅延・高ロス回線でスループットを保ちやすい半面、既存のLossベースと混在させると帯域の取り合いで挙動が変わることが報告されています。

観点	Lossベース（CUBIC）	帯域遅延ベース（BBR）
輻輳の合図	パケットロス	RTT増加と推定帯域
得意な経路	ロスが輻輳を表すLAN内	高遅延・高ロスの長距離
弱点	過大バッファで減速しにくい	他方式と混在時の帯域配分
仕様の所在	RFC 9438	IETF ccwgでドラフト進行中

どちらを選ぶかは回線特性次第で、長距離・高遅延やロスの多い経路ではBBR系、社内LANのようにロスが素直に輻輳を表す環境では既定のCUBIC系、という切り分けが実務の当たりになります。既定値やバージョンは環境で変わるため、採用時はカーネルとディストリビューションの当該時点の設定を実機で確認します。

ECNとAQM：ルータ側から輻輳を早期に知らせてロスを避ける仕組み

ロスが出てから減速するのでは、すでに遅延が膨らんだ後です。これを前倒しするのがECN（明示的輻輳通知）とAQM（能動的キュー管理）です。AQMは、待ち行列が完全に満杯になる前から確率的にパケットを落とす、あるいは印を付けることで、送信側へ早めに「そろそろ詰まる」と知らせます。RED系やCoDel・FQ-CoDel系といった方式があり、後者はRFC 8290「The Flow Queue CoDel Packet Scheduler and AQM Algorithm」に手順が記述された、バッファブロート対策として待ち行列の伸びを抑える役割の仕組みです。ECNは、パケットを捨てる代わりにIPヘッダのビットで「輻輳している」と通知し、送信側は再送を伴わずにウィンドウを絞れます。IPヘッダの2ビットをECNフィールドに割り当て、TCP側でECE・CWRフラグを使って合図を返す設計はRFC 3168が定義しました。ロスによる再送を避けられるぶん、対話型トラフィックの体感を保ちやすい仕組みです。ただしECNは経路上の機器と両端がそろって対応している必要があり、途中の機器が印を無視すると効きません。導入時は、端末・サーバ・中継機器の対応状況を確認したうえで、AQMと組み合わせて段階的に有効化するのが安全な進め方です。

L4SとQUIC：輻輳の通知を細かく返す新しい枠組みと適用できる範囲

ECNの考え方をさらに推し進めたのがL4S（Low Latency, Low Loss, and Scalable Throughput）で、RFC 9330がそのアーキテクチャを示しています。従来のECNが「輻輳している／していない」に近い粗さで合図を返すのに対し、L4Sは対応トラフィック用のキューを分け、輻輳の度合いを高い頻度で細かく印付けして、送信側が小刻みに速度を調整できるようにする設計です。狙いはキューイング遅延をミリ秒級に保ったままスループットを落とさない点にあり、対話型・リアルタイム系の通信で効きます。ただし経路上の機器と両端の双方が対応してはじめて効く枠組みなので、閉じた社内網や自前で機器を制御できる区間から試すのが現実的です。もう一つの流れがトランスポート層そのものの置き換えで、UDP上で輻輳制御と再送をユーザ空間に持つQUICでは、アプリケーション側から輻輳制御を差し替えられる構造になっています。QUICの仕組みとTCPとの違いを押さえておくと、カーネル設定でしか動かせないTCPと、実装単位で挙動を変えられるQUICのどちらで輻輳を制御するかという選択肢が見えます。

輻輳を実測する手順：ssとtcで再送率とキュー遅延と破棄数を採取する

輻輳の議論は、実測値が無いと「たぶん混んでいる」で止まります。手元のLinuxから、送信側の輻輳ウィンドウと再送、機器側のキュー破棄を採る手順を順に示します。以下のコマンドは検証機で実行し、本番へ入れる前に切り戻し手順まで確認してください。

ss -tiで輻輳ウィンドウと再送率とRTTを取り送信側の実態を確認する

最初に見るのは送信側の状態です。ssコマンドの-tiオプションは、確立済みTCPコネクションごとに、使っている輻輳制御アルゴリズム、輻輳ウィンドウ（cwnd）、スロースタート閾値（ssthresh）、平滑化RTTとその揺らぎ、再送バイト数を出力します。

ss -ti state established

# 出力例（1コネクション分の抜粋。値は環境で変わります）
# cubic wscale:7,7 rto:236 rtt:35.4/1.2 mss:1448
# cwnd:42 ssthresh:31 bytes_sent:18432110 bytes_retrans:24160
# delivery_rate:9.8Mbps busy:41200ms

読み方の勘所は3点です。rttの平滑値が経路の物理距離から想定される値より大きく膨らんでいれば、途中のキューで待たされている疑いがあります。bytes_retransがbytes_sentに対して無視できない比率で増え続けていれば、どこかでパケットが捨てられています。そしてcwndがssthresh付近で頭打ちになり伸びないなら、送信側は既に「詰まっている」と判断して抑えている状態です。RTTだけが伸びて再送がほぼ無い、という組み合わせが出たときはバッファブロートの典型で、帯域を足しても症状は変わりません。ソケット単位でどの値がどう決まるのかを追いたい場合は、ソケット通信の仕組みとAPI手順を併せて見ると、アプリのバッファ設定と輻輳ウィンドウの関係を切り分けられます。

sysctlで輻輳制御アルゴリズムを切り替えて実測で比較する進め方

アルゴリズムの差は机上で議論しても決着しないので、同じ経路で切り替えて実測します。利用できるアルゴリズムの一覧と現在値はsysctlで確認でき、各パラメータの意味はLinuxカーネル公式ドキュメントのip-sysctlに定義があります。

# 利用できるアルゴリズムと現在の既定値を確認する
sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control

# bbr を読み込んで一時的に切り替える（再起動で元に戻る）
sudo modprobe tcp_bbr
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

# 恒久化する場合のみ設定ファイルへ書く。切り戻しはこのファイルの削除
echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee /etc/sysctl.d/99-cc.conf

比較のときは、切り替えの前後で同じ時間帯・同じ相手・同じ転送サイズを揃え、スループットだけでなくRTTの分布も並べて見ます。スループットが伸びても95パーセンタイルのRTTが悪化していれば、対話型の体感は落ちているからです。なお本番系での切り替えは、他のフローとの帯域配分が変わる影響が出るため、まず片系や検証環境で当てて挙動を確かめてから広げます。

tcでfq_codelを設定しキュー遅延を抑える検証と切り戻しの手順

機器側のキュー管理はtcで試せます。FQ-CoDelはフローごとに待ち行列を分けたうえでCoDelの遅延目標を当てる方式で、man 8 tc-fq_codelによれば既定は目標遅延targetが5ms、観測窓intervalが100ms、フロー数1024、ハード上限10240パケットです。

# 現在の qdisc と統計を確認する
tc -s qdisc show dev eth0

# fq_codel を当てる（既定値を明示し、ECN 印付けも有効化）
sudo tc qdisc replace dev eth0 root fq_codel target 5ms interval 100ms ecn

# 適用後、drop_overlimit と maxpacket、ecn_mark の増え方を追う
tc -s qdisc show dev eth0

# 切り戻し（既定の qdisc に戻す）
sudo tc qdisc del dev eth0 root

判定の目安は、適用前後でss -tiのRTTがどう変わるかです。RTTの上振れが縮み、再送が極端に増えていなければ、待ち行列を短く保つ方向に効いています。逆にドロップだけが増えてスループットが落ちるなら、targetが経路のRTTに対して短すぎる可能性があるため、manページの説明どおりボトルネックの最悪RTTを踏まえたintervalの見直しが必要です。この検証はサーバ側の送信インタフェースでしか効かない点にも注意が必要で、詰まっているのが上流のWAN機器なら、同じ設定思想を機器側のAQMで当てる話になります。

輻輳対策の採用判断：帯域増強・QoS・リンク束ね・監視をどう選ぶか

輻輳対策は入れれば入れるほど良いわけではなく、原因に合っていなければ費用だけがかさみます。どの手をどの条件で採り、どこでは見送るかを言い切ります。

帯域増強だけでは輻輳が消えない場面と、それでも増速が効く場面

「遅いなら回線を太くする」は、当たる場面と外れる場面がはっきりしています。恒常的にリンク使用率が上限に張り付き、ピークだけでなく平均でも帯域が不足しているなら、増速やリンク束ねが素直に効きます。一方で、平均使用率に余裕があるのにロスや遅延が出るケース、すなわちマイクロバーストの瞬間集中やバッファブロートが原因の場合は、帯域を倍にしても症状はほとんど変わりません。太い回線を用意しても、過大なバッファが遅延を積み続ける構造は残るからです。この見極めを飛ばして増速に投資すると、費用をかけたのに体感が改善しない典型的な失敗に陥ります。まず監視で平均とピーク、そしてキュー由来の遅延を切り分け、「帯域が足りない輻輳」なのか「設計・バッファ由来の輻輳」なのかを確定させてから、増速するかを決めるべきです。前節のss -tiで、再送が増えているのかRTTだけが伸びているのかを見れば、この二択はおおむね判別できます。

QoS・優先制御を入れるべき条件と、かえって運用を複雑にする場面

QoS（優先制御）は、限られた帯域を用途ごとに優先度づけして分け合う手段です。音声・ビデオ会議のような遅延に敏感なトラフィックと、バックアップやファイル転送のような遅れても構わないトラフィックが同じ回線を共有し、かつピーク時に取り合いが起きる環境では、QoSで優先度を付ける価値が明確に出ます。逆に、帯域そのものが恒常的に不足している場合、QoSは「誰を先に通すか」を決めるだけで総量は増えないため、根本解決にはなりません。また、拠点数やアプリ種別が多い環境で細かい優先クラスを設計すると、分類ルールの保守が重くなり、設定ミスがかえって障害を招きます。QoSは「帯域は足りているがピークの競合で特定用途が割を食う」ときに絞って入れ、増速で足りるなら無理に導入しないのが運用を軽く保つ判断です。優先クラスを増やす前に、まずFQ-CoDelのようなフロー公平のAQMで足りないかを試すと、設計を膨らませずに済む場合があります。

リンク束ね・MTU調整・監視で輻輳を抑える実務の順序と落とし穴

対策には効かせるべき順序があります。最初にやるのは監視で、リンク使用率・出力キューの破棄・再送率・RTTの推移を継続して取り、詰まりの場所と時間帯を特定する作業です。次に、恒常的な帯域不足に対しては複数の物理リンクを束ねて帯域と冗長性を上げるのが定石で、LACPによるリンクアグリゲーションの仕組みと採用判断が具体的な手段になります。ただし束ねても単一フローは1本ぶんが上限のため、多数の通信が分散する経路でこそ効く点に留意が必要です。パケットサイズの設計も見逃せず、経路の途中で分割（フラグメンテーション）が起きるとオーバーヘッドと再送で実効スループットが下がるため、MTUの仕組みとMSS調整・測定手順を踏まえて経路のMTUに合わせたMSSへ調整します。バッファブロートが疑われるならAQMとバッファ見直しを、瞬間競合ならQoSを、というふうに監視で見えた原因に手を当てるのが順序です。

クラウド側の帯域上限で起きる輻輳とVPC構成で先に確認する箇所

クラウドでは、物理リンクが見えないぶん「上限に当たっているのか輻輳しているのか」が分かりにくくなります。実際にはインスタンスのネットワーク帯域、NATゲートウェイやVPNトンネルのスループット、VPCピアリングやゲートウェイ単位の上限といった形で、サービスごとに数値の枠が定義されています。AWSであればAmazon VPCのクォータ一覧のように公式ドキュメントへ集約されているので、設計段階でピーク時の必要帯域と突き合わせておくことが、運用開始後に「原因不明の遅延」として現れる事故の削減に有効です。判別の手掛かりは、クラウド側が提供するインタフェース単位のメトリクス（帯域超過による破棄カウンタなど）で、これが立っていれば輻輳ではなく上限到達です。オンプレの機器とクラウド側のネットワーク（VPCの帯域・ゲートウェイのスループット上限・複数AZ設計）を一体で詰めたい場合は、インフラ構築（AWS/GCP/Azure）として構成段階から相談すると、物理と仮想の両側で輻輳が起きうる箇所を先に洗い出せます。

よくある質問

輻輳について実務でよく挙がる疑問を、仕組みと対策の観点から簡潔に答えます。

輻輳と輻輳制御は何が違うのですか？

輻輳は「ネットワークの経路が混雑し、バッファ超過でパケットロスや遅延が起きている状態」という現象そのものを指します。輻輳制御は、その現象を起こさない・悪化させないために送信量を加減する仕組みで、担い手は主にTCPです。輻輳が問題（渋滞）、輻輳制御が対処（流量調整）という関係で、輻輳制御があるからこそ多数の通信が同じ回線を崩壊させずに分け合えます。標準の挙動はRFC 5681に定義されています。

輻輳が起きると通信はどうなりますか？

まず待ち行列が伸びてレイテンシー（遅延）が増え、体感が重くなります。さらに混雑が進んでバッファが満杯になるとパケットが捨てられ、送信側の再送も重なってスループットが落ちるという二段構えです。対処を誤って再送が積み重なると、リンクは満杯なのに有効に届くデータがほとんど無い輻輳崩壊に近づきます。対話型のアプリほど遅延の増加に敏感で、会議やゲームの品質が先に悪化します。

帯域を増やせば輻輳は解消しますか？

恒常的に帯域が不足しているなら増速は効きますが、常に有効とは限りません。平均使用率に余裕があるのにロスや遅延が出る場合、原因は瞬間的なマイクロバーストや過大バッファによるバッファブロートで、帯域を倍にしても遅延は残ります。まず監視で「帯域不足の輻輳」か「設計・バッファ由来の輻輳」かを切り分け、後者なら増速ではなくAQMやバッファ見直し、QoSで対処するのが正しい順序になります。

TCPのCUBICとBBRはどちらを使うべきですか？

回線特性で選びます。パケットロスが素直に輻輳を表す社内LANや安定した経路では、Linux既定のCUBIC系で不都合は起きにくいです。一方、長距離・高遅延やロスの多い無線・モバイル経路では、遅延と推定帯域を手がかりにするBBR系がスループットを保ちやすい傾向があります。ただしBBR系はLossベースと混在すると帯域配分の挙動が変わるため、変更時はsysctlで切り替えて本番同等の経路で実測し、既定値やバージョンは当該時点のカーネル設定を確認してから決めます。

アプリ側で輻輳を悪化させないために何をすべきですか？

再送・リトライに指数バックオフとジッタ（待ち時間のばらつき）を入れ、失敗時の即時再試行や全クライアント同時再送を避けることが第一です。タイムアウトを短くしすぎると、遅いだけのサーバへ再送を重ねて輻輳を煽ります。同時接続数の上限を設け、リトライ嵐が連鎖しないようサーキットブレーカーで遮断する設計も有効です。輻輳対策はネットワーク機器だけでなく、上位のタイムアウト・再送設計とセットで考えます。