TCP の信頼性 ── 再送・ウィンドウ・輻輳制御

学習目標

本講を終えると、以下の問いに答えられるようになります。

• TCP の 5 つの特徴(コネクション指向・信頼性・順序保証・フロー制御・輻輳制御) をそれぞれ一言で説明できる
• TCP セグメントの主要フィールド(ポート番号・シーケンス番号・ACK 番号・フラグ・受信ウィンドウ・チェックサム) の役割を述べられる
• 3-way handshake(SYN / SYN+ACK / ACK) と 4-way close(FIN / ACK / FIN / ACK) の手順と意味を図解できる
• 累積 ACK と 重複 ACK(3 重 ACK)による高速再送 のしくみを区別できる
• 受信ウィンドウ(rwnd) によるフロー制御と、輻輳ウィンドウ(cwnd) による輻輳制御の役割の違いを説明できる
• 輻輳制御の 4 フェーズ(slow start / congestion avoidance / fast retransmit / fast recovery) と AIMD の考え方を述べられる
• RTT 推定と RTO、Nagle アルゴリズム、Delayed ACK といった補助メカニズムの目的を理解する

このレッスンの目次

TCP の 5 つの特徴 ── 何を保証してくれるのか

5 つの特徴を 1 行で

補足:「コネクション指向」の「指向」とは

指向は「その考え方を中心に設計されている」という意味です。TCP の コネクション指向 は、通信路が物理的に 1 本の専用線になるという意味ではありません。実際には、IP パケットは毎回独立に転送されます。ただし TCP は、送信側と受信側が コネクションの状態 を持ち、シーケンス番号・ACK・ウィンドウなどを使って、アプリから見ると 1 本の会話が続いている ように扱います。

もう一つ:全二重(full-duplex)

TCP は 全二重通信 です。1 つのコネクションの中で、両端が 同時に データを送り合えます。ヘッダの ACK 番号フィールド を使って、受信したことの通知(ACK) は 反対方向のデータに相乗り させて運べます ── これを ピギーバック(piggyback) と呼び、ACK のためだけにわざわざ別パケットを出す無駄を省きます。

TCP セグメントの構造 ── ヘッダの読み方

大きな図 ① TCP ヘッダ

図の見方:1 行が 32 ビット(4 バイト)。最初の 5 行(20 バイト) が 必須ヘッダ、その下にオプションが入って、さらに下が アプリのデータ。色は機能ごとの分類で、青=多重化(ポート)、黄=順序・到達確認(Seq/ACK)、赤=制御フラグ、緑=フロー制御(rwnd)、水色=誤り検出を表しています。

主要フィールド早見表

フラグビットの意味

コネクションの確立と解放 ── 状態遷移を歩く

大きな図 ② コネクションを 8 ステップで体験(walkthrough)

図の見方:左が時間軸の早い順に、上から下へセグメントが流れます。① 〜 ③ が 3-way handshake、④ 〜 ⑤ が確立中のデータ送受信(双方向・累積 ACK + ピギーバック)、⑥ 〜 ⑧ が 4-way close。「次へ」ボタンで矢印が進みます。

シーケンス番号と確認応答 ── ストリームをバイトで数える

例:500,000 バイトのファイルを 1,000 バイトずつ送る

1 つ目のセグメントは seq = 0(ファイルの 0 バイト目から開始)、2 つ目は seq = 1000、3 つ目は seq = 2000 ……となります。受信側が「3000 バイト目まで受け取った」なら、ACK には 3000(= 次に欲しいバイト番号) を入れて返します。

図の見方:Seq 番号は「このセグメントの先頭バイトのストリーム上の位置」を表します。1 つ前のセグメントの長さを足したものが次の Seq になります。受信側はこの番号を見て 並べ直し ます ── ネットワーク経路の違いで順序が乱れて到着しても、アプリには順番通りに渡せます。

累積 ACK(cumulative ACK) のからくり

TCP の ACK は 「ここまで連続して受け取りましたよ」 という意味です。仮に受信側が seq=1000 と seq=2000 を受け取ったら、ACK = 3000(次の期待バイト) を返します。途中の ACK が 1 つロスしても、後の ACK が届けば前の ACK の役割も兼ねるので問題ありません。

