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

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
に最終更新