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

パケットが奏でる調和と狂気：TCP輻輳制御アルゴリズムの深淵と、限界を超えたチューニングの美学

ネットワークエンジニアとして生きていると、夜中に突如として飛び込んでくる「特定のデータセンター間だけスループットが出ない」「グローバル展開したWebアプリケーションの初回レスポンスが妙にもたつく」といったアラートほど、アドレナリンが分泌される瞬間はない。

表面上のモニタリングツールは「帯域に余裕あり」と平然と告げているにもかかわらず、なぜかパイプラインの底が抜けたようにパケットが流れていかない。この不可解な現象の裏側では、OSのカーネル空間で、トランスポート層の泥臭い生存競争が繰り広げられている。そう、犯人はいつだって TCPの輻輳制御（Congestion Control） だ。

教科書を開けば、スロースタートや輻輳回避といった美しいアルゴリズムのフローチャートが描かれている。しかし、実世界のインターネットはそんなに優しくない。数千キロ離れた海底ケーブルを駆け抜け、キャリアのルーターのキュー溢れと戦いながら、パケットは刻一刻と変化する環境に適応しようとしている。

今回は、インフラアーキテクトやテックリード、そしてパケットの挙動にロマンを感じるすべてのエンジニアに向けて、TCPの輻輳制御の内部メカニズムをレイヤーの底から解き明かし、極限のパフォーマンスを引き出すための実践的なチューニング手法を叩き込む。

—

1. 輻輳制御のメカニズム：Tahoe、Reno、そしてCubicのパケット挙動

TCPがインターネットの崩壊を防ぐために実装した最大の発明が「輻輳制御」だ。ベストエフォート型のネットワークにおいて、送信側が勝手にパケットを送り続けたらどうなるか。ルーターのバッファは瞬時に枯渇し、パケットロスが連鎖し、ネットワーク全体が機能不全に陥る（いわゆる輻輳崩壊）。これを防ぐため、TCPはネットワークの許容量を自律的に推測し、送信ウィンドウサイズをダイナミックに変化させる。

この制御を支えるのが、送信側の状態管理アルゴリズムの歴史的進化だ。

スロースタート（Slow Start）と輻輳回避（Congestion Avoidance）

接続確立直後、送信側は cwnd（Congestion Window：輻輳ウィンドウ）を小さく設定してパケットを送り出す。名前は「スロースタート」だが、その挙動はむしろアグレッシブだ。ACK（確認応答）が返ってくるたびに cwnd が指数関数的に（通常は1RTTごとに倍々で）拡大していく。

しかし、いつまでも無限に増やせるわけではない。ssthresh（Slow Start Threshold：スロースタート閾値）に到達した瞬間、アルゴリズムは「輻輳回避モード」へシフトする。ここからは指数関数ではなく、1RTTごとに cwnd を線形（+1セグメントずつ）に増加させ、慎重にネットワークの限界を探る。

紛失の検知：TahoeとRenoの分岐点

パケットロスが発生したとき、ネットワークの混雑をどう検知するかで、アルゴリズムの性格が分かれる。

  • TCP Tahoe:

重複ACK（Duplicate ACK）を3回受信するか、あるいはRTO（Retransmission Timeout）の期限切れを検知すると、「あ、詰まったな」と判断して ssthresh を当時の cwnd の半分に絞り、cwnd を強制的に1セグメントに戻して再びスロースタートからやり直す。非常に保守的で、帯域が太い近代の高速回線では宝の持ち腐れになる。

  • TCP Reno:

3つの重複ACKを受信した場合（高速再送：Fast Retransmit）、RTOを待たずにロストしたパケットを即座に再送する（高速回復：Fast Recovery）。Tahoeのように cwnd を1まで落とさず、ssthresh を半分にした上で、cwnd をその値から線形増加させる。これにより、パイプラインの水を完全に切らさずに復旧を試みる。

モダンLinuxの標準：TCP Cubicの非線形アプローチ

Reno系アルゴリズムの最大の弱点は、広帯域・高遅延（Long Fat Networks: LFN）環境での非効率性だ。RTTが100msを超えるような大陸間通信では、パケットロスを検知してウィンドウを半減させた後、元のサイズに戻るまでに途方もない時間がかかる。

そこで登場したのが、現在のLinuxカーネルのデフォルトである TCP Cubic だ。Cubicは、ウィンドウサイズの増加を「経過時間」の三次関数（Cubic関数）として計算する。

ウィンドウサイズ (cwnd)
        ^
        |          /------- (最大飽和点 K)
        |         /
        |        /  <- 緩やかな増加 (変曲点)
        |       /
  W_max +      /
        |     /   <- 急激なキャッチアップ
        |    /
        +---+----------------------------> 経過時間 (t)
      ロス発生時

Cubicの秀逸な点は、「前回パケットロスが発生したウィンドウサイズ（$W_{max}$）の近傍ではウィンドウの増加を極めて緩やかにし、そこから離れた場所では素早く回復させる」という点にある。これにより、公平性を保ちながら、高帯域回線でもパイプラインを常に満杯に維持することが可能になる。