図の見方:上段では 0, 1000, 2000, 3000 が順に届くので ACK も 1000, 2000, 3000, 4000 と進む。下段では seq=1000 が欠けているため、後ろの 2000 や 3000 が届いても ACK は 1000 のまま止まる。この同じ ACK の繰り返しが重複 ACK。

再送制御 ── 失われたセグメントを取り戻す 2 つの道

(A) 再送タイムアウト(RTO)による再送

セグメントを送ったら、送信側は 再送タイマ を起動します。一定時間(RTO, Retransmission Time Out) 経っても ACK が返ってこなければ 「ロスしたとみなして再送」 します。安全策ですが、タイマ満了を待つ分 遅延が大きい のが弱点です。

(B) 高速再送(Fast Retransmit)── 重複 ACK を見て早めに再送

累積 ACK のしくみ上、あるセグメントだけが欠けて後続が届くと、受信側は同じ ACK を何度も返します(=重複 ACK)。送信側は 同じ ACK を 4 つ受け取った時点(= 重複 ACK が 3 つ来た時点) で、タイマを待たずに 即座にそのセグメントを再送 します。これが高速再送です。

大きな図 ③ RTO 再送と高速再送の違い

図の見方:上段の RTO 再送 は ACK が戻らないため、送信側はタイマが切れるまで待ってから再送する。下段の 高速再送 は、後続セグメントが届くたびに受信側が同じ ACK を返すので、送信側が 「同じ ACK が続く = その手前が欠けている」 と判断して、RTO を待たずに再送する。

RTO 再送と高速再送の違い

フロー制御 と 輻輳制御 ── 似て非なる 2 つのウィンドウ

フロー制御 ── 相手の PC の負荷を大きくしすぎない

受信ウィンドウ(rwnd) は、相手の PC(受信側)が「今あと何バイトまでなら受け取れますよ」を ACK のヘッダで通知する仕組みです。相手のアプリ処理が進まず受信バッファが詰まっているときに、こちらがさらにパケットを送り続けると、相手 PC の負荷が大きくなりすぎます。そこで送信側は rwnd を超えてデータを送りません。

図の見方:相手 PC のアプリ処理が遅いと、届いたデータが受信バッファに残り続ける。空きが少ないと相手は ACK の中で rwnd を小さく通知 し、送信側は送る量を抑える。これにより、相手 PC にさらに大量のパケットを押し込んで負荷を大きくしすぎることを防ぐ。

もし rwnd を無視して送り続けると、相手 PC の受信バッファが溢れてセグメントを 捨てる しかなくなり、結局再送が増えてしまいます。フロー制御は 「速い送信側が、処理の追いつかない受信側を踏み潰さない」 ためにあるのです。

輻輳制御 ── ネットワーク全体の混雑を抑える

輻輳ウィンドウ(cwnd) は 送信側が自分で決める 値で、「今ネットワークがどれくらい受け入れられそうか」の見積もりです。ヘッダのフィールドではなく、送信側ホストの内部状態として保持されます。

送信側が一度に投げ入れる量は、実は次の 最小値 で決まります。

みんなが好き勝手に大量のデータを送ると、ルータのバッファが溢れて 輻輳(ふくそう) が起きます。すると大量のロスが起き、再送がさらに混雑を加速させ、最悪 輻輳崩壊(congestion collapse) に至ります。これを防ぐため、TCP は「ロスを観測したら自分で送信レートを落とす」協調動作をします。

横並びで比較

送信側はこの 2 つの両方に従って送出量を決めます。「rwnd と cwnd の小さい方」 ── これが鉄則です。

輻輳制御の 4 フェーズ ── slow start / avoidance / fast retx / fast recovery

① slow start(スロースタート) ── 小さく始めて指数関数的に立ち上げる

コネクション開始直後は cwnd を 非常に小さい値(初期は 1 〜 10 MSS [要確認:現代の初期値は IW=10]) から始め、ACK が 1 つ返るごとに cwnd を 1 MSS ずつ増やす ── これにより 1 RTT ごとに cwnd は 2 倍 になっていきます(1 → 2 → 4 → 8 → …)。指数増加です。

