メインコンテンツまでスキップ

RFC 9293 - 伝送制御プロトコル (Transmission Control Protocol)

  • ステータス: Internet Standard
  • 発行日: August 2022
  • ストリーム: IETF
  • 更新: RFC1011, RFC1122, RFC5961
  • 廃止: RFC793, RFC879, RFC2873, RFC6093, RFC6429, RFC6528, RFC6691
  • エラッタ: エラッタなし

概要 (Abstract)​

本文書は伝送制御プロトコル (Transmission Control Protocol, TCP) を規定します。TCPはインターネットプロトコルスタックにおける重要なトランスポート層プロトコルであり、インターネットの使用と成長の数十年にわたって継続的に進化してきました。この期間に、RFC 793で指定されたTCPに多くの変更が加えられましたが、これらは断片的な方法でのみ文書化されてきました。本文書は、RFC 793のプロトコル仕様とともにそれらの変更を収集してまとめます。

本文書はRFC 793、およびRFC 793の一部を更新したRFC 879、2873、6093、6429、6528、6691を廃止します。RFC 1011および1122を更新し、TCP要件を扱うこれらの文書の部分の代替と見なされるべきです。また、SYN-RECEIVED状態でのリセット処理に小さな明確化を追加することでRFC 5961を更新します。RFC 793のTCPヘッダー制御ビットもRFC 3168に基づいて更新されています。

目次 (Table of Contents)​

附属書 (Appendices)​

関連リソース​

クイックリファレンス​

TCPとは？​

TCP (Transmission Control Protocol, 伝送制御プロトコル) は、インターネットプロトコルスタックにおける中核的なトランスポート層プロトコルであり、以下を提供します:

  • 接続指向 (Connection-Oriented) - 通信前に接続を確立
  • 信頼性のある伝送 (Reliable Transmission) - データが正しく到着することを保証
  • 順序付き配信 (Ordered Delivery) - 送信された順序でデータを受信
  • フロー制御 (Flow Control) - 受信者の過負荷を防止
  • 輻輳制御 (Congestion Control) - ネットワーク輻輳を回避

主要機能​

  • ✅ 3ウェイハンドシェイク - 接続確立
  • ✅ シーケンス番号メカニズム - 順序と信頼性を保証
  • ✅ 確認応答 - データ到着の確認
  • ✅ タイムアウト再送信 - パケット損失の処理
  • ✅ スライディングウィンドウ - フロー制御
  • ✅ 輻輳制御 - ネットワークの安定性

TCP vs UDP​

機能TCPUDP
接続接続指向コネクションレス
信頼性信頼性あり信頼性なし
順序保証あり保証なし
速度遅い速い
オーバーヘッド大きい小さい
用途HTTP, SMTP, FTP, SSHDNS, ビデオストリーミング, ゲーム

RFC 9293の重要性​

RFC 9293 vs RFC 793:

  • RFC 793 (1981) - 元のTCP仕様
  • RFC 9293 (2022) - 最新標準、40年の進化を統合
  • RFC 793および複数の更新を廃止
  • 現代のTCP実装要件を明確化
  • セキュリティとパフォーマンスのベストプラクティスを更新

主な改善点:

  • すべてのTCP拡張機能と正誤表を統合
  • 必須サポートオプションを明確化
  • 輻輳制御要件を更新
  • セキュリティの考慮事項を強化
  • 現代のネットワーク環境を反映

一般的なTCPポート​

  • HTTP: 80
  • HTTPS: 443
  • SMTP: 25
  • FTP: 20, 21
  • SSH: 22
  • Telnet: 23
  • POP3: 110
  • IMAP: 143

関連RFC:

  • RFC 768 - UDP (ユーザーデータグラムプロトコル)
  • RFC 791 - IP (インターネットプロトコル)
  • RFC 5681 - TCP輻輳制御
  • RFC 7323 - TCP拡張機能 (ウィンドウスケーリング、タイムスタンプ)
  • RFC 7413 - TCP Fast Open
  • RFC 8200 - IPv6仕様

附属書B. TCP要件の要約 (TCP Requirement Summary)​

本附属書では、RFC 9293全体でRFC 2119キーワード (MUST, SHOULD, MAY等) でマークされたすべての実装要件を要約します。

基本プロトコル要件​

MUST要件 (必須)​

  1. ヘッダー形式

    • TCP実装はRFC 9293で定義されたヘッダー形式に従わなければなりません (MUST)
    • 予約ビットはゼロに設定しなければなりません (MUST)
    • チェックサムフィールドは常に計算して送信しなければなりません (MUST)

  2. オプション処理

    • 最大セグメントサイズ (MSS) オプション (Kind 2) をサポートしなければなりません (MUST)
    • 認識されないオプションは無視しなければなりません (MUST)
    • オプションリスト終了 (EOL, Kind 0) とノーオペレーション (NOP, Kind 1) をサポートしなければなりません (MUST)

  3. シーケンス番号

    • 初期シーケンス番号 (ISN) は予測不可能な方法で選択しなければなりません (MUST)
    • シーケンス番号は各オクテットのデータを追跡しなければなりません (MUST)

  4. 接続管理

    • 3ウェイハンドシェイクを使用して接続を確立しなければなりません (MUST)
    • 適切な状態遷移に従わなければなりません (MUST)
    • TIME-WAIT状態を実装しなければなりません (MUST)

  5. データ伝送

    • 受信データを順序通りに配信しなければなりません (MUST)
    • セグメントチェックサムを検証しなければなりません (MUST)
    • ウィンドウサイズを尊重しなければなりません (MUST)

  6. エラー処理

    • 無効なチェックサムを持つセグメントを破棄しなければなりません (MUST)
    • 無効な状態でRSTを送信しなければなりません (MUST)

