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

RFC 7413 - TCP Fast Open

  • ステータス: Experimental
  • 発行日: December 2014
  • ストリーム: IETF
  • エラッタ: エラッタなし

概要​

本文書は、TCP Fast Open (TFO) と呼ばれる実験的な TCP メカニズムについて説明します。TFO は、TFO Cookie（TCP オプションフィールド）を使用して以前接続したクライアントを検証することにより、TCP ハンドシェイク中のデータ交換を可能にします。これにより、新しい TCP 接続のレイテンシが削減され、Web サービスなどのレイテンシに敏感なアプリケーションにとって特に価値があります。

技術的重要性: TCP Fast Open は、HTTP リクエスト-レスポンス時間を 1 往復時間 (RTT) 分短縮でき、特に短期接続に有効です。

目次​

主要セクション​

付録​

主要な技術ポイント​

  • Cookie 生成: サーバーはクライアント IP アドレスに基づく暗号化を使用して Cookie を生成
  • Cookie 検証: クライアントは後続の接続で Cookie を含めて検証
  • データ転送: 検証が成功すると、SYN パケット内のデータをアプリケーション層で受信可能

パフォーマンス上の利点​

  • 1 RTT 分のレイテンシを削減
  • 短期接続やリクエスト-レスポンスパターンに特に適している
  • Web ブラウジングや API 呼び出しのパフォーマンスが大幅に向上

セキュリティ保護​

  • 増幅攻撃を防止: SYN データサイズを制限
  • リソース枯渇を防止: Cookie 検証メカニズム
  • 互換性: 従来の TCP と透過的に共存

関連 RFC​

  • RFC 793: Transmission Control Protocol
  • RFC 6994: Shared Use of Experimental TCP Options
  • RFC 7323: TCP Extensions for High Performance

実装状況​

この RFC は実験的であり、いくつかの主要なオペレーティングシステムに実装されています:

  • Linux カーネル (3.6+)
  • Apple iOS および macOS
  • Windows 10 (1607+)

注意: 実験的ステータスは、このメカニズムがまだ評価中であることを意味します。実装時にはセキュリティと互換性への影響を慎重に考慮する必要があります。

1. はじめに (Introduction)​

1.1. 動機 (Motivation)​

従来の TCP 接続確立には 3 ウェイハンドシェイク (three-way handshake) が必要であり、データ転送が開始される前に少なくとも 1 往復時間 (Round-Trip Time, RTT) の遅延が発生します。多くの現代のアプリケーション、特に Web サービスやモバイルアプリにとって、この遅延は重大なパフォーマンスのボトルネックです。

典型的なシナリオの遅延問題​

従来の TCP では、クライアントは以下の手順を踏む必要があります。

  1. SYN パケットを送信
  2. サーバーの SYN-ACK 応答を待機
  3. ACK 確認を送信
  4. 最後にアプリケーションデータを送信

これはアプリケーションデータの転送に少なくとも 1.5 RTT が必要であることを意味します（サーバーが ACK 受信後すぐに応答すると仮定した場合）。

HTTP 短期接続の課題​

HTTP リクエスト-レスポンスパターンでは以下の問題があります。

  • 新しい接続ごとに完全な 3 ウェイハンドシェイクが必要
  • 短期接続（例：単一の API 呼び出し）では、ハンドシェイクの遅延が総時間に占める割合が大きい
  • 高遅延ネットワーク（モバイルネットワークなど）ではこの問題がより深刻

1.2. 主要概念 (Key Concepts)​

TCP Fast Open (TFO) は、TCP ハンドシェイク中にデータを交換できるようにすることでこの問題を解決します。

TFO Cookie はクライアントの身元を検証するための暗号化トークンです。

  1. Cookie リクエストフェーズ：

    • クライアントは初回接続時に TFO Cookie をリクエスト
    • サーバーは Cookie を生成して返す（クライアント IP アドレスに基づいて暗号化）
    • クライアントは後続の使用のために Cookie をキャッシュ

  2. Fast Open フェーズ：

    • クライアントは SYN パケットに Cookie とアプリケーションデータを含める
    • サーバーは Cookie の有効性を検証
    • 検証が通過した場合、サーバーは SYN データを受け入れ、即座に応答できる

パフォーマンス向上​

TFO 使用後のデータ転送タイムライン：

  1. 初回接続：クライアントが SYN を送信（Cookie をリクエスト）
  2. 後続接続：クライアントが SYN + Cookie + データを送信 → サーバーが即座に処理

