【入門編】 TCP輻輳制御：スロースタート、輻輳回避、高速再送のアルゴリズム – ネットワーク基礎とWebセキュリティ実践ガイド

こんにちは！ネットワークやインフラの世界へ足を踏み入れたばかりの皆さん、日々の学習お疲れ様です。「パケットがどうやって世界中を駆け巡っているのか」、ワクワクする半面、次から次へと出てくる専門用語に圧倒されていませんか？

今回は、そんなネットワークの基礎の中でも、特に熱いドラマが隠されている「TCPの輻輳（ふくそう）制御」についてお話しします。

「輻輳制御？なにそれ難しそう……」と思ったそこのあなた、大丈夫です！一歩ずつ、身近な例えから紐解いていきましょう。

—

1. なぜTCPに「渋滞対策」が必要なの？

私たちが普段何気なく見ているWebサイトや動画は、すべて小さなデータのかたまり（パケット）に分割されて、世界中のルーターという交差点を経由して手元に届いています。

ここで想像してみてください。
もし、巨大なデータを送り主（サーバー）が「受け手の状況お構いなし」に、超高速でドバーッと送り出したらどうなるでしょうか？

途中の道路（ネットワーク回線）や、宛先のルーターの処理能力には限界があります。処理しきれなくなったルーターは、あふれ出たパケットを泣く泣くゴミ箱にポイッと捨ててしまいます。これを「パケットロス（パケット破棄）」と呼びます。

パケットが捨てられると、「あれ、届いてないよ？」と再送のお願いが発生し、かえって通信が遅くなります。最悪の場合、ネットワーク全体が完全に麻痺する「混雑（輻輳）」を引き起こしてしまうのです。

これを防ぐために、TCPというプロトコルには、「相手の様子を見ながら、送るスピードを賢く調整する機能（輻輳制御）」が備わっています。

—

2. 郵便配達員にたとえて理解するTCPの仕組み

TCPの動きをイメージしやすくするために、「ものすごく丁寧だけど慎重な郵便配達員さん」を思い浮かべてみてください。

この配達員さんは、送り先の家（受信側）が一度にどれくらいの荷物を受け取れるか、最初はまったく知りません。そこで、以下のようなルールで配達を行います。

1. スロースタート（まずは様子見）
最初は「1個だけ」荷物を届けてみます。無事に「届いたよ！」というお返事（ACK）が返ってきたら、次は「2個」、その次は「4個」「8個」と、届くたびに爆発的（倍々ゲーム）に送る量を増やしていきます。
2. 輻輳回避（調子に乗りすぎない！）
倍々で増やしていくと、いつか道のキャパシティがいっぱいになります。ある一定のライン（閾値：スレッショルド）を超えたら、今度は一気に増やすのをやめ、「1個ずつ慎重に増やすモード」に切り替えます。
3. 高速再送（トラブルの察知と立て直し）
もし途中で「荷物が届かない！」というパケットロスが発生したら、配達員さんは「おっと、道が混んできたな」と察知します。送る量をガクッと減らし、再び安全な速度から立て直しを図ります。

この一連のドラマチックなアルゴリズムが、歴史的に Tahoe（タホ） や Reno（リノ）、そして現代の主流である Cubic（キュービック） といった名前で進化を続けてきました。

—

3. パケットの動きをシミュレーションしてみよう！

言葉だけだとイメージしにくいので、Pythonの簡単なコードを使って、TCPがどのように「送るウィンドウサイズ（一度に送れる量）」を変化させているのかをシミュレーションしてみましょう。

実務の現場でも、Linuxカーネルのパラメータ調整などでこの概念に触れることになります。まずは雰囲気を掴んでみてくださいね。

# TCPの輻輳制御（スロースタートから輻輳回避への遷移）を模したシミュレーションコード

def simulate_tcp_congestion():
    # 混雑ウィンドウサイズ（一度に送信できるパケット数）
    cwnd = 1
    # 閾値（この値を超えたら慎重モードに入る）
    ssthresh = 16
    
    print("=== TCP 輻輳制御シミュレーション開始 ===")
    
    for round_trip in range(1, 15):
        print(f"ラウンド {round_trip}: 現在のウィンドウサイズ = {cwnd}")
        
        # 閾値に達するまでは「スロースタート（倍々ゲーム）」
        if cwnd < ssthresh:
            cwnd *= 2
            # 万が一、閾値を超えたら調整
            if cwnd > ssthresh:
                cwnd = ssthresh
        else:
            # 閾値を超えたら「輻輳回避（1個ずつ増加）」
            cwnd += 1
            
        # 仮想的なパケットロスが発生した想定のイベント（例としてラウンド7でロス）
        if round_trip == 7:
            print("  -> 【警告】パケットロス発生！速度を急降下させます。")
            ssthresh = cwnd // 2  # 閾値を当時の半分に設定
            cwnd = 1              # スロースタートに戻る
            print(f"  -> 新しい閾値(ssthresh): {ssthresh}, ウィンドウサイズリセット: {cwnd}")

# 実行
simulate_tcp_congestion()

このコードを実行すると、最初は 1 -> 2 -> 4 -> 8 -> 16 と急激に増え、閾値に達すると 17 -> 18 と緩やかになり、途中でロスが起きるとガクッと 1 に戻る様子がよく分かります。これがまさに、ネットワークの裏側で行われているドラマです。

—

4. 現場のインフラエンジニアが知っておくべきチューニングの視点

インフラの構築やサーバーの初期設定（Linuxなど）を行う際、このTCPの挙動をコントロールするアルゴリズムを変更することができます。

例えば、現在のLinuxカーネル（標準）では、より高速なネットワーク環境（光回線や高遅延回線）に最適化された Cubic や BBR というアルゴリズムが使われています。

現在のサーバーがどのアルゴリズムを使っているか、Linuxのコマンドで確認してみましょう。

# 現在のシステムで有効なTCP輻輳制御アルゴリズムを確認する
sysctl net.ipv4.tcp_available_congestion_control

もし出力結果に cubic reno などが表示されていれば、それが現在利用できるアルゴリズムです。さらに、現在適用されているアルゴリズムを変更したい場合は、以下のように設定ファイルをいじります。

# 一時的にTCPの輻輳制御をBBR（Googleが開発した最新のアルゴリズム等）に変更する例
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

# 設定を永続化するために /etc/sysctl.conf に追記する設定例
# net.ipv4.tcp_congestion_control = bbr

実務では、動画配信サービスや大容量ファイルを扱うストレージサーバーなどを構築する際、この輻輳制御アルゴリズムの選択がパフォーマンス（スループット）に直結する重要なポイントになります。

—

5. まとめ

今回は、TCPの輻輳制御アルゴリズムについて、スロースタートや輻輳回避の仕組みを郵便配達の例えやシミュレーションを交えて解説しました。

スロースタートで様子見しながら爆発的に速度を上げ、
輻輳回避で慎重に安全な速度を探り、
パケットロスが起きたら素早く速度を落としてネットワーク崩壊を防ぐ。

この絶妙な「譲り合いの精神」があるからこそ、私たちは世界中どことでもスムーズに通信できるのです。

「難しいプロトコルも、裏側のストーリーを想像すると少し面白そうだな」と感じてもらえたら嬉しいです。それでは、また次回の技術解説でお会いしましょう！一歩ずつ、確実にエンジニアとしての引き出しを増やしていきましょうね！