SHOULD要件 (推奨)​

  1. パフォーマンス

    • 実装はウィンドウスケーリングオプション (RFC 7323) をサポートすべきです (SHOULD)
    • 実装はタイムスタンプオプション (RFC 7323) をサポートすべきです (SHOULD)
    • 実装はSACK (Selective Acknowledgment, RFC 2018) をサポートすべきです (SHOULD)

  2. 輻輳制御

    • 実装は適切な輻輳制御アルゴリズムを使用すべきです (SHOULD)
    • RFC 5681で定義されたアルゴリズムに従うべきです (SHOULD)

  3. セキュリティ

    • 実装は予測可能なISN攻撃から保護すべきです (SHOULD)
    • 実装はブラインドイン・ウィンドウ攻撃を軽減すべきです (RFC 5961) (SHOULD)

MAY要件 (任意)​

  1. オプション機能

    • 実装は緊急ポインタメカニズムをサポートしてもかまいません (MAY)
    • 実装は追加のTCPオプションをサポートしてもかまいません (MAY)

  2. 最適化

    • 実装はNagleアルゴリズムを実装してもかまいません (MAY)
    • 実装は遅延ACKメカニズムを使用してもかまいません (MAY)

カテゴリ別詳細要件​

1. オプション処理​

必須 (MUST):

  • Kind 0 (EOL): オプションリスト終了
  • Kind 1 (NOP): ノーオペレーション
  • Kind 2 (MSS): 最大セグメントサイズ

推奨 (SHOULD):

  • Kind 3: ウィンドウスケール (RFC 7323)
  • Kind 4,5: SACK許可とSACK (RFC 2018)
  • Kind 8: タイムスタンプ (RFC 7323)

任意 (MAY):

  • その他の標準化されたオプション

2. シーケンス番号​

必須 (MUST):

  • ISNは暗号的に安全な乱数生成器を使用して生成しなければなりません
  • シーケンス番号は各オクテットのデータを追跡しなければなりません
  • 重複したセグメントを検出して破棄しなければなりません

推奨 (SHOULD):

  • シーケンス番号攻撃から保護すべきです (RFC 6528)

3. 接続管理​

必須 (MUST):

  • 3ウェイハンドシェイクを実装しなければなりません
  • 適切な接続状態遷移に従わなければなりません
  • TIME-WAIT状態を少なくとも2MSLの間維持しなければなりません
  • 同時オープンと同時クローズを処理しなければなりません

推奨 (SHOULD):

  • SYNクッキーまたは同等のメカニズムでSYNフラッド攻撃を軽減すべきです

4. データ伝送​

必須 (MUST):

  • データを順序通りに配信しなければなりません
  • ウィンドウサイズ制限を尊重しなければなりません
  • チェックサムを検証しなければなりません
  • 失われたセグメントを再送信しなければなりません

推奨 (SHOULD):

  • 適切なタイムアウトメカニズムを実装すべきです
  • 輻輳制御アルゴリズムを使用すべきです

5. エラー処理​

必須 (MUST):

  • 無効なチェックサムを持つセグメントを破棄しなければなりません
  • 無効な状態でRSTを送信しなければなりません
  • 範囲外のACKを適切に処理しなければなりません

推奨 (SHOULD):

  • ブラインドリセット攻撃を軽減すべきです (RFC 5961)

実装チェックリスト​

コア機能​

  • 完全なTCPヘッダー処理
  • 3ウェイハンドシェイク
  • 4ウェイ接続終了
  • シーケンス番号管理
  • チェックサム計算と検証
  • 基本的なフロー制御 (ウィンドウメカニズム)
  • 再送信メカニズム
  • TIME-WAIT状態処理

必須オプション​

  • MSS (最大セグメントサイズ) オプション
  • EOL (オプションリスト終了)
  • NOP (ノーオペレーション)

推奨機能​

  • ウィンドウスケーリング (RFC 7323)
  • タイムスタンプオプション (RFC 7323)
  • SACK (Selective Acknowledgment, RFC 2018)
  • 適切な輻輳制御 (RFC 5681)
  • ECN (Explicit Congestion Notification, RFC 3168)

セキュリティ機能​

  • 安全なISN生成
  • SYNフラッド保護
  • ブラインドイン・ウィンドウ攻撃軽減 (RFC 5961)
  • シーケンス番号検証

パフォーマンス最適化​

  • 遅延ACK
  • Nagleアルゴリズム
  • 高速再送信と高速リカバリ
  • 適切なRTT測定

要件レベルの定義​

RFC 2119で定義された通り:

  • MUST / REQUIRED / SHALL: 絶対的要件
  • MUST NOT / SHALL NOT: 絶対的禁止
  • SHOULD / RECOMMENDED: 正当な理由がある場合を除き従うべき
  • SHOULD NOT / NOT RECOMMENDED: 正当な理由がある場合を除き避けるべき
  • MAY / OPTIONAL: 真の任意項目

注: 完全な要件の詳細とコンテキストについては、RFC 9293の本文を参照してください。本附属書は便宜的な要約を提供しますが、公式仕様を置き換えるものではありません。