遅延削減：1 完全 RTT を節約

セキュリティ設計​

TFO Cookie メカニズムは以下のセキュリティ保護を提供します。

  • 増幅攻撃防止 (Anti-Amplification)：SYN データパケットサイズを制限
  • リソース枯渇防止 (Anti-Resource Exhaustion)：Cookie 検証によりクライアントの身元を確認
  • 後方互換性 (Backward Compatibility)：TFO をサポートしないサーバーはオプションを無視

用語定義 (Terminology)​

RFC 2119 の規定に従い、本文書のキーワードの意味は以下の通りです。

  • MUST（しなければならない）：絶対的な要件
  • SHOULD（すべきである）：強く推奨されるが特定の状況では無視できる
  • MAY（してもよい）：完全にオプションの機能

適用シナリオ (Use Cases)​

TFO は以下のシナリオに特に適しています。

  • Web ブラウジング：HTTP/HTTPS リクエスト
  • API 呼び出し：RESTful API、RPC
  • モバイルアプリ：頻繁な短期接続リクエスト
  • IoT デバイス：定期的なデータ送信

制限と考慮事項 (Limitations)​

TFO 使用時の注意事項：

  • SYN データは再送される可能性がある（冪等性の要件）
  • 一部のネットワーク機器が TCP オプションを妨害する可能性がある
  • Cookie には有効期限があり、定期的な更新が必要

2. プロトコル概要 (Protocol Overview)​

本章では TCP Fast Open の完全なワークフロー（Cookie リクエスト、付与、使用プロセスを含む）を説明します。

クライアントはサーバーへの初回接続時に TFO Cookie を取得する必要があります。

メッセージフロー​

クライアント                          サーバー
   |                                    |
   |  SYN + TFO Cookie リクエスト (空)  |
   |---------------------------------->|
   |                                    |
   |  SYN-ACK + TFO Cookie             |
   |<----------------------------------|
   |                                    |
   |  ACK                               |
   |---------------------------------->|
   |                                    |
   |  アプリケーションデータ            |
   |<--------------------------------->|

TCP オプション形式​

Cookie リクエストオプション：

  • Kind: 34 (TCP Fast Open)
  • Length: 2 (オプションヘッダーのみ、Cookie データなし)
  • Cookie: 空（Cookie のリクエストを示す）

サーバーは Cookie リクエストを受信後、Cookie を生成して返します。

サーバーは以下の情報を使用して Cookie を生成します。

  • クライアント IP アドレス
  • サーバーシークレット (Server Secret)
  • タイムスタンプ（Cookie の有効期限用）
Cookie = AES-128(ServerSecret, ClientIP || Timestamp)

TCP オプション形式​

Cookie 付与オプション：

  • Kind: 34
  • Length: 6 〜 18（2 バイトヘッダー + 4 〜 16 バイト Cookie）
  • Cookie: サーバーが生成した暗号化トークン

2.3. TCP Fast Open 接続 (Fast Open Connection)​

クライアントは後続の接続でキャッシュされた Cookie を使用して Fast Open を実現します。

メッセージフロー​

クライアント                          サーバー
   |                                    |
   |  SYN + TFO Cookie + データ        |
   |---------------------------------->|
   |                                    | (Cookie を検証)
   |                                    | (データを処理)
   |  SYN-ACK + データ                 |
   |<----------------------------------|
   |                                    |
   |  ACK                               |
   |---------------------------------->|

主要な利点​

遅延節約：

  • 従来の TCP：1 RTT（ハンドシェイク）+ 1 RTT（リクエスト-レスポンス）= 2 RTT
  • TCP Fast Open：1 RTT（ハンドシェイク+リクエスト-レスポンス）= 1 RTT 節約

SYN データの制限​

増幅攻撃を防ぐため、SYN パケット内のデータは制限されます。

  1. 最大データ長：

    • Linux 実装：デフォルトで MSS（最大セグメントサイズ）に制限
    • 典型値：約 1460 バイト（イーサネット MTU 1500 - IP/TCP ヘッダー）

  2. データ要件：

    • MUST：データは冪等でなければならない（安全に再送可能）
    • SHOULD：データは完全なリクエストであるべき（完全な HTTP リクエストなど）

有効期間管理：

  • 典型的な有効期間：数時間から数日
  • 更新戦略：クライアントは定期的に新しい Cookie をリクエストできる
  • 期限切れ処理：Cookie が期限切れになると、サーバーは Fast Open を拒否し、クライアントは標準ハンドシェイクにフォールバック

