プロンプトとコンテキスト
モバイルクライアントは頻繁にネットワークを切り替えて再接続するため、チームは QUIC 0-RTT を使用してハンドシェイクが完了する前にアプリケーションデータを送信したいと考えています。サービスには読み取り処理のほか、請求、注文作成、トークンローテーションが存在します。
単に 0-RTT が高速であると主張するのではなく、安全性の境界を説明してください。リプレイ、ロードバランシング、マルチリージョン展開、およびクライアントのフォールバックを網羅してください。
面接官がテストしていること
プロトコルの基礎知識
0-RTT データには完全なリプレイ保護がなく、認証済みの 1-RTT リクエストと同様に扱ってはならないことを理解しているか。
リクエストの分類
HTTP メソッドによって機械的にリクエストを許可するのではなく、副作用、冪等性、鮮度、認可状態によって分類できるか。
分散環境での防御
チケット、リプレイウィンドウ、共有状態、ロードバランシング、および拒否後のリトライセマンティクスについて議論できるか。
検証可能性
リプレイ攻撃テスト、メトリクス、マスクされたログ、および安全性を示す段階的ロールアウトを提案できるか。
尋ねるべき確認の質問
- どのエンドポイントが読み取り専用で、どのエンドポイントが請求や注文の状態を変更しますか？
- 0-RTT チケットの有効期間、スコープ、およびアイデンティティバインディングはどのようになっていますか？
- サービスはマルチリージョンまたはマルチバージョン構成ですか？また、ノード間でリプレイ状態を共有できますか？
- 0-RTT 拒否後、クライアントは 1-RTT で自動的にリトライしますか？
- リクエストにはワンタイム nonce、冪等性キー、またはビジネスリビジョンが含まれていますか？
- 監査やコンプライアンスにおいて、1 つのリクエストが 2 回実行されていないことを証明する必要がありますか？
30秒の回答フレームワーク
「私は 0-RTT をハンドシェイク前のデータとして扱い、副作用のない読み取りまたは明示的に冪等な読み取りのみを許可します。書き込みはデフォルトで 1-RTT を待ちます。早期書き込みが必要な場合は、短期間のチケット、nonce、共有リプレイ検出、および冪等性キーを付与します。拒否された後、クライアントは同じ request_id を使用して 1-RTT 経由で同じリクエストをリトライします。リプレイテストを実行し、エンドポイント単位でこれを有効化します。」
ステップバイステップの詳細解説
ステップ 1: リクエストタクソノミーの構築
読み取り専用、冪等な書き込み、非冪等な書き込み、およびセキュリティに敏感なアクションを分離します。読み取りは対象となる場合がありますが、注文作成、請求、リワード、トークンローテーションは 1-RTT を待つ必要があります。冪等な PUT であっても、シーケンスレベルの副作用レビューが必要です。
ステップ 2: チケットスコープの定義
チケットをサービス、プロトコルバージョン、クライアントアイデンティティスコープ、および有効期限にバインドします。ある環境で発行されたチケットは、意図的なポリシーなしにテナントやリージョンを越えて再利用されてはなりません。キーをローテーションし、拒否理由を記録します。
ステップ 3: リプレイ防御の設計
許可された 0-RTT リクエストに対して nonce または冪等性キーを要求し、短いウィンドウ内で重複を排除します。マルチノード展開では、リージョンの共有ストレージを使用するか、整合性ドメインにルーティングできます。リプレイ状態の処理がメインのハンドシェイクパスをブロックしてはなりません。
ステップ 4: 拒否とリトライの処理
サーバーは 0-RTT を拒否できます。クライアントはハンドシェイクを待ち、1-RTT 経由でリトライし、早期データとリトライを 2 つのビジネス操作として扱うことは決してありません。レスポンスは、ダウンストリームでの重複排除のために requestid、attempt、および replaysafe メタデータを公開します。
ステップ 5: ロードバランシングとキャッシュの保護
エッジは、リプレイセーフなリクエストのみを 0-RTT 対応のバックエンドに転送します。キャッシュキーは変動するチケットに依存してはならず、プライベートなレスポンスが共有キャッシュに入ってはなりません。リージョン切り替え時には、不整合なリプレイ状態を避けるために 1-RTT を優先します。
ステップ 6: 検証と段階的ロールアウト
同じ 0-RTT パケットを記録し、ノード、リージョン、チケット有効期限、およびバージョンアップグレードにわたってリプレイします。少量の読み取りから開始し、拡張する前に拒否、リプレイブロック、副作用アラート、およびハンドシェイクレイテンシを観察します。
質の高い模範回答
「私は 0-RTT を一律の高速化スイッチにはしません。サーバーはエンドポイントポリシーを維持します。副作用のない読み取りはオプトインでき、冪等な書き込みには繰り返しを安全にするビジネスキーと nonce が必要です。請求、注文作成、エンタイトルメント、およびトークンローテーションは 1-RTT を待ちます。
チケットはテナント、サービスバージョン、および有効期間をバインドし、キーローテーションにより古いチケットは迅速に無効化されます。許可されたリクエストには requestid と冪等性キーが付与されます。エッジノードとバックエンドノードはリプレイを検出するために短い TTL の共有セットをチェックし、共有状態を持たないリージョンは 0-RTT を拒否します。拒否後、クライアントはハンドシェイクを待って同じ requestid で 1-RTT 経由でリトライし、サービスは 1 つのビジネス効果のみを保持します。
リプレイパケット、並行リプレイ、ノード切り替え、チケット有効期限、および混在バージョンをテストします。メトリクスには、0-RTT 承認率、拒否数、リプレイブロック数、重複ビジネスアラート、チケット経過時間、および p95 TTFB（最初の 1 バイトを受信するまでの時間）が含まれます。ロールアウトは読み取りから低リスクの書き込みへと進めます。」
よくある間違い
- すべての GET を許可する → 読み取りが請求やロギングの副作用を引き起こす可能性がある → ビジネス効果を分類し、シーケンスをレビューする。
- 0-RTT を認証済みとして扱う → リプレイによって早期データが繰り返される可能性がある → 1-RTT を待つか、明示的なリプレイ防御を実施する。
- プロセスメモリ内でのみ重複排除する → ロードバランシングによってリプレイが別のノードに送信される → 短い TTL の状態を共有するか、ダウングレードする。
- 拒否後に新しいビジネスキーを生成する → リトライが新しい操作になってしまう → request_id と冪等性キーを再利用する。
- チケットを無期限に有効にしておく → 古い権限やキーのリスクが残る → チケットのスコープを限定し、TTL を短縮し、キーをローテーションする。
- 攻撃シナリオなしでレイテンシのみをテストする → リリース後に重複効果が発生する → 記録、リプレイを行い、ビジネス効果が 1 回であることをアサートする。
- キャッシュとチケットのセマンティクスを混同する → プライベートなレスポンスが共有されてしまう → キャッシュキー、認可、および早期データ状態を分離する。
フォローアップの質問と回答
フォローアップ 1: すべての冪等な操作は 0-RTT で安全ですか？
いいえ。個別に冪等な操作のシーケンスであっても非冪等な効果を持つ場合があり、権限、在庫、クォータ、および通知によって副作用が追加されます。最終的なビジネス結果を検証してください。
フォローアップ 2: サーバーはどのようにリプレイを検出できますか？
短い TTL の nonce または request_id のセット、チケット使用ウィンドウ、および必要に応じて共有状態を使用します。検出が利用できない場合は、0-RTT を拒否して 1-RTT を使用します。
フォローアップ 3: 拒否によってリクエストは失われますか？
アプリケーションプロトコルがフォールバックを定義します。クライアントはリクエストを保持し、ハンドシェイク後にリトライします。早期処理が既に行われていた場合でも、冪等性キーによって重複が防止されます。
フォローアップ 4: なぜマルチリージョンでは難易度が上がるのですか？
リプレイ状態、チケットキー、およびバージョンが異なる可能性があるためです。共有状態の維持コストが高すぎる場合は、チケットを特定のリージョンにバインドし、リージョン切り替え後は早期データを拒否します。
フォローアップ 5: 0-RTT を安全に無効化するにはどうすればよいですか？
新しいチケットの発行を停止し、古いチケットを期限切れにするか拒否し、拒否数とフォールバックの成功を監視します。クライアントでサイレント障害が発生しないように、1-RTT パスとアラートを維持します。
出典 1: RFC 9001
RFC 9001 では、0-RTT にはリプレイ保護が欠如しており、副作用を伴うデータが安全であると想定するのではなく、アプリケーションプロトコルが許容可能な使用法を定義する必要があると述べられています。
出典 2: RFC 9308
RFC 9308 では、リプレイによってサーバーが同じデータを複数回処理する可能性があることを説明し、早期データを永続的な効果のない操作、または真の冪等性を持つ操作に制限することを推奨しています。
出典 3: Algoroq networking interview guide
公開されているネットワーキングガイドでは、QUIC、0-RTT、低レイテンシ、およびリプレイに関する注意事項が 1 つの面接フォローアップの流れとして関連付けられています。