「スロー」と呼ぶのは、初期 TCP は要求した分すべてを一気に投げていた のに対して、最初は控えめに立ち上げる、という意味です。実際の伸び方は決して遅くありません。

② congestion avoidance(輻輳回避) ── 線形に増やす

cwnd が 閾値(ssthresh, slow start threshold) に達したら、増加を 1 RTT ごとに +1 MSS の 線形増加 に切り替えます。これが AIMD の 「加算増加」 部分です。容量近くまで来ているはずなので、急加速で詰まらないよう慎重に伸ばします。

③ fast retransmit(高速再送) ── 軽い輻輳の検知

3 重 ACK を受け取ったら、上で見たように 失われたセグメントを即再送。同時に 「軽い輻輳」 と判断し、ssthresh を現在の cwnd の半分にして、cwnd 自体も小さくします。これが AIMD の 「乗算減少」 部分(× 1/2)です。

④ fast recovery(高速回復) ── スロースタートに戻らず復帰

Reno の特徴で、3 重 ACK 後は slow start に戻らず、ssthresh の位置から再び 輻輳回避(線形増加)で再開 します。「ちょっと欠けただけならパイプはまだ機能している」という前向きな判断です。一方 RTO 再送 は重い輻輳とみなし、cwnd=1 MSS から slow start でやり直し です。

大きな図 ④ 輻輳ウィンドウの増減アニメーション

図の見方:横軸は時間(RTT 数)、縦軸は cwnd。青=slow start で指数増加 → ssthresh で 緑=輻輳回避 に切替えて線形増加 → 赤の 3 重 ACK で半減し fast recovery で輻輳回避に戻る → 紫の RTO が起きると cwnd=1 まで落として slow start からやり直し。これが TCP Reno の「のこぎり波」パターンです。

AIMD ── 公平性の数学

AIMD(Additive Increase, Multiplicative Decrease) は、複数の TCP コネクションが同じボトルネック回線を共有する際に 長期的に帯域を公平に分け合う という重要な性質を持ちます。直感的には:

• 加算増加(+1):全員が同じ速さで上に伸びる
• 乗算減少(× 1/2):大きく取りすぎているコネクションのほうが 絶対値として大きく削られる

この組み合わせを繰り返すと、各コネクションのスループットは 「公平な帯域共有」点 に収束していきます ── これが TCP の公平性 と呼ばれる古典的な結果です。

RTT 推定 / Nagle / Delayed ACK ── 周辺の最適化

RTT(Round Trip Time) と RTO の決め方

RTT は「セグメントを送ってから、その ACK が返るまでの往復時間」。RTO はこの RTT より少し長く取らないと「まだ来ていないのに再送」という誤判定になります。だが長すぎると、ロス時の復旧が遅れます。

Linux などの実装は EWMA(指数加重移動平均) で SRTT(平滑化 RTT) と RTTVAR(RTT のばらつき) を更新し、おおむね次の式で決めます(Jacobson / Karels アルゴリズム, RFC 6298):

Nagle アルゴリズム ── 小さなパケットをまとめて投げる

たとえばエディタで 1 文字打つたびに 1 バイトの TCP セグメントが飛ぶと、ヘッダ(IP+TCP で最低 40 バイト) のオーバーヘッドが 40 倍になり、ネットワークが「小パケットだらけ」で詰まります。Nagle アルゴリズム(RFC 896, 1984) は 「ACK が返るまで、新しい小データはバッファに溜めて送らない」 ルールで、小さな送信を自動的に束ねます。

Delayed ACK ── ACK 専用パケットを減らす

ACK だけを送るセグメントもオーバーヘッドが大きいので、受信側は ACK を少し遅らせて、(a) 反対方向のデータにピギーバックできれば乗せる、(b) できなくても 200 ms 程度経つか、もう 1 セグメント受け取ったタイミングで返す、という最適化をします。これが Delayed ACK(RFC 1122) です。

まとめと用語チェック

用語チェック

確認問題