Cookie は以下の状況で無効になる場合があります。

  1. 時間切れ：サーバーが設定した有効期間を超過
  2. サーバーキーの更新：サーバーが暗号化キーをローテーション
  3. IP アドレスの変更：クライアントの IP アドレスが変更（モバイルネットワーク）
  4. サーバーポリシー：サーバーが Cookie を積極的に無効化（セキュリティ上の理由）

2.5. プロトコル相互作用の概要 (Protocol Interaction Summary)​

完全なライフサイクル​

フェーズ 1：初期化
   クライアント ──SYN(Cookie リクエスト)──> サーバー
   クライアント <──SYN-ACK(Cookie)─────── サーバー
   クライアント ──ACK──────────────────> サーバー
   [クライアントが Cookie をキャッシュ]

フェーズ 2：Fast Open（複数回）
   クライアント ──SYN(Cookie+Data)──> サーバー
   クライアント <──SYN-ACK(Data)───── サーバー
   クライアント ──ACK──────────────> サーバー
   [1 RTT 節約]

フェーズ 3：Cookie 更新（必要時）
   フェーズ 1 を繰り返す

互換性マトリックス​

クライアントサーバー結果
TFO サポートTFO サポートFast Open 成功
TFO サポートTFO 非サポート標準 TCP にフォールバック
TFO 非サポートTFO サポート標準 TCP
TFO 非サポートTFO 非サポート標準 TCP

3. プロトコルの詳細 (Protocol Details)​

本章では TCP Fast Open の技術的な実装の詳細（オプション形式、状態機械の遷移、データ処理ルールを含む）を詳しく説明します。

TCP オプション形式​

+-------------+-------------+
|   Kind=34   |  Length=2   |
+-------------+-------------+

フィールド説明：

  • Kind: 8 ビット、値は 34（TCP Fast Open 実験的オプション番号）
  • Length: 8 ビット、値は 2（Cookie データなし、これはリクエスト）

クライアントの動作仕様​

クライアントが Cookie をリクエストする際に MUST 従うこと：

  1. 初回接続：

    • SYN パケットの TCP オプションに Kind=34, Length=2 を含める
    • アプリケーションデータを運ばない
    • 通常の 3 ウェイハンドシェイクを完了する

  2. 再送処理：

    • SYN パケットを再送する必要がある場合、MUST TFO オプションを保持する

TCP オプション形式​

+-------------+-------------+-------------------+
|   Kind=34   |   Length    |  Cookie (4-16バイト)|
+-------------+-------------+-------------------+

フィールド説明：

  • Kind: 8 ビット、値は 34
  • Length: 8 ビット、値は 6 〜 18（2 + Cookie 長）
  • Cookie: 4 〜 16 バイトの暗号化トークン

推奨される Cookie の内部構造：

Cookie = AES-128(ServerSecret, ClientIP || Timestamp || Counter)

構成要素：
- ClientIP:   クライアント IP アドレス (4 または 16 バイト)
- Timestamp:  Unix タイムスタンプ (4 バイト)
- Counter:    リプレイ防止カウンター (オプション、4 バイト)

サーバーの実装要件​

MUST 実装：

  • Cookie はクライアント IP アドレスにバインドされなければならない
  • Cookie は検証可能でなければならない（MAC または暗号化を使用）
  • Cookie には有効期限がなければならない

SHOULD 実装：

  • 強力な暗号化アルゴリズムを使用（AES-128 など）
  • キーローテーションメカニズムを実装
  • Cookie 使用統計を記録

3.3. TCP Fast Open 接続 (Fast Open)​

クライアントの送信仕様​

クライアントが Fast Open を使用する際に MUST 従うこと：

  1. Cookie の包含：

    • SYN パケットの TCP オプションにキャッシュされた Cookie を含める
    • Cookie は対象サーバーから受信した有効な Cookie でなければならない

  2. データの運搬：

    • SYN パケットにアプリケーションデータを含めることができる
    • データ長は MSS を超えてはならない (MUST NOT)
    • データは冪等でなければならない (MUST)（安全に再送可能）

サーバーの受信仕様​

サーバーが Fast Open SYN を受信した際の処理フロー：

SYN + TFO Cookie + Data を受信
   ↓