—

2. 実践：LinuxカーネルにおけるTCP輻輳制御の観測とチューニング

理屈はわかった。では、実際のLinuxサーバーでこの挙動をいかに観測し、最適化すべきか。

現代のLinux（Ubuntu 20.04/22.04やRHEL 8/9以降）では、標準でCubicが有効になっているが、BBR（Bottleneck Bandwidth and Round-trip propagation time）など、さらに次世代のアルゴリズムへの切り替えも容易だ。

現在の輻輳制御アルゴリズムの確認と変更

まずは、システムが現在どのアルゴリズムを使用しているか確認する。

# 現在カーネルで利用可能な輻輳制御アルゴリズムを確認
$ sysctl net.ipv4.tcp_available_congestion_control
cubic reno bbr

# 現在アクティブなアルゴリズムを確認
$ sysctl net.ipv4.tcp_congestion_control
cubic

もし、パケットロスが激しいモバイル網向けのサーバーや、大陸間通信のストリーミング基盤などで Google BBR に切り替えたい場合は、動的にsysctlを叩くか、永続的な設定を行う。

# 一時的にBBRへ切り替える（即座に適用）
$ sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

# 再起動後もBBRを維持するための設定ファイル作成
$ sudo tee /etc/sysctl.d/99-tcp-bbr.conf << 'EOF'
# 輻輳制御アルゴリズムをBBRに指定
net.ipv4.tcp_congestion_control = bbr

# キューイング規 disciplina に fq (Fair Queueing) を指定（BBRの必須要件）
net.core.default_qdisc = fq
EOF

# 設定を即時反映
$ sudo sysctl --system

> Expert Tip: BBRは従来の「ロスベース」の制御ではなく、パケットの往復遅延（RTT）と帯域のボトルネックをリアルタイムで計測し、「これ以上送るとキューが溢れる」という限界点を予測して送信レートを絞る。そのため、送信側のパケット送出タイミングを制御する fq（Fair Queueing）との組み合わせが絶対条件となる。

—

3. 境界防御の盲点：TCPスタックを狙う巧妙な攻撃と回避策

インフラエンジニアやセキュリティスペシャリストにとって、TCPの内部挙動を理解することは、そのまま高度なDDoS攻撃やリソース枯渇攻撃（DoS）からの防御に直結する。

SYNフラッドとSYNクッキー

TCPハンドシェイクの第一歩である SYN パケット。攻撃者は偽装した送信元IPから無数の SYN パケットを送りつけ、サーバーの backlog キューを意図的に溢れさせ、正当なユーザーの接続を拒絶させる（SYNフラッド）。

これに対する古典的かつ強力な対抗策が SYNクッキー（SYN Cookies） だ。サーバーは SYN 受信時に接続状態をメモリ上に保持せず、暗号学的なハッシュ値（クッキー）を SYN-ACK の初期シーケンス番号に埋め込んでクライアントに返す。クライアントからの正当な ACK が返ってきた段階で初めてメモリ上にセッションを構築する。

# SYNクッキーが有効化されているか確認
$ sysctl net.ipv4.tcp_syncookies
net.ipv4.tcp_syncookies = 1

TCPタイムスタンプとシークエンス番号推測の脅威

RFC 1323で規定されたTCPタイムスタンプオプションは、RTTの正確な測定（RTTM）や、パケットの順序逆転・重複を検知するPAWS（Protect Against Wrapped Sequences）に不可欠だ。

しかし、古いカーネルや設定不備のある環境では、このタイムスタンプの増加傾向からサーバーの稼働時間（Uptime）が推測されたり、シーケンス番号の予測を容易にしてセッションハイジャックのリスクを高める原因になったりする。

現代のセキュアなエンタープライズ環境では、カーネルパラメータを適切に硬化（Hardening）させる必要がある。

# セキュアなTCPパラメータの推奨設定例 (/etc/sysctl.d/99-security-tcp.conf)

# タイムスタンプのランダム化（OSフィンガープリンティングや推測攻撃の緩和）
net.ipv4.tcp_timestamps = 1

# TIME-WAITソケットの再利用を許可し、ポート枯渇を防ぐ
net.ipv4.tcp_tw_reuse = 1

# FIN-WAIT-2状態のタイムアウトを短縮し、メモリリーク・リソース枯渇を防ぐ
net.ipv4.tcp_fin_timeout = 15

# SYNパケットに対するSYN-ACKの再送回数を絞る（SYNフラッド対策の補助）
net.ipv4.tcp_synack_retries = 2

—

4. トランスポート層とTLSハンドシェイクの極限最適化（RTT削減の哲学）

Webアプリケーションのパフォーマンスを語る上で、TCPの挙動とTLSのハンドシェイクは切っても切れない関係にある。暗号化通信の安全性を担保しつつ、いかにして「最初の1バイト（TTFB）」までのレイテンシを削り取るか。ここにはエンジニアの執念が宿る。

TCP 3-wayハンドシェイクとTLS 1.3の融合

