プロンプトとコンテキスト
この質問は、トランスポートレベルのレイテンシ最適化を明確なビジネスセキュリティ境界へと変換できるかをテストします。TLS 1.3 early data は接続が完全に確立される前に送信できるため、RFC 8470 はリプレイリスクを明示的に指摘しています。したがって、リクエストの安全性は HTTP メソッド名のみから判断することはできません。リクエストクラス、状態遷移、冪等性、キャッシュとプロキシ、クライアントの再試行、監視、およびフォールバックについて説明してください。
面接官が評価している点
- 無害な繰り返しの読み取りと、繰り返される副作用を区別できているか。
- early data を明示的な安全なセットに制限し、不確実なリクエストに説明可能な拒否パスを提供しているか。
- 425、冪等性キー、重複排除、および再試行バックオフが連携して機能しているか。
- プロキシチェーン、ログ、メトリクス、ロールバック、および段階的ロールアウト制御を説明できるか。
最初に確認すべき明確化のための質問
どのリクエストが early data を運ぶ可能性があるか、TLS がどこで終端されるか、エッジの後続にプロキシやメッセージの再試行が存在するかを確認します。残高、在庫、注文、権限、または通知を変更する操作はどれですか？ビジネスにはすでに冪等性キー、リクエスト状態テーブル、一意性制約がありますか？クライアント、SDK、ゲートウェイは 425 を理解できますか？誰が、何回、どのような指数バックオフとジッターで再試行しますか？重複排除ストレージが利用できない場合、サービスは拒否、フルハンドシェイクへのフォールバック、または読み取り専用トラフィックの継続のいずれを行うべきですか？
30秒の回答フレームワーク
副作用を伴うリクエストや冪等性を証明できないリクエストは、デフォルトで early data から除外します。エッジは early data を検出し、保護されたシグナルをアプリケーションに渡します。安全な読み取りは継続できますが、注文、請求、権限変更は 425 を返すかフルハンドシェイクを要求します。真に低レイテンシを必要とする書き込みの場合、クライアントは冪等性キーを提供し、サーバーは一意性制約と短期間の結果状態を使用して「処理中（processing）」および「完了（completed）」を永続化します。クライアントは、明示的に再試行可能なレスポンスのみを有界な指数バックオフとジッターで再試行します。段階的にロールアウトし、重複実行、425、再試行ボリューム、およびビジネス上の異常を監視します。
ステップバイステップの詳細解説
1. early data の信頼境界を定義する
TLS 終端レイヤーで early data を検出し、保護された内部シグナルを介して渡します。パブリッククライアントが「安全なリクエスト」マーカーを偽造できてはなりません。プロキシ、キャッシュ、サービス間呼び出しがリクエストをコピーまたは遅延させることができるかどうかを定義します。シグナルの欠落や不確実なパスは、デフォルトで高リスクとして扱います。
2. ビジネスの副作用によって分類する
繰り返し実行してもリソースが変更されないステートレスな読み取りは、受け入れやすくなります。注文の作成、請求、在庫の減算、権限の変更、メッセージ送信、外部システムの呼び出しはリプレイの影響を受けやすいです。PUT や DELETE であっても実際の実装に対してチェックする必要があります。POST が自動的に非冪等であるとは限りません。ビジネス状態モデルと一意性制約が保証を決定します。
3. 425 とフルハンドシェイクへのフォールバックを設計する
early data を許可しないパスに対して 425 Too Early を返し、再送信前にクライアントがフルハンドシェイクを完了する方法を文書化します。ゲートウェイは 425 を無制限に再試行してはなりません。エッジとクライアントの双方が再試行して負荷が増幅しないよう、元のリクエストがアプリケーションに到達した可能性があるかどうかを記録します。クライアントの対応可否が不明な場合、暗黙的な実行よりも明示的な失敗の方が安全です。
4. 冪等性キーとステートマシンを使用する
冪等性キーをテナント、操作タイプ、およびリクエストパラメータのダイジェストにバインドします。一意性制約の背後で処理中、成功、失敗の状態を永続化します。並行する 1 つのリクエストがキーを所有し、他のリクエストは状態を読み取るか有界な時間待機しますが、パラメータの不一致は拒否されます。古い結果がビジネスの再試行ウィンドウを超えて残らないように保持期間を設定します。データベースのコミットや外部の副作用には、依然としてアウトボックス、ステータスポーリング、または補償設計が必要です。
5. 再試行とプロキシの動作を制約する
クライアントは、レスポンスが再試行可能であり、操作が冪等性のルールを満たしている場合にのみ、打ち切り付き指数バックオフ、ジッター、および総試行回数の制限を使用して再試行します。ゲートウェイ、SDK、キューコンシューマが無制限の再試行を積み重ねてはなりません。425、接続障害、レート制限、ビジネス拒否を区別します。価値の高い書き込みの場合、元の副作用を再送信する代わりに、クライアントに冪等性キーのステータスを照会させます。
6. 監視、ロールアウト、およびフォールバック
読み取りパスと少数のテナントセットから開始し、ルート、クライアント、リージョンごとのスイッチを維持します。early-data ボリューム、425 レート、重複キーの競合、重複請求や在庫の異常、再試行の増幅、フルハンドシェイクのレイテンシ、重複排除ストアのエラーを追跡します。しきい値を超えた場合は、ロールアウトを停止するか、early data を無効化するか、フルハンドシェイクを強制し、リクエストが実際に実行されたかどうかを判断するための監査サンプルを保持します。
質の高い模範回答
私は early data を通常の HTTPS リクエストとしてではなく、潜在的にリプレイ可能な入力として扱います。エッジがシグナルを検出して保護します。読み取りはリスクが許容できる場合にのみ継続され、注文、請求、在庫、権限、および外部通知は 425 を返してフルハンドシェイクを要求します。低レイテンシが必要な書き込みの場合、クライアントはテナント、操作、およびパラメータダイジェストにバインドされた冪等性キーを送信する必要があります。サーバーは一意性制約の背後で処理中、成功、失敗の状態を永続化し、パラメータの競合を拒否します。425、接続障害、レート制限に対して再試行条件を個別に定義します。クライアントは有界な指数バックオフとジッターを使用し、ゲートウェイは無制限の自動再試行を回避します。段階的にロールアウトし、425、重複キー、重複したビジネス実行、再試行の増幅、フォールバックレイテンシ、重複排除の失敗を監視します。異常発生時には early data を無効化するかフルハンドシェイクを強制し、監査ログを照合します。
よくある間違い
- TLS で暗号化されているため early data はリプレイされないと思い込む。
- 実際のビジネスの副作用ではなく、メソッド名のみに基づいて分類する。
- ゲートウェイとクライアントの双方が制限なく 425 を再試行できるようにする。
- 冪等性キーからテナントやパラメータのバインディングを省略する。
- 成功のみをキャッシュし、処理中状態や再試行可能な失敗のセマンティクスを無視する。
- 重複請求、在庫の異常、再試行の増幅を考慮せずにレイテンシの改善効果だけを測定する。
- ルートレベルの無効化、フルハンドシェイクへのフォールバック、および監査の照合を省略する。
フォローアップの質問と回答
425 と 429 の違いは何ですか？
425 は、現在の early-data 条件下ではリクエストの到着が早すぎたため、フルハンドシェイク後に再送信する必要があることを意味します。429 は、リクエストがレート制限またはクォータ制限に達したことを意味します。再試行条件、待機ヒント、監視上の意味が異なるため、同一の自動再試行ブランチを共有すべきではありません。
クライアントが 425 をサポートしていない場合はどうなりますか？
重要な書き込みパスの場合、クライアントの解釈に依存するのではなく、ゲートウェイで early data を拒否するかフルハンドシェイクを強制します。アップグレードされた SDK で互換性の動作を提供します。読み取り専用パスは継続できますが、クライアントの機能とリスク境界を記録します。
冪等性ストアがダウンしている場合、請求処理は継続すべきですか？
重複排除が証明できない場合は、リスクの高い副作用を実行しないでください。再試行可能なエラーを返すか、フルハンドシェイクにフォールバックして再確認するか、リクエストを照会可能な保留状態に変換します。許容損失額と復旧パスに基づいて選択します。
サービスが 425 を返した後に early-data リクエストが実行されることはありますか？
リクエストがすでにアプリケーションに到達しているという競合状態が存在するため、アプリケーションは副作用を実行する前に early-data シグナルと冪等性状態を再確認する必要があります。425 はすでに開始された操作を取り消すものではありません。ステートマシンと一意性制約を介して副作用をコミットし、監査ログを使用して実行を確認します。