1. 出題とコンテキスト
あるHTTPSマルチテナントAPIでは、複数のドメイン間でHTTP/2コネクションを再利用しています。一部のリクエストで断続的に421が発生しており、チームはアプリケーションコントローラーでこれを503に書き換えようとしています。421のセマンティクスを判断し、SNIとHostの違いを説明した上で、ゲートウェイ、オリジン、クライアント、および可観測性の計画を設計してください。リクエストはCDN、リバースプロキシ、およびサービスメッシュを通過する可能性があるものとします。
2. 面接官が見ているポイント
- 421が、リクエストがターゲットURIに対して信頼できる応答を提供できない、または提供する意思がないオリジンに到達したことを意味することを理解しているか。
- コネクションの再利用、TLS SNI、リクエストのHost、スキーム、オーソリティを1つの診断チェーンとして結び付けられるか。
- プロキシが独自のルーティング判断から421を捏造すべきではなく、クライアントは新しいコネクションでのみリトライすべきであることを理解しているか。
- ステータスコードのみを変更するのではなく、421をアップストリームの障害、404、503、および証明書の設定エラーから切り離して扱えるか。
3. 回答前の明確化のための質問
- 421はオリジン、ゲートウェイ、CDN、またはアプリケーションのどこで生成されていますか？
- リクエストはHTTP/2またはHTTP/3を使用していますか？また、1つのコネクションで複数のオーソリティを伝送できますか？
- 最終ホップにおけるTLS SNI、HTTP Host、および選択されたバーチャルホストは何ですか？
- クライアントはターゲットドメインに対して新しいコネクションを開くことができますか？また、そのメソッドは冪等ですか、それともすでに副作用が発生していますか？
4. 30秒の回答フレームワーク
421は、コネクション証明書とターゲットオーソリティの互換性のない組み合わせなど、リクエストが誤ったコネクションまたはバーチャルホストに送信されたとオリジンが判断したことを意味します。レスポンスを変更する前にSNI、Host、スキーム、オーソリティ、コネクションプーリング、およびオリジンのルーティングを診断してください。503に書き換えてはなりません。オリジンは421を送信できますが、プロキシは独自のルーティング判断から生成するのではなく、それを転送する必要があります。クライアントは、メソッドの冪等性、リクエストボディの再送可能性、およびバックオフに従って、新しいコネクションでリトライできます。ログ内でコネクションID、SNI、オーソリティ、ルート、およびリトライ結果を関連付けます。
5. ステップごとの詳細な回答
ステップ1: 責任境界を定義する
RFC 9110は、421をターゲットURIが誤って向けられたように見えることによるオリジンの拒否として定義しています。原因としては、オリジンの設定の不一致、または現在のコネクションコンテキストに適合しないリクエストが考えられます。アプリケーションは、任意のアップストリームのタイムアウト、DNSエラー、または期限切れの証明書を421にマッピングしてはなりません。これらの状態には独自のセマンティクスが必要です。
ステップ2: コネクションコンテキストを再構築する
TLSハンドシェイク中、SNIによって証明書とバーチャルホストが選択されます。暗号化が確立された後、リクエストのHostまたはオーソリティがターゲットを選択します。HTTP/2は1つのコネクションで複数のリクエストを伝送できますが、再利用が安全なのは証明書、プロトコル、およびサーバー設定で許可されている場合のみです。SNI、Host、スキーム、オーソリティ、ALPN、コネクション開始時刻、および選択されたバックエンドを記録し、コネクションの所有者とリクエストの送信先を比較します。
TLS SNI: api-a.example
HTTP authority: api-b.example
ALPN: h2
selected virtual host: api-a.example
result: 421 from originステップ3: プロキシ、CDN、およびサービスメッシュを処理する
エッジプロキシは、オリジナルのオーソリティ、TLS終端の詳細、およびアップストリームのコネクション状態を保持しつつ、互換性のないアップストリームコネクションでのテナント間の再利用を防ぐ必要があります。オリジンの421を転送することはできますが、自身のルートが失敗したというだけで421を生成すべきではありません。プロキシの502、503、またはルーティングエラーの規約を使用してください。サービスメッシュのプールキーには、IPとポートのみでプーリングするのではなく、証明書とバーチャルホストの選択に影響を与えるフィールドを含める必要があります。
ステップ4: クライアントのリトライを設計する
仕様では、ターゲットオリジン用の新しいコネクションを含む別のコネクションでクライアントが421をリトライすることが許可されています。リトライする前に、メソッドの冪等性、リクエストボディの再送可能性、トークンの有効性、および部分的なレスポンスや副作用がすでに発生していないかを確認します。POSTまたはその他の副作用を伴うメソッドの場合は、リトライ前にIdempotency-Keyを使用するか、実行されなかったことを確認します。試行回数を制限して理由を記録します。固定ループで設定エラーを覆い隠してはなりません。
ステップ5: 観測、修正、およびリグレッションテスト
グローバルなカウントのみを監視するのではなく、SNI、オーソリティ、バーチャルホスト、プロトコルバージョン、およびエッジノードごとに421を分類します。マスキングされたコネクションID、ルーティング決定、証明書のフィンガープリント、オリジンのレスポンス、およびクライアントが新しいコネクションを開いたかどうかを保持します。修正後は3つのパスをテストします。有効な再利用で421が返されないこと、互換性のないコネクションで一貫して421が返されること、新しいコネクションでのリトライがターゲットサービスの最終レスポンスに到達することを確認します。
6. 高品質な回答の例
私は421を一過性の一般的な障害ではなく、コネクションコンテキストまたはオリジンオーソリティの不一致として扱います。まずTLS SNI、HTTPオーソリティ、証明書、ALPN、コネクションプール、バーチャルホストルーティングを関連付けて、リクエストが互換性のないコネクションを再利用したかどうかを確認します。オリジンは421を返すことができますが、プロキシは捏造するのではなく転送すべきです。クライアントはターゲットオリジンに対して新しいコネクションを開き、冪等性、ボディの再送可能性、Idempotency-Keyを確認した上でのみリトライできます。ドメイン、プロトコル、ノード、プールごとにコードを計測し、再利用と新規コネクションの両方のリグレッションテストで修正を証明します。
7. よくある間違い
- すべての421を503に書き換える → コネクションコンテキストの証拠が失われる → 421を保持し、ゲートウェイでSNIとオーソリティをログに記録する。
- Hostのみを確認しSNIを確認しない → 証明書とバーチャルホストの再利用を見落とす → TLSとHTTPの両方のターゲットを記録する。
- プロキシに421を捏造させる → ステータスコードの責任境界に違反する → オリジンの421を転送し、プロキシのルーティング障害には明確な5xxの規約を使用する。
- POSTを無条件でリトライする → 書き込みが重複する可能性がある → Idempotency-Keyを使用するか、制限付きリトライの前に実行されていないことを確認する。
- 1つのドメインと1つのコネクションのみをテストする → HTTP/2の再利用を見落とす → クロスドメインの再利用、互換性のない再利用、および新規コネクションのテストを含める。
8. フォローアップと回答
421は503とどのように異なりますか？
421は、リクエストと現在のコネクションまたはオリジンオーソリティの間の不一致を示しています。ターゲット固有の新しいコネクションにより回復する可能性があります。503は、キャパシティ、メンテナンス、または依存関係が原因で、サービスが一時的にリクエストを処理できないことを意味します。修正方法、リトライルール、およびアラートのディメンションが異なります。
クライアントは古いコネクションで421をリトライできますか？
不適切と判断されたコネクションを使い続けるべきではありません。ターゲットオリジン用に新しいコネクションを開き、バックオフ、ボディの再送、および認証状態を考慮しながら、TLSとプロトコルを再ネゴシエーションします。
HostとSNIが異なる場合、プロキシは421を返してもよいですか？
プロキシ自身の推論のみに基づいて返すべきではありません。プロキシはルーティングエラーの規約に従うか、オリジンが判断できるようにリクエストを転送する必要があります。オリジンの421を転送する場合は、診断のためにソース情報を保持してください。
プールの修正によってパフォーマンスが低下していないことをどのように証明しますか？
有効な再利用、オーソリティをキーとするプール、および拒否された互換性のない再利用を個別に測定します。421の発生率、ハンドシェイク数、テールレイテンシ、コネクション数、およびCPUを比較します。目標は、追加のハンドシェイクコストを許容範囲内に抑えながら、不適切な再利用を排除することです。