1. Cookie を検証
   ├─ Cookie 形式チェック
   ├─ IP アドレス一致チェック
   ├─ タイムスタンプ検証（期限切れかどうか）
   └─ MAC/署名検証
   ↓
2. Cookie 検証結果
   ├─ 有効 → ステップ 3 に進む
   └─ 無効 → データを破棄、標準 SYN-ACK を送信
   ↓
3. SYN データを受け入れる
   ├─ TCB (Transmission Control Block) を作成
   ├─ 状態：SYN-RECEIVED
   ├─ データを受信バッファに配置
   └─ アプリケーション層にデータが読み取り可能であることを通知
   ↓
4. SYN-ACK を送信
   ├─ SYN とデータを確認（ACK = ISN + 1 + DataLen）
   ├─ オプション：SYN-ACK に応答データを含める
   └─ オプション：Cookie を更新（新しい Cookie を返す）
   ↓
5. ACK を受信
   └─ 接続が ESTABLISHED 状態に移行

サーバー側：

# Cookie 生成の疑似コード
def generate_cookie(client_ip, server_secret, timestamp):
    data = client_ip + timestamp
    cookie = aes_encrypt(server_secret, data)
    return cookie

def validate_cookie(cookie, client_ip, server_secret, max_age):
    try:
        data = aes_decrypt(server_secret, cookie)
        stored_ip, timestamp = parse(data)
        if stored_ip != client_ip:
            return False
        if current_time() - timestamp > max_age:
            return False
        return True
    except:
        return False

セキュリティ強化措置​

リプレイ攻撃防止：

Cookie にタイムスタンプを含める
   → サーバーは期限切れの Cookie を拒否
   → Cookie の有効期間を制限（例：24 時間）

IP スプーフィング防止：

Cookie をクライアント IP にバインド
   → 異なる IP のクライアントは同じ Cookie を使用できない
   → モバイルネットワークシナリオでは IP ドリフトを考慮する必要がある

3.5. 状態機械の拡張 (State Machine Extensions)​

クライアントの状態機械​

CLOSED
   ↓ (アプリケーションが接続をリクエスト + Cookie あり)
SYN-SENT (SYN + Cookie + Data を送信)
   ↓ (SYN-ACK を受信、ACK がデータを含む)
ESTABLISHED
   ↓
   [Fast Open 成功！]

サーバーの状態機械​

LISTEN
   ↓ (SYN + 有効な Cookie + Data を受信)
SYN-RECEIVED (データを受け入れ、アプリケーションに通知)
   ↓ (SYN-ACK を送信、データを確認)
   ↓ (ACK を受信)
ESTABLISHED
   ↓
   [Fast Open 成功！]

4. セキュリティに関する考慮事項 (Security Considerations)​

TCP Fast Open はハンドシェイク中にデータを転送するメカニズムを導入しており、新たなセキュリティ上の課題をもたらします。本章ではこれらの脅威と対応する防護措置を詳しく分析します。

4.1. 攻撃の脅威概要 (Attack Threats Overview)​

主要な脅威カテゴリ​

  1. 増幅攻撃 (Amplification Attacks)
  2. リソース枯渇攻撃 (Resource Exhaustion Attacks)
  3. リプレイ攻撃 (Replay Attacks)
  4. プライバシー漏洩 (Privacy Leakage)

4.2. 増幅攻撃 (Amplification Attacks)​

攻撃の原理​

攻撃者はサーバーの応答を利用して攻撃トラフィックを増幅します。

攻撃シナリオ：
1. 攻撃者が被害者の IP アドレスを偽造
2. 小さな SYN パケット（+ TFO Cookie + リクエスト）を送信
3. サーバーが被害者に大きな応答を送信
4. 増幅倍率 = 応答サイズ / リクエストサイズ

防護措置​

1. SYN データサイズの制限

サーバーは MUST：

  • 受け入れる SYN データ長を制限する（推奨 ≤ MSS、約 1460 バイト）
  • 過大な SYN データパケットを拒否する

2. SYN-ACK 応答サイズの制限

サーバーは SHOULD：

  • 接続が完全に確立される（ACK を受信する）前に、応答データサイズを制限する
  • 推奨制限：≤ 4 × SYN データ長

3. Cookie 検証

厳格な Cookie 検証により IP スプーフィングを防止します。

  • Cookie は MUST クライアント IP アドレスにバインドされなければならない
  • 無効な Cookie のリクエストはデータ応答をトリガーしない

4.3. リソース枯渇攻撃 (Resource Exhaustion)​

防護措置​

