TCPのフロー制御とウィンドウスケーリング

フロー制御は「受信側を守る」仕組み

TCPには送信ペースを律する制御が2つあります。混同されがちですが起源も守る対象も違います。

• フロー制御（flow control）: 受信側のバッファが溢れないように送信側を絞る。エンド間の局所的な問題。
• 輻輳制御（congestion control）: 経路上のネットワークが溢れないように送信側を絞る。共有資源の問題。

本稿はフロー制御の側を扱います。輻輳制御の数理は AIMD と輻輳制御の数理 を参照してください。両者は独立に算出され、送信側が一度に流せる未確認データ量（in-flight）の上限は、受信側が許す rwnd（受信窓） と、ネットワークが許す cwnd（輻輳窓） の 最小値 で決まります。

実効送信ウィンドウ = min(rwnd, cwnd)

どちらか小さい方がボトルネックです。受信側がいくらバッファを広げても経路が細ければ無駄で、逆もまた然り。TCP/UDPの役割分担は TCP と UDP の違い を前提とします。

スライディングウィンドウの内部

フロー制御の実体は スライディングウィンドウ です。受信側は確認応答（ACK）のたびに「あと何バイト受け取れるか」を 広告ウィンドウ（advertised window） としてヘッダの16ビット欄に載せて返します。これが受信バッファの空き容量そのものです。

送信側はシーケンス番号空間を4区分で管理します。

 |---- 1 ----|---- 2 ----|------ 3 ------|---- 4 ----|
   送信&ACK済   送信&未ACK    送信可（窓内）   送信不可（窓外）
              ^SND.UNA     ^SND.NXT
              |<------ ウィンドウ幅 ------>|

• 区分2（SND.UNA から SND.NXT）: 送ったがACK待ちの未確認データ。
• 区分3: まだ送っていないが窓に空きがあり送れるデータ。

ACKが届くと左端（SND.UNA）が右へ進み、窓全体が右へ「滑る」。これがスライディングの名の由来です。受信側がバッファを読み出して空きが増えれば広告ウィンドウが拡大し、アプリの読み出しが遅れて空きが尽きれば広告ウィンドウは0になります。これを ゼロウィンドウ と呼びます。

ウィンドウスケーリング：16ビットの壁を越える

ヘッダのウィンドウ欄は16ビット、つまり最大65,535バイト（約64KB）しか表現できません。ここに高速回線時代の根本問題があります。

リンクを満たすのに必要な未確認データ量は 帯域遅延積（BDP, Bandwidth-Delay Product） で決まります。

BDP = 帯域 × RTT
例: 1Gbps × 100ms = 約12.5MB

BDPが12.5MBの経路で窓が64KBしか取れなければ、64KB送るたびにACKを待って停止し、回線の0.5%しか使えません。窓が小さいほどスループットが頭打ちになる関係は 帯域・レイテンシ・スループット の通りです。

これを解くのが ウィンドウスケールオプション（RFC 7323） です。原理は単純で、広告する窓の値に左シフト量（スケールファクタ）を掛けて解釈させます。

実際の受信窓 = ヘッダのウィンドウ値 << スケールファクタ

ここで決定的に重要なのは、スケールファクタはコネクション確立時の3ウェイハンドシェイクでしか交渉できない ことです。SYNとSYN-ACKの両方にオプションが載って初めて双方向で有効になり、片方が載せなければそのコネクションは全期間スケーリング無効です。確立後の途中変更はできません。ハンドシェイクの流れは TCPの状態遷移とコネクション確立・切断の内部 を参照してください。

Silly Window Syndrome：細切れが効率を壊す

スライディングウィンドウには Silly Window Syndrome（SWS、愚かな窓症候群） という固有の病があります。受信アプリが1バイトずつ読み、そのたびに「1バイト空きました」と広告すると、送信側も1バイトずつ送る。40バイト以上のヘッダ（IP+TCP）で1バイトのデータを運ぶ、極端に非効率な状態に陥ります。

原因は送受の両側にあり、対策も両側で行います。

Nagleアルゴリズムの判断規則

送信側の対策が Nagleアルゴリズム です。規則は一行で表せます。

未確認の送信データが存在する間は、
MSS未満のセグメントを送らずバッファに溜める。
（全データがACKされるか、MSS分溜まったら送る）

狙いは小さな書き込みを束ねて1つのフルサイズセグメントに合体させ、ヘッダ比率を下げることです。telnetのような対話型でも、往復の間に溜まった打鍵をまとめて送れます。

この相互作用は、HTTPのような小さなリクエストを送って即レスポンスを待つ通信で特に顕著です。だからレイテンシ重視のアプリは TCP_NODELAY でNagleを無効化するのが定石です。

TCP_NODELAY 有効 → Nagleを切る。小セグメントを即送信。
  対話・RPC・HTTPなど低遅延優先の用途で設定する。
バルク転送（大ファイル）では Nagle を残す方が効率的。

つまりNagleは万能ではなく、スループット最適化（束ねる）とレイテンシ最適化（即送る）のトレードオフ を体現するスイッチです。用途で判断します。

まとめ

フロー制御は受信側バッファをスライディングウィンドウで保護する仕組みで、ネットワークを守る輻輳制御とは独立し、実効送信窓は両者の最小値でした。16ビット窓の64KB制限は高BDP路で致命的になるため、ウィンドウスケールオプションがハンドシェイク時にだけ左シフト量を交渉し最大1GBへ拡張します。そしてSWS・Nagle・Delayed ACKは「効率」と「遅延」のせめぎ合いとして相互作用し、用途に応じて TCP_NODELAY で調停します。コネクションの状態遷移と合わせて押さえると、観測した転送の遅さを原理から切り分けられるようになります。