一度Cookieを受け取り、次のTCP接続のSYNにデータを載せる流れの概念図

TCP Fast Open（TFO）は、TCPの初期接続中にアプリケーションデータを送れるよう設計された仕組みです。IETFのRFC 7413は、条件が合えば通常の3ウェイ・ハンドシェイク完了後に送るデータを前倒しし、最大一往復時間（RTT）を節約できると説明します。ただし同RFCはExperimentalで、標準化トラックの仕様ではありません。すべての接続で遅延が減る、またはどのサーバーも直ちにデータを処理するという保証ではありません。

通常のTCP接続と異なる点

通常のTCPでは、クライアントがSYNを送り、サーバーのSYN-ACKを受け、ACKを返して接続が成立してからアプリケーションデータを送ります。短い要求では接続開始に必要なRTTが待ち時間の大きな部分を占めることがあります。TFOでは有効なサーバーCookieを持つクライアントがデータとCookieをSYNに含めます。サーバーが受理すれば、ハンドシェイク完了前にアプリケーションへ渡し、応答を始められます。

これはTCP全体を置き換えたり、すべての往復をなくしたりする技術ではありません。初期交換で最初のアプリケーションデータを前に移す仕組みです。RFC 7413は条件が合う場合に最大一RTTを節約し得るとしています。実際の結果は新規接続か再利用か、要求サイズ、経路、サーバー対応、中間装置の動作に左右されます。その後は通常のTCP接続として続きます。

最初にCookieを取得し、次回以降に使う

TFOを行う前に、クライアントはCookie欄が空のFast Openオプションを付けたSYNでCookieを要求します。対応するサーバーはSYN-ACKでCookieを返せます。クライアントはこれを保存し、次の接続でデータとともにSYNへ載せます。サーバーがCookieを検証して受理すれば、SYNデータをアプリケーションへ渡し、ハンドシェイク完了前に応答を送る場合があります。

初めて接続するサーバーでは、Cookie取得に一往復が使われることがあり、その時点でRTTが短縮されるとは限りません。Cookieはサーバーが期限切れにできます。要求がパケットや経路の制約に合うことも必要です。SYNデータが確認されない、中間装置がオプションを破棄する場合、ACKで再送したり通常のハンドシェイクへ戻ったりすることがあります。RFCは互換性のない経路で失敗を繰り返さない処理も扱っています。

アプリケーションは初期データの重複に備える

接続成立前にSYNデータがアプリケーションへ届くため、まれな再送や重複SYNの状況で同じ初期データを複数回受け取る可能性があります。RFC 7413はTCPの意味が変わる点と再生の可能性を明記し、重複実行を許容できない処理にはTFOを使わないよう注意しています。

読み取り要求と、決済や注文を二度実行すると問題になる処理では影響が異なります。必要に応じて処理を冪等にする、または重複を検出する設計が求められます。早く送れる可能性だけを理由に、あらゆる要求を接続前に実行してよいとは言えません。

サーバー制御、中間装置、セキュリティ

RFC 7413はTFOを既定で有効にせず、アプリケーションがサービスのポートごとに明示して要求するよう定めています。サーバーはCookieを検証し、未完了のFast Open要求数を制限します。有効なCookie付きSYNでもサーバー資源を使うため、過剰な要求はCPUやメモリーの負荷につながります。上限に達すると、新しい接続を一時的に通常TCPへ戻せます。

ファイアウォール、NAT、ロードバランサーなどがSYNオプションやデータを破棄することがあります。その経路では効果が消えたり再送で遅くなったりします。パケットサイズと初期輻輳ウィンドウも送信量に影響します。導入前に実際のサービスと経路で互換性、負荷上限、フォールバックを確認してください。

専門家の視点：仕様と現在の対応状況を分ける

RFC 7413は2014年12月のIETF Experimental文書で、Cookie交換、初期データの受理、再生リスク、資源制限、通常TCPへの移行を定めています。LWNの2012年記事はCookieの流れとAPIを理解するための歴史的な実装解説です。そこで述べられる当時のLinux対応状況を、現在の全OSの状況として使いません。現在のカーネル、ライブラリ、サーバーの資料を調べ、実際の経路で測定してください。

TFOは、適切な小さな要求を再接続時に早く送り出す可能性のある任意の最適化です。要求の安全性、実装対応、ネットワーク互換性を合わせて検証する必要があります。

出典