はい、承知いたしました。TCPの輻輳制御アルゴリズム（Slow Start, Congestion Avoidance）について、ネットワーク初心者の方にも分かりやすく、現実世界の例えを交えながら解説するブログ記事を執筆します。教科書的な説明ではなく、現場のリアルな知見を盛り込み、読者が実践で役立てられるような内容を目指します。
—
ネットワークの渋滞、どう乗り切る？ TCP輻輳制御の「Slow Start」と「Congestion Avoidance」を郵便配達に例えて徹底解説！
皆さん、こんにちは！ ネットワークの世界へようこそ！ インフラやネットワークに初めて触れるエンジニアの皆さん、そしてこれからその奥深い世界に飛び込もうとしている皆さん、今日は一緒に、インターネットの「交通整理」とも言える、とっても重要な仕組みについて学んでいきましょう。
私たちが普段何気なく使っているインターネット。Webサイトを見たり、動画をストリーミングしたり、オンラインゲームを楽しんだり。これらすべて、データという「荷物」が、世界中のネットワークという「道路」を駆け巡ることで成り立っています。でも、もし突然、たくさんの荷物が一度に道路に溢れ出したらどうなるでしょう？ そう、大渋滞が発生してしまいますよね。
今日のテーマは、そんなネットワークの「渋滞」を賢く回避し、スムーズな通信を実現するための、TCP（Transmission Control Protocol）という通信ルールに組み込まれた「輻輳制御（ふくそうせいぎょ）」アルゴリズムです。特に、その中でも代表的な「Slow Start（スロースタート）」と「Congestion Avoidance（コンジェスチョン・アボイダンス）」という2つのフェーズに焦点を当てて、郵便配達員さんに例えながら、分かりやすく解説していきますね。
郵便配達員さんの大奮闘！ ネットワークの「渋滞」って、どうして起こるの？
まず、なぜネットワークが「渋滞」してしまうのか、イメージを掴んでみましょう。
昔々、あるところに、とても親切で働き者の郵便配達員さんがいました。彼の仕事は、手紙という「パケット」を、依頼主（送信元）から受け取って、宛先（送信先）に届けることです。
- パケット: インターネット上を流れるデータの最小単位。手紙に例えられます。
- 送信元: 手紙を出す人。
- 送信先: 手紙を受け取る人。
- ネットワーク: 手紙を運ぶ道路や、それを仲介する郵便局。
この郵便配達員さん、最初は「できるだけ早く、たくさんの手紙を届けたい！」と、とっても意欲的です。でも、もし一度に大量の手紙を抱えて、まだ見ぬ道路を猛スピードで進んでしまったらどうなるでしょうか？
- 道路が狭かったら？ 荷物でいっぱいになって、身動きが取れなくなります。
- 途中の郵便局（ルーター）が処理しきれなかったら？ 荷物を預かってもらえず、困ってしまいます。
- 道に迷ったり、荷物を落としてしまったりしたら？ （パケットロス） 依頼主（送信元）は「届いていないよ！」と心配になり、もう一度同じ手紙を送る必要が出てきます。
このように、ネットワークも、一度に送られてくるデータ量が多すぎると、途中の通信機器（ルーターなど）が処理しきれなくなり、パケットロスが発生したり、通信速度が極端に遅くなったりします。これが「ネットワークの渋滞」です。
TCPは、この渋滞を検知し、荷物の量を適切に調整することで、通信を円滑に保とうとする賢い仕組みを持っているんです。
まずは「様子見」から！ TCPの「Slow Start」って何？
さて、本題のTCP輻輳制御アルゴリズムです。まずは「Slow Start」から見ていきましょう。
「Slow Start」という名前から「ゆっくり始める」というイメージが湧きますよね。まさにその通り！ 郵便配達員さんが、新しい配達ルートで初めて荷物を運び始めるときを想像してみてください。
1. 最初の1通（2つのパケット）からスタート！
通信が始まったばかりの頃、送信元は「このネットワークはどれくらいの荷物を運べるんだろう？」と、まだよく分かっていません。そこで、まずはごく少量、例えば2つのパケットを送信します。
（※TCPの初期ウィンドウサイズは、環境によって異なりますが、ここでは分かりやすさのために「2」として説明します。実際には4や10など、より多い場合もあります。）
2. 「無事届いたよ！」の返事（ACK）が来たら、倍々ゲームで増やす！
送信先から「荷物、ちゃんと届いたよ！」という返事（ACK: Acknowledgment）が、パケットごとに（あるいはまとまって）返ってきます。この「ACK」という返事が、送信元にとっては何よりも嬉しい「信号」になります。
- 最初の2つのパケットがACKで確認できたら、「よし、この道路は大丈夫そうだ！」と自信がつき、次に送るパケット数を倍にします。つまり、4つのパケットを送ります。
- その4つのパケットがすべてACKで確認できたら、さらに倍の8つ。
- 次は16個、32個… と、ACKが返ってくるたびに、指数関数的に（倍々ゲームのように）送れるパケット数を増やしていきます。
この「倍々ゲーム」で増やしていく期間が「Slow Start」です。名前とは裏腹に、実は急激に送信レートを上げていくフェーズなんです。これは、ネットワークがまだ混雑していない初期段階で、できるだけ早く通信速度を上げ、効率よくデータを送信するためです。
この「倍々ゲーム」で増えるパケット数の上限は、「輻輳ウィンドウ（Congestion Window: cwnd）」という変数で管理されています。cwndは、一度に送信できる（あるいは確認応答を待っている）パケットの最大数を示します。
郵便配達員さんの例えで言うと…
- 最初は「この道、初めてだから、とりあえず2つだけ持ってみよう。」
- 2つ無事に届いて「ありがとう！」の連絡が来たら、「お、いけそうじゃん！ 次は4つ持ってみよう！」
- 4つ無事に届いたら、「調子いいぞ！ 次は8つ！」
- …というように、返事が来るたびに、持っていく荷物の数をどんどん増やしていくイメージです。
この「Slow Start」は、ある一定の閾値（ssthresh：Slow Start Threshold）に達するまで続きます。この閾値は、ネットワークが「そろそろ混み始めるかもしれないな」という、経験則に基づいた「目安」のようなものです。
「そろそろ安全運転に切り替えよう…」 TCPの「Congestion Avoidance」って何？
さて、先ほどの「Slow Start」で、通信速度はどんどん上がっていきました。でも、いつまでも倍々ゲームを続けていると、さすがにネットワークもパンクしてしまいます。そこで登場するのが「Congestion Avoidance」です。
「Congestion Avoidance」は、文字通り「混雑を回避する」ためのフェーズです。郵便配達員さんが、慣れてきた道でも、急に荷物の数を倍々に増やしていくのではなく、もっと慎重に、安全運転に切り替えるイメージです。
1. 「ゆっくり、着実に」増やす！
ssthresh（Slow Start Threshold）に達したら、それ以降は倍々ゲームではなく、1往復（RTT: Round Trip Time）につき、1パケットずつ、ゆっくりと送信レートを上げていきます。
- 例えば、
cwndが16個になったとします。ssthreshに達した後は、16個のパケットがすべてACKで返ってきたら、次は17個、その次の往復で18個…というように、徐々に増やしていきます。
2. 「ちょっと待って！ 荷物が多いよ！」のサイン（パケットロス）
この「Congestion Avoidance」のフェーズで、もし万が一、パケットロスが発生してしまったらどうなるでしょうか？
これは、郵便配達員さんが「あれ？ 荷物が多すぎて、道路が詰まってしまったかも…」とか、「途中の郵便局で、もう置く場所がないって言われた！」というサインだと解釈されます。
この「パケットロス」を検知すると、TCPは「ネットワークが混雑している！」と判断し、以下の2つの重要なアクションを起こします。
ssthresh（閾値）を現在のウィンドウサイズの半分に下げる:
「今回は多すぎたんだな。次からは、この半分の量から慎重に再開しよう。」と、次に「Slow Start」から「Congestion Avoidance」に移行する際の「目安」を下げます。
cwnd（輻輳ウィンドウ）を小さくする:
具体的には、cwndを1パケット（または2パケット）まで一気に小さくし、再び「Slow Start」または「Congestion Avoidance」のフェーズから再開します。
この「パケットロスを検知したら、ウィンドウサイズを小さくして、閾値を下げる」という動作は、ネットワークの混雑を緩和するための、TCPの最も重要な「安全装置」と言えます。
郵便配達員さんの例えで言うと…
- 「よし、そろそろこの道も慣れてきたけど、調子に乗るのは危ないな。これからは、1往復で、1つだけ荷物を増やすようにしよう。」
- （そして、ある日…）「おっと！ 荷物がいっぱいで、道が渋滞してる！ これはまずいぞ！」
- 「今回は多すぎたんだ。次からは、この半分くらいからやり直そう。そして、今持ってる荷物は一旦減らして、様子を見ながらまた少しずつ増やしていこう。」
というような、慎重な対応に切り替わるイメージです。
パケットロスを検知する「賢い」方法：Fast RetransmitとFast Recovery
「パケットロス」を検知すると、TCPはウィンドウサイズを小さくするとお話ししましたが、では、具体的にどのように「パケットロス」を検知するのでしょうか？
TCPには、このパケットロスを効率的に検知するための仕組みがあります。
- 重複ACK（Duplicate ACK）の検知:
送信側は、パケットを順番に送っています。もし、例えばパケット番号5が失われたとすると、パケット番号6、7、8…は、送信元に届きます。しかし、送信先は「あれ？ 5番が来てないな…」と気づき、5番が届くまで、最後に正常に受け取ったパケット（この場合は4番）のACKを繰り返し送信します。
送信元は、この「同じACKが何度も返ってくる」という状況を「重複ACK」と呼び、これを3回（またはそれ以上）受け取ると、「これはパケットロスだな！」と判断します。
この重複ACKの検知によって、タイムアウト（一定時間ACKが返ってこないこと）を待つよりも、ずっと早くパケットロスを検知できるんです。
- Fast Retransmit (高速再送):
重複ACKを検知したら、TCPはタイムアウトを待たずに、失われたと判断されたパケット（この例では5番）をすぐに再送します。これがFast Retransmitです。
- Fast Recovery (高速回復):
Fast Retransmitで失われたパケットを再送し、さらに重複ACKを一定数受け取っている間は、cwndをすぐに1にまで減らすのではなく、「Slow Start」に移行する閾値 (ssthresh) を現在のウィンドウサイズの半分に設定し、cwndをその閾値の近くまで（例えば ssthresh + 3 パケット分）まで減らし、そこから「Congestion Avoidance」を継続します。
これにより、パケットロスが発生しても、通信の停止時間を最小限に抑え、比較的スムーズな通信を維持しようとします。
これらの「Fast Retransmit」と「Fast Recovery」は、TCPがパケットロスに素早く対応し、ネットワーク全体の効率を維持するための、まさに「賢い」工夫なんです。
まとめ：Slow StartとCongestion Avoidanceの役割
今日の学びをまとめると、TCPの輻輳制御アルゴリズムは、以下の2つのフェーズをうまく使い分けることで、ネットワークの渋滞を避け、効率的な通信を実現しています。
- Slow Start:
- 通信開始時や、大きなパケットロス発生後に、短時間で送信レートを急激に上げるフェーズ。
- 倍々ゲームのように
cwndを増やしていく。 ssthreshに達するまで続く。- 目的: ネットワークの帯域幅を素早く見つけ出す。
- Congestion Avoidance:
ssthreshに達した後、送信レートをゆっくりと着実に上げるフェーズ。- 1往復（RTT）につき、1パケットずつ
cwndを増やす。 - 目的: ネットワークの混雑を避けつつ、帯域幅を最大限に活用する。
- パケットロスが発生すると、
ssthreshが下がり、cwndも小さくなる。
そして、パケットロスを検知すると、Fast RetransmitやFast Recoveryといった仕組みで、迅速に状況を改善しようとします。
実務で知っておきたいこと：LinuxでのTCP輻輳制御アルゴリズムの確認と設定
さて、ここまで理論を学んできましたが、実際のインフラエンジニアや開発者としては、「自分の環境ではどうなっているんだろう？」と気になるところですよね。
Linuxでは、sysctlコマンドを使って、TCPの輻輳制御アルゴリズムに関する様々な設定を確認したり、変更したりすることができます。
現在のTCP輻輳制御アルゴリズムの確認
どのアルゴリズムが有効になっているかを確認してみましょう。
# 現在有効になっているTCP輻輳制御アルゴリズムを表示
sysctl net.ipv4.tcp_congestion_control実行結果の例：
net.ipv4.tcp_congestion_control = cubicここで表示される cubic などが、現在使用されているアルゴリズム名です。cubic は、現代の高速ネットワークで広く使われている、非常に効率的なアルゴリズムの一つです。他にも reno（TCPの初期のアルゴリズム）や、bbr（Googleが開発した、より高度なアルゴリズム）などがあります。
利用可能なTCP輻輳制御アルゴリズムの一覧表示
システムで利用可能なアルゴリズムの一覧を確認することもできます。
# 利用可能なTCP輻輳制御アルゴリズムの一覧を表示
sysctl net.ipv4.tcp_available_congestion_control実行結果の例：
net.ipv4.tcp_available_congestion_control = reno cubic bbrTCP輻輳制御アルゴリズムの変更（一時的）
例えば、一時的に reno アルゴリズムを使いたい場合（学習目的などで）、以下のように実行できます。
# TCP輻輳制御アルゴリズムを reno に一時的に変更
sudo sysctl -w net.ipv4.tcp_congestion_control=reno【重要】 この設定は、サーバーを再起動すると元に戻ってしまいます。永続的に変更したい場合は、/etc/sysctl.conf ファイルを編集する必要があります。
/etc/sysctl.conf で永続的に設定する場合
/etc/sysctl.conf ファイルに以下の行を追加し、保存します。
# TCP輻輳制御アルゴリズムを cubic に設定
net.ipv4.tcp_congestion_control = cubic設定を反映させるには、以下のコマンドを実行します。
# sysctl.conf の設定を読み込み、適用
sudo sysctl -p補足：Slow Start Threshold (ssthresh) の調整
ssthresh の値も、TCPの挙動に影響を与えます。通常は自動で調整されますが、特定の状況下で調整が必要になることもあります。
# 現在のssthreshの値を確認（これはシステム全体の設定ではなく、個々の接続で動的に変化します）
# システム全体でデフォルト値を変更したい場合は、sysctl.confに記述します
# 例: sudo sysctl -w net.ipv4.tcp_slow_start_after_idle=N (Nは秒数)最後に：ネットワークの「見えない努力」に感謝！
いかがでしたでしょうか？ TCPの輻輳制御、特に「Slow Start」と「Congestion Avoidance」の仕組みについて、郵便配達員さんの例えを交えながら解説しました。
普段、私たちがインターネットを快適に利用できるのは、このような見えないところで、TCPが一生懸命「交通整理」をしてくれているおかげなのです。パケットロスが発生したときに、すぐに諦めずに、ウィンドウサイズを調整して再送を試みる。そして、ネットワークの状況を見ながら、送信レートを賢くコントロールする。これらの「見えない努力」があるからこそ、私たちはスムーズな通信を享受できているんですね。
皆さんがこれから開発やインフラ構築に携わる上で、このTCPの輻輳制御の知識が、ネットワークのパフォーマンスチューニングやトラブルシューティングの糸口となれば幸いです。
もし、「この部分がまだよく分からないな…」とか、「もっとこういう例えで説明してほしい！」といったご要望があれば、ぜひコメントで教えてくださいね！ 一緒に、ネットワークの不思議をもっと解き明かしていきましょう！
それでは、また次回のブログでお会いしましょう！
コメント