Tech Learning Daily

送信側は「道がどれだけ空いているか」を知らない

TCP の送信側は、相手から ACK（確認応答: 「ここまで受け取った」という返信）が届く前に、まとめて何パケットか先に送ってしまう。ACK を 1 個ずつ待っていたら、1 往復で 1 パケットしか送れないからだ。問題は「ACK を待たずに何バイトまで送ってよいか」である。

その上限を決めるものは 2 つある。1 つは受信側が「これだけなら受け取れる」と申告する受信ウィンドウ。もう 1 つが送信側が自分で見積もるcwnd（congestion window, 輻輳ウィンドウ: 経路を詰まらせずに送れると推定した量）だ。実際に送るのは両者の小さい方になる。

受信ウィンドウは相手が教えてくれるが、途中のルーターがどれだけ空いているかは誰も教えてくれない。経路上には他人のトラフィックも流れていて、ルーターのバッファ（待ち行列）が溢れればパケットは捨てられる。全員が全力で送ると全員の再送が増えて誰も届かなくなるため、TCP は 1980 年代から「様子を見ながら増やし、詰まったら減らす」という輻輳制御（congestion control）を各送信者に求めてきた。

スロースタート: 14.6KB から始めて往復ごとに倍

新しい接続の cwnd の初期値は、RFC 6928 で上限 10 セグメントと定められている。一般的な Ethernet の MSS（Maximum Segment Size: 1 パケットに載せられるデータ量）1460 バイトなら 14,600 バイトだ。Linux は 2011 年にこの初期値を 10 に引き上げている。それ以前の規定は約 4KB で、RFC 6928 は Web のレスポンスが大きくなったことを引き上げの理由に挙げている。

RFC 5681 によれば、スロースタート中は新しいデータの ACK が 1 つ届くたびに cwnd を最大 1 セグメントずつ増やす。1 往復で送った 10 セグメント分の ACK が返れば 10 増えて 20 になり、次は 40 になる。名前は「スロー」だが、1 往復ごとにほぼ倍という指数的な増え方だ。名前は「最初の量が小さい」ことを指している。

RTT 100ms・初期 cwnd 10 の場合
（TCP/TLS ハンドシェイクを除く）

RTT#  sent/RTT           total
──────────────────────────────
 1    ==        14.6KB   14.6KB
 2    ====      29.2KB   43.8KB
 3    ========  58.4KB  102.2KB
 4    ================
               116.8KB  219.0KB
──────────────────────────────
▶ 200KB を受け取り終えるのは 4 往復目
▶ 所要 ≒ 4 × 100ms = 400ms

リードの疑問はこれで解ける。200KB のレスポンスは帯域の上では一瞬でも、cwnd が育つまでに 4 往復かかる。RTT が 100ms の経路なら、それだけで 400ms だ。最初の往復で送れる 14.6KB を 100ms で割ると約 1.2Mbps 相当で、1Gbps の回線はほぼ遊んでいる。短い転送の速さを決めるのは回線の太さではなく往復の回数と RTT である。

では、どこまで増やせば十分なのか。経路を満杯にするのに必要な量は「帯域 × RTT」（BDP: Bandwidth-Delay Product）で計算できる。1Gbps × 100ms なら 12.5MB で、14.6KB から倍々で到達するには 10 往復ほどかかる。

増やし続けた先: ロスで減らす CUBIC、測って決める BBR

倍々に増やせばいつか経路のどこかでバッファが溢れ、パケットが失われる。RFC 5681 の基本形（Reno と呼ばれる系統）では、ロスを検知するとしきい値 ssthresh（slow start threshold: スロースタートをやめる境目）を送信中データ量の半分に下げ、以後は 1 往復あたり 1 セグメントずつしか増やさない輻輳回避に移る。再送タイマーが切れるほど深刻な場合は cwnd を 1 セグメントまで落としてスロースタートからやり直す。

現在 Linux・Windows・Apple の標準は CUBIC（RFC 9438）である。ロスを合図に減らす点は Reno と同じだが、減らし幅は半分ではなく 0.7 倍で、その後は「前回ロスした大きさ」に向けて時間の 3 次関数で素早く戻る。RTT の長い高帯域経路で、Reno のように 1 往復 1 セグメントずつ増やしていては回復に時間がかかりすぎるためだ。

ロスこそ混雑のサインだと思いがちだが、実際には両者は一致しないことがある。ルーターのバッファが深いと、ロスが起きる前に待ち行列が伸びて遅延が膨らむ（bufferbloat）。逆に Wi-Fi などでは混雑と無関係なロスが起きて、送信側が不要に減速する。Google が開発した BBR は、ロスではなく「最近測れた最大の配送速度」と「最小の RTT」から経路のモデルを作り、その速度に合わせて送る。Google の 2017 年の報告では、YouTube で CUBIC に比べスループットが平均 4% 上がり、RTT が 33% 下がったとしている。

# 使える方式と、いま使われている方式を見る（Linux）
sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control

# BBR に切り替える（tcp_bbr モジュールが必要）
sudo modprobe tcp_bbr
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

この設定が効くのは「そのマシンが送る方向」だけである。ダウンロードが遅いからといってクライアント側を BBR にしても、データを送っているのはサーバーなので変化しない。切り替えるならレスポンスを大量に送る側（Web サーバーや CDN のオリジン）で行う。

育った窓を捨てない: アイドル後のリセットと initcwnd

スロースタートの代償は接続ごとに払う。そのため HTTP の keep-alive やコネクションプールで接続を使い回すと、TCP ハンドシェイクだけでなく育った cwnd も再利用できる。ただし、しばらく何も送らなかった接続では、経路の状況が変わっている可能性があるので窓は縮められる。RFC 5681 は、再送タイムアウトより長く送信が止まった場合は cwnd を初期値以下に戻すよう定めている。

# アイドル後に cwnd を初期値へ戻すか（既定 1 = 戻す）
sysctl net.ipv4.tcp_slow_start_after_idle

# 0 にすると、間欠的に大きな応答を返す長寿命接続で
# 毎回スロースタートをやり直さずに済む
sudo sysctl -w net.ipv4.tcp_slow_start_after_idle=0

0 にすると、数秒おきに大きなレスポンスを返す接続（HTTP/2 や gRPC の長寿命接続など）で毎回 4 往復を払わずに済む。代わりに、混雑が始まっている経路へいきなり大きな窓で送り込む可能性がある。初期値そのものはルート単位で変えられ、ip route の initcwnd オプションで宛先ごとに指定できる。

# 既定ルートの初期 cwnd を 20 セグメントにする例
ip route show default
sudo ip route change default via 192.0.2.1 dev eth0 initcwnd 20

192.0.2.1 と eth0 は自分の環境の ip route show default の出力に置き換える。大きくすると最初の往復で送れる量は増えるが、RFC 6928 が 10 で止めているのは経路を詰まらせる危険との兼ね合いである。自社で計測できる環境以外では、触る前に CDN の利用や接続の使い回しを検討する方がよい。