1. SYN-RECEIVED 状態の制限

サーバーは MUST：

  • SYN-RECEIVED 状態の接続数を制限する
  • TFO 接続にはより厳格な制限を設ける

2. アプリケーション層の分離

サーバーは SHOULD：

  • ACK を受信するまで SYN データのアプリケーション層への配信を遅延させる
  • または SYN-RECEIVED 状態では軽量な処理のみを行う

3. SYN Cookies との統合

サーバーは MAY TCP SYN Cookies と組み合わせて使用できます。

  • SYN Cookies：ステートレスな SYN Flood 防護
  • TFO Cookies：ステートフルなパフォーマンス最適化

4.4. リプレイ攻撃 (Replay Attacks)​

防護措置​

1. 冪等性の要件

アプリケーション層は MUST：

  • TFO SYN では冪等な操作のみを送信する
  • 例：
    • ✓ 許可：GET リクエスト、読み取り専用操作
    • ✗ 禁止：POST、PUT、DELETE などの副作用のある操作

2. Cookie の時効性

  • Cookie が期限切れになると、古いリプレイ攻撃は無効になる
  • Cookie の有効期間を短くすることでリプレイウィンドウを縮小

4.5. プライバシーの考慮事項 (Privacy Considerations)​

1. Cookie と IP のバインド

Cookie は MUST IP アドレスにバインドされなければなりません。

  • IP が変更されると Cookie は無効になる
  • 新しい Cookie を再リクエストする必要がある

2. 限定的な Cookie ライフサイクル

  • 推奨有効期間：数時間から 1 日
  • Cookie を定期的にローテーション
  • ユーザーがブラウジングデータをクリアする際に Cookie をクリア

3. Cookie にユーザー情報を含めない

Cookie は MUST NOT：

  • ユーザー ID やセッション ID を含める
  • ユーザーを識別できる情報を含める
  • 異なるサービス間で共有される

4.6. セキュリティのベストプラクティス (Security Best Practices)​

サーバー側​

MUST 実装：

  • ✓ Cookie をクライアント IP にバインド
  • ✓ SYN データサイズを制限
  • ✓ ACK 前の SYN-ACK 応答サイズを制限
  • ✓ Cookie の有効期限メカニズム
  • ✓ レート制限

SHOULD 実装：

  • ✓ サーバーキーを定期的にローテーション
  • ✓ TFO 使用パターンを監視
  • ✓ SYN Cookies との統合
  • ✓ アプリケーション層のリクエスト重複排除

クライアント側​

MUST 実装：

  • ✓ 冪等な操作にのみ TFO を使用
  • ✓ Cookie の安全な保存
  • ✓ 標準 TCP へのフォールバック機能

5. IANA に関する考慮事項 (IANA Considerations)​

本章では TCP Fast Open の IANA 登録の要件と割り当て状況を説明します。

5.1. TCP オプション番号の割り当て (TCP Option Kind Assignment)​

TCP Fast Open は Cookie および関連情報を転送するために TCP オプションを使用します。RFC 6994「Shared Use of Experimental TCP Options」に基づき、TCP Fast Open には実験的オプション番号が割り当てられています。

オプション番号​

TCP Option Kind Number: 34

正式名称：TCP Fast Open Cookie
参照文書：RFC 7413
割り当て状態：Experimental（実験的）

オプション形式​

+-------------+-------------+-------------------+
|   Kind=34   |   Length    |   Cookie (オプション)|
+-------------+-------------+-------------------+

フィールド説明：

  • Kind: 8 ビット、固定値 34
  • Length: 8 ビット、値の範囲 2-18
    • Length=2：Cookie リクエスト（Cookie データなし）
    • Length=6-18：Cookie 応答または使用（4-16 バイト Cookie）
  • Cookie: 可変長、4-16 バイト

5.2. 実験的ステータスの説明 (Experimental Status)​

TCP Fast Open は Experimental（実験的） とマークされており、これは以下を意味します。

  1. 非標準トラック：IETF 標準トラック (Standards Track) にない
  2. 部署の推奨：実装者は実験的な性質を理解すべき
  3. 標準への進化：実装経験に基づいて標準に昇格する可能性がある

5.3. 登録情報の概要 (Registration Summary)​

項目：TCP Option
パラメーター：Kind
値：34
名称：TCP Fast Open Cookie
参照：RFC 7413
日付：2014-12
備考：Experimental

6. 参考文献 (References)​

