設問と範囲
あなたは決済、パスワード変更、または注文作成APIを担当しています。エッジではTLS 1.3 0-RTTが有効化されており、ゲートウェイはEarly-Data: 1を含むリクエストを転送する可能性があります。425を返すタイミング、処理を続行するタイミング、およびハンドシェイク完了後にクライアントがどのようにリトライするかを説明してください。これはバックエンド、プラットフォーム、およびAPIインフラの面接に適しています。
RFC 8470は、425を「リプレイされる可能性のあるリクエストの処理リスクをサーバーが拒否すること」と定義しています。一般的な「サーバービジー」のリトライコードではありません。ゲートウェイがEarly-Dataシグナルを維持でき、サービスが読み取り専用操作と副作用を区別できることを前提とします。
面接官がテストしていること
- すべての4xxを通常のクライアント入力として扱うのではなく、0-RTTのレイテンシ上の利点とリプレイリスクを区別できているか。
- 待機、リトライ、冪等性に関するクライアント、ゲートウェイ、アプリケーションの責任範囲を追跡できるか。
- RFCの条件、非キャッシュ性、リトライタイミングをテスト可能なAPIポリシーに落とし込めるか。
不十分な回答は「425はToo Earlyを意味する」と暗記しているだけです。優れた回答は、副作用、Early-Dataシグナル、冪等性キー、および制限されたリトライウィンドウから判断を下し、誤った設定によって顧客に二重請求が発生する仕組みを説明します。
最初に確認すべき明確化のための質問
- リクエストに
Early-Data: 1が含まれているか、またはエッジがearly dataで届いたことを証明できるか？RFC 8470はそのシグナルなしに425レスポンスを作成しないよう推奨しています。 - その操作は外部への副作用を生成するか？注文の読み取りは続行できます。請求、パスワード変更、またはクーポン発行はハンドシェイクを待つか、厳密な冪等性レコードを使用する必要があります。
- ゲートウェイは自動的にリトライするか？その場合、ハンドシェイク後にリトライすること、およびゲートウェイとSDKがそれぞれ重複してリトライを実行しないことを確認してください。
- クライアントは冪等性キーとリトライ上限をサポートしているか？これらがない場合、その操作に対して0-RTTを無効にする方が、425を無限にリトライしてよい許可として扱うよりも安全です。
30秒の回答
「まずリクエストがEarly-Data: 1を伴うTLS early data経由で届いたことを確認し、次にその副作用を分類します。読み取り専用の処理は続行できます。決済やパスワード変更はゲートウェイで待機するか425を受信します。クライアントはハンドシェイクが完了した後にのみリトライし、サービスは冪等性キーとユニーク制約を使用して重複実行を防止します。ゲートウェイはシグナルを維持し、1つのリトライポリシーを管理し、425レート、リトライ成功率、重複副作用を監視します。チェーン全体でこれらの条件を証明できない場合は、書き込みエンドポイントに対して0-RTTを無効化します。」
ステップバイステップの解決策
1. リスクシグナルの特定
RFC 8470は、early dataを転送する際に中間者がEarly-Dataの意味を維持することを求めています。サービスは、リクエストがリプレイされる可能性がある場合にのみ425を検討すべきです。証拠なしに425を返すと、通常のネットワーク障害を誤解を招くセキュリティ上の拒否に変えてしまいます。
2. 副作用による分類
エンドポイントを、読み取り専用、安全に再試行可能、または再試行が安全ではないものに分類します。GET /orders/123は通常読み取り専用です。1回限りのクーポン発行、カードへの請求、またはパスワード変更は安全に再試行できません。安全ではないクラスは、ハンドシェイクの完了を待つか、副作用が発生する前に冪等性キーを永続化する必要があります。
3. 単一のリトライ責任者の割り当て
425の後、クライアントはTLSハンドシェイクを待ってからリクエストを再送信します。リトライでearly dataを使用してはなりません。ゲートウェイがそのリトライを担当することもできますが、契約に明記されている必要があります。そうでなければ、ゲートウェイとSDKの両方がリトライを実行する可能性があります。指数バックオフ、最大試行回数、および各リトライの可視化された理由を設定します。
4. 冪等性を第2の防御策にする
書き込みには冪等性キーを要求します。サービスはテナント、エンドポイント、キーによって一意のレコードを保存し、少なくとも処理中、成功、リトライ可能な失敗の各状態を持たせます。重複リクエストには元の結果または明示的な処理中レスポンスを返します。冪等性は425の代わりにはなりません。データベースのコミット後、レスポンスがクライアントに届く前に最初のリクエストがリプレイされる可能性があるためです。
5. ゲートウェイとインスタンスの一貫性を保つ
すべてのインスタンスが同じEarly-Dataポリシーを適用する必要があります。アップストリームがシグナルを理解しているかゲートウェイが確信を持てない場合、ハンドシェイクを待つか早期リクエストを拒否します。HTTPのみのサービスに書き込みを暗黙的に転送してはなりません。リクエストID、Early-Data状態、425の理由、ハッシュ化された冪等性キーをログに記録し、決済内容自体は絶対に記録しません。
6. 失敗パスのテスト
Early-Data: 1の有無によるリクエスト、ハンドシェイク後の最初のリトライ、ゲートウェイのリトライ、クライアントのタイムアウト後の再送信、および1つの冪等性キーに対して2つのインスタンスが競合するケースをテストします。危険な副作用が1回だけ発生すること、および425がキャッシュされないことを検証します。
より単純な代替案は、0-RTTを完全に無効化することです。セキュリティ境界は明確になりますが、ハンドシェイクのレイテンシが増加します。レイテンシ削減の恩恵がわずかである少数のエンドポイントでは、レイヤーをまたぐポリシーを維持するよりも無効化する方が安全です。
質の高い回答例
「425を一般的なスロットリングエラーとして使用することはありません。まずEarly-Data: 1を確認し、次にその操作に副作用があるかを検討します。注文の読み取りは続行できます。決済およびパスワード変更のエンドポイントはゲートウェイで待機するか425を返します。クライアントはハンドシェイク完了直後に、制限付きのSDKポリシーに従ってリトライします。サービス側でも冪等性キーを要求し、テナント＋キーのユニーク制約を適用し、処理中および最終結果を保存することで、レスポンス喪失による二重請求を防ぎます。ゲートウェイとインスタンスは単一のポリシーを共有し、425レート、リトライ成功率、重複実行を監視します。Early-Dataが伝播できない場合は、推測に頼るのではなく、書き込みに対する0-RTTを無効にします。」
よくある間違い
- 425を429の代替として使用する → トリガーとクライアントのアクションが異なります → early-dataのリプレイリスクが存在する場合にのみ425を使用してください。
- すべてのリクエストに対して425を返す → 読み取りがブロックされ、クライアントが無限にリトライする可能性があります → 副作用を分類し、リトライを制限してください。
- 再度0-RTTでリトライする → リプレイウィンドウが開いたままになります → 再送信前に完了したハンドシェイクを要求してください。
- 冪等性をアプリケーション内のみに実装する → ゲートウェイまたは別のインスタンスが先に実行される可能性があります → エッジ、サービス、永続化層全体で統一されたポリシーを適用してください。
- 決済ボディ全体をログに記録する → デバッグによって機密データが露出します → 識別子、理由、および秘匿化されたキーのハッシュをログに記録してください。
フォローアップの質問と回答
ゲートウェイがEarly-Dataヘッダーを削除した場合はどうなりますか？
機能上の欠陥として扱います。ゲートウェイはハンドシェイクを待つか、早期リクエストを拒否する必要があります。アプリケーションは通常のリクエストから0-RTTを推測できません。書き込みを有効にする前にシグナルの伝播を修正してください。
クライアントがタイムアウトし、425を確認する前に再送信した場合はどうなりますか？
2回目のリクエストが最初のリクエストの処理中または最終状態を読み取れるように、同じ冪等性キーを使用します。キーのない危険な書き込みの場合は、診断可能なエラーを返し、手動または補償ワークフローを使用します。請求が発生したかどうかを推測してはなりません。
リトライが頻繁に成功するものの、レイテンシSLOが悪化する場合はどうなりますか？
エンドポイントおよびユーザーエージェントごとに、425レート、p95の初回成功レイテンシ、重複副作用、およびビジネス上の成功率を比較します。書き込みの利点がレイテンシの悪化に見合わない場合は、安全な読み取りに対してのみ0-RTTを維持するか、そのクラスのエンドポイントに対して0-RTTを無効化します。