要約

  • 0-RTTデータの受理が示すのはトランスポートの判断であり、業務効果が一度だけ確定したことではない。
  • 受け入れ証跡には、早期データ、リプレイ防止範囲、再試行経路、アプリケーションの確定結果を結び付ける必要がある。

サービスを開通するクライアントが接続を再開し、ハンドシェイク完了前にPOSTを送るとする。あるエッジは早期データを受け入れたが、応答が失われ、クライアントまたは中継装置が別のエッジへ再試行した。監視画面は低遅延と成功を示す。それでも、一つのサービスが作られたのか、二つなのかは分からない。

これは実在の障害を主張する話ではなく、規格が定める境界を示す仮定である。RFC 8446は、再開用情報を共有するクライアントとサーバーに0-RTTを認める一方、接続をまたぐリプレイ耐性を保証しないと明記する。同一接続内で同じレコードを二重処理できないことと、分散システム全体で同じ論理操作を一度しか受理しないことは別である。

全体で強いリプレイ防止を実現するには、既に受理した情報を共有するか、同等の一貫した仕組みが要る。これは可用性と運用コストを伴う。ある拠点がチケットを受理した事実だけでは、別の受理領域が同じ操作を拒否することまでは証明できない。

QUICでも責任は消えない。RFC 9001は、0-RTTで受け取ったアプリケーションデータが複数回処理され得ると警告し、許容範囲と対策をアプリケーションプロトコルに求める。後からハンドシェイクが完了しても、それ以前に始まった処理が自動的に一度限りになるわけではない。

HTTPには経路を保つ信号がある。RFC 8470のEarly-Data: 1は、前段で早期データとして送られた事実を中継先へ伝える。後段のハンドシェイク完了を待つだけでは、その要求は安全にならない。リプレイの恐れを受け入れないサーバーは425 Too Earlyを返し、再試行はハンドシェイク後に行われる。

メソッドの意味も重要だ。RFC 9110では、同一要求を複数回行った場合の意図された効果が一回と同じなら冪等である。POSTはキーを付けただけで冪等にはならない。安全な再試行を設計するなら、キーの範囲、保持期間、競合規則、全経路が参照する確定結果が実装されていなければならない。

0-RTT受理率は高速経路の利用を示す。TLSやQUICのログは接続状態を示す。HTTPステータスは一つの応答経路を示す。いずれも単独では、永続的な確定回数や、再試行が別のリプレイ防止領域に入ったかを証明しない。

必要な記録は、要求IDまたは冪等キー、メソッドと対象、早期データ判断、エッジとオリジン、リプレイ防止領域、Early-Dataの伝播、425と再試行、アプリケーション取引ID、最終確定回数と結果を結ぶ。秘密そのものは残さず、どの範囲が受理を支配したかを残す。

0-RTTを禁じる必要はない。読み取りや、リプレイを許容するよう設計された操作には価値がある。必要なのは、遅延の改善を実行保証と取り違えないことだ。バイト受理後に何が起きたかを証明できるのはアプリケーションである。

情報源