RFC 9293: TCP

RFC 793以来40年分の追補と正誤で散らばっていたTCP仕様をRFC 9293が単一のSTDへ統合し、3ウェイハンドシェイクから状態機械・フロー制御・TIME-WAITの理由まで現代の実装が拠るべき決定版として読み解ける。

応用RFCTCPネットワークプロトコルTCP/IP最終更新: 2026-07-29
3つの要点
TL;DR
  1. RFC 9293はRFC 793(1981年)を置換するTCPの現行標準(STD 7)。ISN乱数化や緊急ポインタ非推奨など、長年の追補・正誤・ホスト要件を1本へ統合した。
  2. SYN→SYN/ACK→ACKで確立し、シーケンス番号とACKで順序・欠落を管理する。広告ウィンドウで受信側の過負荷を防ぎ、輻輳制御はRFC 5681などへ委ねる。
  3. 接続はLISTENからTIME-WAITまでの状態機械で管理する。能動切断側は2×MSL待ち、最終ACKの再送機会を確保し、旧接続の遅延セグメントが新接続へ混入するのを防ぐ。

このRFCが決めたこと

TCPは1981年のRFC 793で標準化されて以来、インターネットの信頼ある通信を支えてきました。しかし40年の間に、初期シーケンス番号(ISN)の予測攻撃対策、緊急ポインタ(URG)の扱い、ホスト要件の補足といった追補・更新・正誤(errata)が別々のRFCとして積み重なり、実装者は全体像を掴むのに十数本を継ぎ接ぎで読む必要がありました。

2022年8月に公開されたRFC 9293は、この散逸した知見をひとつの権威ある文書へ統合し、RFC 793を正式に置き換えました。あわせてRFC 879・6093・6528・6691などを廃止吸収し、RFC 1122などを更新しています。位置づけはInternet Standard、すなわちSTD 7です。新しいプロトコルを発明したのではなく、現に動いている現代のTCPを1本に書き下したことが本RFCの意義です。

統合された主な明確化

ISNの乱数化による接続乗っ取り対策(旧RFC 6528)、緊急ポインタ機構の非推奨化(旧RFC 6093)、必須(MUST)と推奨(SHOULD)の区別の徹底などが本文へ織り込まれました。輻輳制御はあえて範囲外とし、RFC 5681やRFC 6298へ委ねる方針も明記されています。

ハンドシェイクと状態機械

横にスクロール

TCPがCLOSED LISTENからSYN SYN ACK ESTABLISHED FIN TIME WAITへ遷移する図
TCPの三方向ハンドシェイク、信頼配送、流量/輻輳制御と接続終了を示します。

TCP接続は、両端が互いの初期シーケンス番号を交換し合意する3ウェイハンドシェイクで始まります。

クライアント                        サーバー
  CLOSED                            LISTEN
    | --- SYN seq=x ------------>     |
 SYN-SENT                        SYN-RECEIVED
    | <-- SYN seq=y, ACK x+1 ----     |
    | --- ACK y+1 ------------->      |
 ESTABLISHED                      ESTABLISHED

各エンドポイントは、CLOSED・LISTEN・SYN-SENT・SYN-RECEIVED・ESTABLISHEDといった状態を遷移していきます。RFC 9293はこの状態機械を、受信セグメントのフラグと現在状態の組み合わせに対する動作として厳密に定義します。ISNを固定値ではなく時刻ベースの乱数から選ぶのは、第三者にシーケンス番号を推測されてセグメントを注入されるのを防ぐためで、これも本RFCが取り込んだ重要な明確化です。

信頼性とフロー制御

TCPが信頼性を持つと言われる根拠は、シーケンス番号と確認応答番号(ACK番号)にあります。送信側は各バイトへ連続した番号を振り、受信側は次に期待するバイト番号をACKで返します。一定時間ACKが来なければ再送し、重複や順序の乱れは番号で検出・整列します。