従来のTLS 1.2までは、TCPの3-wayハンドシェイクが完了した後に、さらに数往復のTLSハンドシェイク（鍵交換、証明書検証、暗号スイート合意）が必要だった。これでは、クライアントが最初のHTTPリクエストを送信するまでに、最低でも 2〜3 RTT のロスタイムが発生する。

これを劇的に改善したのが TLS 1.3 だ。

1. TCP Fast Open (TFO):
TCPの最初の SYN パケットに、あらかじめHTTPリクエスト（あるいはTLS ClientHello）のデータを載せて送信してしまう技術。これにより、条件が揃えば 0 RTT でデータ伝送を開始できる。
2. TLS 1.3 0-RTT / 1-RTT:
TLS 1.3ではハンドシェイクがわずか 1 RTT に短縮された。さらに、過去に接続実績のあるクライアントであれば、セッションチケットを用いて 0-RTT で暗号化データの送信が可能になる。

NagleアルゴリズムとDelayed ACKの悪魔の抱擁

アプリケーション層で小さなパケット（例えば、APIの微小なJSONペイロードなど）を連続して送信する際、歴史的な悪名高きコンビがパフォーマンスを殺すことがある。

  • Nagleアルゴリズム: 小さなパケットが送信されたとき、未確認のACKが返ってくるか、あるいは最大セグメントサイズ（MSS）分のデータが溜まるまで、次のパケットの送信を遅延させて帯域を節約する。
  • Delayed ACK: 受信側は、即座にACKを返さず、他のデータ送信に便乗させるか、一定時間（通常40ms程度）待ってからACKを返す。

この2つが同時に有効な状態で小さなデータを投げると、「送信側がNagleで待つ ⇔ 受信側がDelayed ACKで待つ」という最悪のデッドロック（タイマー待ちの膠着状態）が発生し、レイテンシが劇的に跳ね上がる。

低レイテンシが求められるWeb APIサーバーやリアルタイム通信基盤では、ソケットオプションで明示的にNagleアルゴリズムを無効化（TCP_NODELAY）するのが定石だ。

# PythonのソケットプログラミングにおけるTCP_NODELAYの設定例
import socket

# ソケットの作成
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# Nagleアルゴリズムを無効化し、パケットを即座に送出する（レイテンシ最適化）
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)

sock.connect(("example.com", 443))

—

5. ヘッダー圧縮と次世代プロトコルへの架け橋（HTTP/2・HTTP/3の視座）

TCPの輻輳制御は強力だが、根本的な構造的欠陥として 「ヘッド・オブ・ライン・ブロッキング（HoLブロック）」 を抱えている。TCPストリームの途中で1つのパケットがロストすると、そのロスが回復されるまで、その背後にあるすべての後続パケットがOSのバッファで足止めを食らう。たった1つのパケットの迷子が、コネクション全体の交通渋滞を引き起こすのだ。

このTCPの限界を突破するために生み出されたのが、HPACK/QPACKによるヘッダー圧縮 と、UDPベースのトランスポートプロトコルである QUIC（HTTP/3） である。

HTTP/2のHPACKとTCPのジレンマ

HTTP/2は1本のTCPコネクション上で複数のリクエスト・レスポンスを多重化（Multiplexing）することに成功したが、TCP自体のHoLブロック問題からは逃れられなかった。そのため、アプリ層で多重化しているにもかかわらず、TCP層でパケットロスが起きると結局すべてのストリームが止まるという矛盾を抱えていた。

QUICが描く未来：トランスポート層の脱却

Googleが主導し標準化された QUIC は、TCPではなく UDP をベースに構築されている。
QUICは以下のような特徴を持つ。

  • トランスポート層での独立したストリーム多重化: あるストリームでパケットロスが発生しても、他の無関係なストリームは一切ブロックされない真の多重化を実現。
  • コネクションIDによる接続の継続: IPアドレスやポート番号が変化しても（例えばWi-Fiからモバイル回線への切り替え時）、コネクションが途切れない（接続マイグレーション）。
  • 暗号化のプリミティブ統合: TLS 1.3のハンドシェイクがプロトコル本体に深く組み込まれており、最初のパケットから暗号化される。

—

結びにかえて：パケットの息遣いを感じるエンジニアであれ

TCPの輻輳制御アルゴリズムの歴史は、人間の知性と物理世界の制約との終わりのない闘いの歴史だ。Tahoeの素朴な絶望からRenoの回復、Cubicの洗練された数学的アプローチ、そしてBBRやQUICが切り拓く予測制御のフロンティアまで、すべてのアルゴリズムの背後には「データを一瞬たりとも無駄にせず、しかし壊さない」というエンジニアリングの美学が貫かれている。

クラウドやコンテナ化が進み、インフラが抽象化されてブラックボックス化していく現代だからこそ、一度立ち止まって tcpdump を仕掛け、ss コマンドでソケットの統計情報を眺め、カーネルが奏でるパケットの息遣いに耳を澄ませてみてほしい。

そこに広がるのは、冷徹なコードの集合体ではなく、美しく調和したデジタルエコシステムの鼓動そのものなのだから。

スポンサーリンク

コメント

タイトルとURLをコピーしました