6.1. 規範的参考文献 (Normative References)​

[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, August 2013.

6.2. 参考情報 (Informative References)​

[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.

[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.

[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.

[RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC 6013, January 2011.

[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, "TCP Extensions for High Performance", RFC 7323, September 2014.

7. 謝辞 (Acknowledgments)​

TCP Fast Open の開発と標準化は多くの個人と組織の貢献によって実現しました。

7.1. RFC 著者 (Authors)​

Yuchung Cheng — Google, Inc.
Jerry Chu — Google, Inc.
Sivasankar Radhakrishnan — Google, Inc.
Arvind Jain — Google, Inc.

これらの著者は Google 在籍中に TCP Fast Open メカニズムを設計、実装、テストし、RFC の執筆を主導しました。

7.2. 技術的貢献 (Technical Contributions)​

TFO プロトコル設計に貴重な意見を提供してくださった方々：

  • Nandita Dukkipati (Google) — パフォーマンス分析と輻輳制御
  • Neal Cardwell (Google) — TCP 実装の専門家
  • Lawrence Brakmo (Facebook) — 初期レビューとフィードバック
  • Eric Dumazet (Google) — Linux カーネル実装

7.3. IETF コミュニティ (IETF Community)​

TCP Maintenance and Minor Extensions (TCPM) ワーキンググループのメンバーに感謝します。

ワーキンググループ議長：

  • Wesley Eddy
  • Yoshifumi Nishida

7.4. レビュアー (Reviewers)​

RFC ドラフトの詳細なレビューを提供してくださった方々：

  • Joe Touch — 複数回の詳細なレビュー、多くの技術的改善提案
  • Alexander Zimmermann — プロトコルの詳細と実装の提案
  • Mark Allman — 輻輳制御とパフォーマンスの考慮事項
  • Fernando Gont — セキュリティと運用上の考慮事項

付録 A. TCP SYN Cookies との比較​

本付録では TCP Fast Open (TFO) と TCP SYN Cookies の 2 つのメカニズムを詳しく比較し、それぞれの異なる目標と適用シナリオを理解するのに役立てます。

A.1. 概要 (Overview)​

TFO と SYN Cookies はどちらも「Cookie」の概念を使用していますが、まったく異なる目的に使用されます。

TFO (TCP Fast Open):
目標：接続遅延を削減し、パフォーマンスを向上
メカニズム：事前に割り当てられた Cookie、SYN データを許可
状態：ステートフル（Cookie をキャッシュ）

SYN Cookies:
目標：SYN Flood 攻撃を防御し、サーバーを保護
メカニズム：ステートレスな応答、ISN に情報をエンコード
状態：ステートレス（SYN-RECEIVED 状態を保存しない）

A.2. 機能特性の比較 (Feature Comparison)​

特性TFOSYN Cookies説明
主な目標パフォーマンス最適化セキュリティ保護設計の意図が異なる
SYN データ転送✓ サポート✗ 非サポートTFO のコア機能
状態タイプステートフルステートレスSYN Cookies のステートレス性が鍵
接続遅延1 RTT 削減標準 3-wayTFO のパフォーマンス優位性
サーバーリソース通常消費極低消費SYN Cookies がリソースを節約
TCP オプション保持完全保持MSS のみSYN Cookies の制限
Cookie 有効期間時間〜日分TFO Cookie は永続化
攻撃防護中程度非常に強力SYN Cookies は防御専用設計

A.3. 共存と協力 (Coexistence and Cooperation)​

TFO と SYN Cookies は共存できます。

推奨設定：

通常時：
  ├─ TFO：有効（パフォーマンス最適化）
  └─ SYN Cookies：有効だが非アクティブ（バックアップ）

軽度の攻撃：
  ├─ TFO：継続動作（レート制限あり）
  └─ SYN Cookies：一部の接続で有効化

重度の攻撃：
  ├─ TFO：無効化または厳格に制限
  └─ SYN Cookies：完全に有効化（主要な防護）

攻撃終了後：
  ├─ SYN Cookies：段階的に退出
  └─ TFO：再有効化

A.4. 総括 (Summary)​

TFO と SYN Cookies は競合関係ではなく、補完関係にあります。

TFO：
   「速いものをさらに速く」— 通常の状況でパフォーマンスを最適化

SYN Cookies：
   「遅くても使える」— 攻撃時でも可用性を維持

理想的な展開：
   両方を同時に有効化し、ネットワーク状況に応じて動的に切り替え