一般面接：Alt-Svc はどのようにして安全な HTTP/3 移行を実現すべきか？

プロンプトとスコープ

ある HTTPS オリジンが HTTP/3 を段階的に有効化したいと考えています。サーバーは別のエンドポイントで同等のサービスを提供できますが、一部のネットワークでは UDP がブロックされており、クライアントが古い代替サービスデータを保持する可能性があります。Alt-Svc について説明し、証明書チェック、キャッシング、フォールバック、無効化、およびオブザーバビリティを設計してください。

Alt-Svc は同じオリジンに対して同等のサービスをアドバタイズします。これはリダイレクトではなく、ユーザーに見える URL を変更しません。これはプロトコル移行をテストするものであり、すべてのクライアントが即座に HTTP/3 を使用するという前提ではありません。

面接官がテストしていること

Alt-Svc、HTTP リダイレクト、および DNS サービスバインディングを区別できるか。
代替エンドポイントのオリジン権限と TLS 証明書検証を説明できるか。
Alt-Svc の有効期間、clear の無効化、到達不能な UDP、およびフォールバックを処理できるか。
ロールアウト、ハンドシェイク成功率、プロトコルバージョン、およびセキュリティイベントを測定できるか。

明確化のための質問

代替エンドポイントを誰が管理しており、その証明書はどのホスト名をカバーしていますか？
クライアント、CDN、プロキシ、ファイアウォールは HTTP/3 および UDP/443 をサポートしていますか？
ポート間またはホスト間のアドバタイズが必要ですか？また、オリジンの境界はどこですか？
不正なアドバタイズはどのように失効され、クライアントキャッシュから削除されますか？
成功の指標はハンドシェイク率、Time to First Byte、テールレイテンシ、エラーのいずれですか？

30秒での回答

「Alt-Svc を使用すると、オリジンはクライアントが以降の接続で試行できる同等の代替エンドポイントをアドバタイズできます。これは 3xx リダイレクトではなく、URL も変更しません。HTTP/3 の場合、代替エンドポイントの TLS 証明書とオリジン権限を検証し、カナリアリリース中は短い ma から開始し、UDP が失敗した場合は HTTP/2 または HTTP/1.1 にフォールバックし、clear による失効パスを維持します。キャッシュの有効期間を延長する前に、クライアント、ネットワーク、プロトコルごとにハンドシェイクとテールレイテンシをセグメント化して分析します。」

ステップバイステップの設計

1. Alt-Svc の役割を説明する

RFC 7838 は、クライアントが同じオリジンの代替サービスを発見できるように Alt-Svc レスポンスヘッダーを定義しています。クライアントは、可能な場合にトランスポートエンドポイントを変更しながら、元の URL を使用し続けることができます。アプリケーションのオリジンおよび認可のセマンティクスをバイパスしてはなりません。

2. 権限と TLS を検証する

代替ホスト名やポートは、レスポンスヘッダーに現れるという理由だけで信頼されるわけではありません。クライアントは、RFC 7838 で記述されているオリジンおよび証明書のルールに基づいてサービスを検証します。証明書は接続された名前をカバーしている必要があり、運用者はテナント間のトラフィック混在を防ぐ必要があります。クロスオリジンのアドバタイズには、より高リスクなレビューが必要です。

3. 段階的にアドバタイズする

成功を測定しながら、短い ma（最大有効期間）を使用して、最初に少数のクライアントまたは地域コホートに Alt-Svc を送信します。HTTP/3 エンドポイントは h3 識別子を使用できます。古いクライアントはヘッダーを無視して既存のプロトコルを継続できます。1 回のアドバタイズは、クライアントがアップグレードすることを保証するものではありません。

http

HTTP/2 200 OK
Alt-Svc: h3=":443"; ma=300
Cache-Control: private, no-store

4. UDP の失敗とフォールバックを処理する

エンタープライズファイアウォール、モバイルネットワーク、または NAT が UDP をブロックする場合があります。接続の試行が失敗またはタイムアウトした後、クライアントは HTTP/2 または HTTP/1.1 に戻る必要があります。単に代替トランスポートを試行したという理由だけで、アプリケーションリクエストを再実行してはなりません。ネットワークのブロックがアプリケーションの障害と誤診されないように、プロトコルの試行とフォールバックの理由をログに記録します。

5. キャッシュの失効と無効化

証明書、ルーティング、またはセキュリティの問題が発生した場合は、Alt-Svc: clear を送信して古いサービスのアドバタイズを停止します。ma の期限切れによっても、クライアントは再評価を行います。カナリアリリース中は有効期間を短く保ち、安定した後にのみ延長します。CDN のみをクリアしても、クライアント側の代替サービス状態は削除されません。

6. HTTPS DNS レコードと連携する

RFC 9460 の SVCB/HTTPS レコードもサービスバインディングパラメータを公開できます。どちらのメカニズムも HTTP/3 の発見に役立ちますが、伝播、キャッシング、および運用の責任範囲が異なります。HTTP レスポンスが古いエンドポイントをアドバタイズしている間に DNS が新しいエンドポイントに移行しないように、優先順位、ロールバック、および競合の監視を定義します。

質の高い回答のモデル

「Alt-Svc はリダイレクトではなく、同じオリジンの代替サービス発見として扱います。まずエンドポイントの TLS 証明書、権限、およびテナント分離を検証し、次に短い ma を持つ h3 を少数のコホートに送信します。UDP または HTTP/3 のハンドシェイクが失敗した場合は、書き込みを再実行せずに HTTP/2/1.1 にフォールバックします。設定またはセキュリティの問題がある場合は、Alt-Svc: clear を送信して古いアドバタイズを停止します。ネットワーク、クライアント、プロトコルごとにハンドシェイク、フォールバック、およびテールレイテンシを測定します。HTTPS DNS レコードも使用されている場合は、競合の優先順位と単一のロールバック手順を定義します。」

よくある間違い

Alt-Svc を 301/308 として扱う → URL とキャッシュのセマンティクスが変更される → サービス発見として説明する。
証明書の検証をスキップする → トラフィックが信頼できないサービスに到達する可能性がある → オリジンおよび TLS のチェックを適用する。
カナリアリリース中に長い ma を使用する → 不正な設定が長期間残る → 短い値から始めて後で延長する。
UDP がブロックされたときにリクエストを失敗させる → ネットワーク状況によって回避可能な障害が発生する → HTTP/2 または HTTP/1.1 にフォールバックする。
CDN のみをクリアする → クライアントが古い代替サービスを保持し続ける → clear を送信し、クライアント側の有効期間が切れるのを待つ。

フォローアップの質問と回答

Alt-Svc はブラウザのアドレスバーの URL を変更しますか？

いいえ。アプリケーションが元の URL を維持している間、同じオリジンの代替サービスを記述します。それが HTTP リダイレクトとの決定的な違いです。

HTTP/3 が失敗した直後に書き込みを直接再試行しないのはなぜですか？

トランスポートの試行が失敗したからといって、アプリケーション操作がまったく到達しなかったことが証明されるわけではないためです。冪等性キーまたは明示的なリクエストセマンティクスを使用し、盲目的にリソースを再作成するのではなく、同じ操作コンテキスト内でフォールバックします。

ma=300 は何を意味しますか？

代替サービス情報の最大キャッシュ期間を 300 秒に設定します。これは必須の HTTP/3 接続期間ではなく、その期間中にクライアントが代替サービスを使用または試行することを保証するものでもありません。