【テクニカル・上級編】 TCPの輻輳制御アルゴリズム(Slow Start, Congestion Avoidance) – ネットワーク基礎とWebセキュリティ実践ガイド

輻輳制御の深淵：TCPの「呼吸」を理解し、グローバル規模のレイテンシを極限まで削ぎ落とす

ネットワークエンジニアの諸君、あるいはアーキテクチャの細部に魂を宿すテックリードたちへ。

我々が日々扱っているTCP/IPスタックは、ただの「データを運ぶパイプ」ではない。それは、世界中の物理的な制約——光速の壁、ルーターのバッファ溢れ、そして気まぐれなパケットロス——と対話し続ける、極めて高度な自律型生物だ。今回は、TCPの心臓部である「輻輳制御（Congestion Control）」という、静かだが熾烈な最適化の舞台裏にフォーカスする。

教科書には「Slow Start」や「Congestion Avoidance」のグラフが描かれているが、現場で重要なのはそのアルゴリズムの「呼吸」そのものだ。

1. パケットの行進：Slow StartからCongestion Avoidanceへ

TCPの送信者が最初にぶつかる壁、それが ssthresh（Slow Start Threshold）だ。

接続開始直後、TCPは「手探り」で帯域を探る。これが Slow Start フェーズだ。ACKが戻るたびに cwnd（Congestion Window）を指数関数的に増加させ、パイプの太さを推測する。この時、もし cwnd が ssthresh を超えると、アルゴリズムは線形増加の Congestion Avoidance へと移行する。

なぜ線形なのか？それは、ネットワークの限界点付近で指数関数的な加速を続ければ、必ずルーターのバッファをパンクさせ、パケットロスという「死」を招くからだ。

2. 現場の現実：TCPバッファチューニングの作法

デフォルトのLinuxカーネル設定は、汎用的な「安全」を優先している。しかし、高トラフィックなAPIサーバーや、グローバル展開するCDNのバックエンドにおいて、そのデフォルト値は往々にしてボトルネックとなる。

特に、RTT（Round Trip Time）が長い環境では、initcwnd（初期輻輳ウィンドウ）の調整が体感速度を劇的に変える。

# 現在のTCP設定を確認
ip route show

# ネットワークの特性に合わせて初期ウィンドウサイズを最適化する
# 多くの大規模Webサービスでは、パケットロスを恐れず10に設定するのが標準的
sudo ip route change default via 192.168.1.1 dev eth0 initcwnd 10

initcwnd 10 に設定することで、最初のハンドシェイク直後に送出できるデータ量を増やし、TLSハンドシェイクの往復回数を減らす。TLS 1.3が普及した現在、このチューニングはレイテンシ削減の最後の聖域とも言える。

3. セキュリティとパフォーマンスの均衡：BBRという選択肢

近年、Googleが開発した BBR (Bottleneck Bandwidth and Round-trip propagation time) が、従来の Cubic や Reno といった「ロスを検知して速度を落とす」手法を過去のものにしつつある。

BBR はパケットロスを「混雑」とは見なさず、実際の伝送遅延と帯域幅を計測し、パイプの「ボトルネック」を特定する。これにより、無線LANのようなパケットロスが常態化する環境でも、TCPスループットが劇的に向上する。

# 現在利用可能な輻輳制御アルゴリズムを確認
sysctl net.ipv4.tcp_available_congestion_control

# BBRに切り替える（要カーネルサポート）
sudo sysctl -w net.core.default_qdisc=fq
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

4. 脆弱性回避と「見えない」ボトルネック

ネットワークセキュリティの観点から言えば、TCPのウィンドウサイズを無闇に広げることは、Slowloris 攻撃のようなリソース枯渇攻撃に対して脆弱になる可能性を孕んでいる。

また、MTU（Maximum Transmission Unit）の不一致による PMTUD（Path MTU Discovery）のブラックホール問題は、今なおエンジニアを悩ませる。UDPベースのQUICが急速に普及している背景には、TCPの「硬直した輻輳制御」と「MTUの柔軟性の欠如」を回避したいという切実な思いがある。

エンジニアへの提言：計測なき最適化は単なる勘違い

最後に、最も重要なことを伝える。どんなに優れた輻輳制御アルゴリズムも、パケットの挙動を可視化できなければただのブラックボックスだ。

ss コマンドや tcpdump を活用し、実際の通信の rtt や cwnd の推移を定期的にプロファイリングしてほしい。

# 現在のソケットの輻輳状態をリアルタイムで追跡する
ss -tin

このコマンドが吐き出す rtt:12.345 ms や cwnd:10 といった数値こそが、君のインフラが今、ネットワークという大海原でどのような呼吸をしているかを示す唯一の真実だ。

ネットワークの世界に魔法はない。あるのは、物理法則とアルゴリズムの厳格な対話だけだ。その対話を深く理解した時、君の構築するシステムは、どんな過酷なネットワーク環境下でも優雅にデータを運び続けるだろう。