流量の調整はスライディングウィンドウが担います。受信側はヘッダのウィンドウ欄で、あと何バイト受け取れるかを広告し、送信側はその範囲を超えて送りません。これがフロー制御で、遅い受信側のバッファ溢れを防ぎます。混同しやすいのが輻輳制御ですが、両者は目的が異なります。

観点フロー制御輻輳制御
守る相手遅い受信側のバッファネットワーク経路の混雑
制御の主体受信側が広告するウィンドウ送信側が推定する輻輳ウィンドウ
規定する文書RFC 9293本体RFC 5681ほか(範囲外)

RFC 9293がフロー制御だけを定め、スロースタートや輻輳回避といった輻輳制御を別RFCへ委ねるのは、輻輳制御が進化し続ける領域だからです。仕様の中核と可変部分を切り離したわけです。

つまずきやすい点

接続の終了は、各方向を独立に閉じる4ウェイの手順を踏みます。片側がFINを送るともう一方はACKを返し、やがて自分のFINを送り返します。

(能動的に閉じる側)              (相手側)
 ESTABLISHED                    ESTABLISHED
   | --- FIN ----------->          |
 FIN-WAIT-1                     CLOSE-WAIT
   | <-- ACK -----------           |
 FIN-WAIT-2                        |(close待ち)
   | <-- FIN -----------        LAST-ACK
   | --- ACK ----------->          |
 TIME-WAIT                       CLOSED
   |(2×MSL 待機)
 CLOSED

最大のつまずきはTIME-WAITです。能動的に閉じた側だけがこの状態に入り、最大セグメント寿命(MSL)の2倍だけ待ってからCLOSEDへ移ります。理由は2つあります。第一に、自分が最後に送ったACKが失われても、相手のFIN再送へ応答できるようにするため。第二に、同じ4つ組(送信元と宛先のIP・ポート)で新しい接続を張ったとき、前の接続の遅延セグメントが紛れ込むのを、旧セグメントが寿命で消えるまで待って防ぐためです。

TIME-WAITは異常ではない

サーバーで大量のTIME-WAITが見えても多くは正常です。能動クローズ側に生じる仕様どおりの状態で、短命な接続を大量に閉じるほど積み上がります。安易にMSLやTIME-WAITを削るとセグメント混入のリスクを招くため、まずは接続の使い回しを検討すべきです。

まとめ

RFC 9293は新機軸ではなく、40年分の実装知を単一のSTDへ束ね直した決定版のTCPです。3ウェイハンドシェイクと状態機械が接続の一生を規定し、シーケンス番号とスライディングウィンドウが信頼性とフロー制御を支え、輻輳制御は意図的に外部RFCへ委ねられます。TIME-WAITのような細部まで理由を辿れば、TCPがなぜこう設計されたかが腑に落ちるはずです。TCPとUDPの対比はTCPとUDP、プロトコル階層の全体像はTCP/IP、他の規格はRFC精読を参照してください。

RFC精読の記事ガイド

RFC 9293: TCPを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

RFC

比較で見る軸

難易度: advanced / カテゴリ: RFC精読 / タグ数: 5

導入後に効く点

SYN→SYN/ACK→ACKで確立し、シーケンス番号とACKで順序・欠落を管理する。広告ウィンドウで受信側の過負荷を防ぎ、輻輳制御はRFC 5681などへ委ねる。

先に潰すリスク

用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。

数字・仕様の読み方
難易度
advanced
カテゴリ
RFC精読
タグ数
5

判断チェックリスト

  • 自社の用途が「RFC / TCP」に近いか確認する。
  • 強みである「RFC 9293はRFC 793(1981年)を置換するTCPの現行標準(STD 7)。ISN乱数化や緊急ポインタ非推奨など、長年の追補・正誤・ホスト要件を1本へ統合した。」が本当に評価軸になるか確認する。
  • 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

RFCTCPネットワークプロトコルTCP/IP