設問と範囲
モバイルクライアントは HTTPS には確実に到達できますが、音声、ゲーム、リアルタイムプローブなどは UDP に依存しています。クライアントがターゲット UDP ホストへの HTTP トンネルを確立できるプロキシを設計し、ライフサイクル、フォワーディング、認可、レート制限、DNS、フェイルオーバー、フォールバックについて網羅してください。
RFC 9298 は CONNECT-UDP とプロキシテンプレートを定義しています。RFC 9297 は、信頼性の低いデータと信頼性の高い制御情報のために、それぞれ HTTP Datagrams と Capsule Protocol を定義しています。優れた回答では、プロトコルセマンティクス、プロキシリソース、およびセキュリティポリシーを明確に分離します。TLS 単体では不正利用を防ぐことはできません。
面接官が評価するポイント
- CONNECT-UDP におけるトンネル確立、フォワーディング、切断の区別。
- フォールバックを含む、HTTP/3 Datagrams と Capsules の境界の説明。
- ターゲットの許可リスト、ポートポリシー、ユーザー認可、およびテナントクォータの設計。
- DNS、タイムアウト、リトライ、ハーフオープンセッション、およびフェイルオーバーの処理。
- 帯域幅、並行性、パケットロス、レイテンシ、不正利用、およびコストメトリクスの定義。
- プロキシが UDP に対して信頼性、順序保証、エンドツーエンドの暗号化セマンティクスを追加することはできないという理解。
明確化のための質問
- クライアントとプロキシの双方が HTTP/3 Datagrams をサポートしていますか、それとも HTTP/2 も動作する必要がありますか？
- ターゲットはエンタープライズネットワーク、リアルタイムメディア、オープンインターネットのいずれですか？リスクモデルが異なります。
- クライアントがホスト名を提供し、プロキシが DNS を解決しますか？プライバシーおよび有効期間の要件は何ですか？
- 1 つのテナントが使用できるトンネル数、バイト数、並行 UDP フロー数はどのくらいですか？リージョンルーティングは必要ですか？
- 最大アイドル期間、パケットサイズ、セッション時間はどのくらいですか？
30秒での回答
プロキシを認証済みテナントおよび明示的なターゲットセットに制限し、CONNECT-UDP を使用してセッションを確立します。Capsules は信頼性の高い制御を転送し、HTTP/3 Datagrams はサポートされている場合に UDP データを転送します。サポートされていない場合、プロキシは信頼性の高いカプセル化にフォールバックするかリクエストを拒否し、同等のレイテンシを保証するとは主張しません。データプレーンではテナントトークンバケット、並行性制限、アイドルタイムアウトを適用し、制御されたリゾルバが DNS 結果をセッションにバインドします。フェイルオーバーでは再生可能な状態のみを再構築します。p99 レイテンシ、パケットロス、セットアップ成功率、リソース使用量、拒否率、不正利用アラートを検証します。
ステップごとの設計
1. セッションとステートマシン
クライアントはターゲットホストとポートに対して CONNECT-UDP を送信します。プロキシはアイデンティティ、ポリシー、クォータを認証し、ターゲットを解決してセッションを作成します。ステートには authorization pending（認可保留中）、connected（接続中）、draining（ドレイン中）、closed（切断）を含める必要があり、ハーフオープンセッションが無期限にリソースを保持しないよう、それぞれにタイムアウトと理由コードを設定します。
CONNECT / .well-known/masque/udp/example.test/443 HTTP/3
Host: proxy.example実装は RFC 9298 のリクエストテンプレートとエンコーディングルールに従う必要があります。上記のスニペットは意図のみを示しています。
2. コントロールプレーンとデータプレーンの分離
Capsule Protocol は、信頼性の高いセッション制御、エラー、切断通知に適しています。HTTP/3 Datagrams は、再送を必要としない UDP データに適しています。各 Datagram を対応する UDP ソケットにマッピングし、パケットサイズ、キューの深さ、バーストを制限します。パスに Datagram サポートがない場合は、レイテンシと CPU コストを隠蔽するのではなく、明示的に信頼性の高いカプセル化を選択するか、サポートされていないことを返します。
3. 認可とターゲットポリシー
ホスト名、IP レンジ、ポート、目的に応じた許可リストを適用する前に、短期間有効なクレデンシャル、テナント状態、デバイスバインディングを検証します。ループバック、プライベート、メタデータ、高リスクな宛先をブロックします。制御されたリゾルバで DNS を解決し、解決バージョンと TTL を記録して、再解決によってテナント境界を暗黙的に越えることを防ぎます。
4. 制限、クォータ、コスト
テナントごとにトンネル数、1 秒あたりのパケット数、バイトレート、セッション時間、アイドル時間を制限します。入力と出力の両方でトークンバケットを使用し、ノード全体の安全閾値を設けます。プロキシの CPU、カーネルソケット、キュー、出力帯域幅、セッションごとのコストを追跡します。HTTP リクエスト数のみを制限しても、長時間持続する UDP フローは抑制できません。
5. 障害とフォールバック
セットアップ失敗、到達不能なターゲット、DNS タイムアウト、過負荷に対して個別の理由を記録します。新規セッションは正常なノードでリトライできます。すでに送信された UDP データは一般にリプレイするのが安全ではないため、フェイルオーバーは制御状態を復元するか、上位プロトコルに新しいセッションを確立させる必要があります。Datagrams がサポートされていない場合は、信頼性の高いカプセル化または明示的なエラーを選択し、それぞれのパスを個別に測定します。
6. オブザーバビリティとセキュリティ運用
セッションごとに、テナント、プロキシノード、ポリシーバージョン、セットアップおよび切断理由、バイト数、パケット数、推定ロス、p50/p95/p99 レイテンシ、スロットリングイベントを記録します。完全なクレデンシャルや機密性の高いペイロードは絶対にログ出力しないでください。ポートスキャン、ターゲット集中、増幅攻撃バースト、テナント間でのリソース競合を検知し、テナント、ターゲット、またはリージョン単位で迅速に失効できるようにします。
7. ロールアウトと受け入れ基準
特定のリージョンや許可リストに登録されたターゲットを対象にカナリアリリースを実施し、ダイレクトパス、Datagram パス、フォールバックパスを比較します。ロス、順序の入れ替わり、プロキシの再起動、DNS の変更、ハーフオープンセッション、過剰なトラフィックに対してストレステストを行います。リリースゲートには、セットアップ成功率、リアルタイム p99、パケットロス、セッションあたりのリソース、誤拒否率、不正利用アラートのレイテンシを含める必要があります。セキュリティまたはリソースの閾値を超えた場合は、ポリシーを厳格化するか、そのパスを無効化します。
優れた回答例
明示的なターゲットセットに限定された認証済みプロキシを構築します。CONNECT-UDP の後、クレデンシャル、ターゲット、クォータを検証し、制御されたリゾルバを通じて DNS を解決してセッションを作成します。Capsules は制御を転送し、HTTP/3 Datagrams は利用可能な場合にリプレイ不可能な UDP データを転送します。各セッションには、パケットサイズ、キュー、レート、アイドル時間、有効期間の制限が設けられます。
送信ポリシーはプライベート、ループバック、メタデータ、高リスクポートをブロックし、トークンバケットが双方向を保護します。新規セッションはフェイルオーバー可能ですが、送信済みの UDP データは自動的にリプレイされません。セットアップ成功率、p99 レイテンシ、ロス、リソース、コスト、スキャン、増幅攻撃を監視します。カナリアテストで Datagram、フォールバック、ダイレクトの各パスを比較し、セキュリティおよびリソースのゲートによって機能を無効化できるようにします。
よくある間違い
- トンネルセマンティクスを考慮せずに「HTTPS 内に UDP を配置する」と述べる → CONNECT-UDP、Capsules、Datagrams を分離してください。
- プロキシを信頼性のあるトランスポートとして扱う → 信頼性と順序保証は上位レイヤーの責務です。
- 任意の宛先を許可する → ホストとポートの許可リストを使用し、特別なレンジをブロックしてください。
- HTTP リクエストのみを制限する → トンネル数、パケット数、バイト数、有効期間、アイドル時間も制限してください。
- 障害後にすべての UDP データをリプレイする → リプレイ可能な制御状態のみを復元し、上位レイヤーに再接続させてください。
- 平均レイテンシのみを測定する → p99、ロス、拒否率、リソース、不正利用のメトリクスを含めてください。
追加の質問と回答
HTTP/2 が HTTP/3 Datagrams を転送できない場合はどうしますか？
ワークロードに応じて、信頼性の高いカプセル化、ポーリングスタイルのトランスポート、または明示的な拒否を選択します。レイテンシ、CPU、帯域幅を個別に測定し、信頼性の低い Datagrams と同等であると主張しないでください。
SSRF をどのように防ぎますか？
DNS 解決後かつ接続前に解決された IP をチェックし、ループバック、リンクローカル、プライベート、メタデータ、ポリシー対象外のレンジをブロックし、DNS リバインディングを処理します。ポリシーバージョンをセッションにバインドし、失効可能にします。
損失した UDP パケットは誰がリトライしますか？
プロキシはトランスポートの観測結果を報告しますが、アプリケーションパケットをリプレイすることはありません。冪等性とシーケンスのセマンティクスを持つ上位プロトコルがリトライを決定します。リアルタイムメディアの場合は、代わりにデータをドロップまたは修復することがあります。
プロキシの再起動時にセッションをどのように回復しますか？
再認証と新しいセッションの作成を推奨します。制御状態を永続化する必要がある場合は、リプレイ不可能なデータを含めずに、短期間有効で検証可能な状態のみを復元し、古いソケットは直ちにドレインします。
制限が誤拒否を引き起こしていないことをどのように示しますか？
テナント、リージョン、ターゲット、クライアントバージョンごとに拒否率と成功率を比較します。エラー拒否バジェットを設定し、バースト、長時間セッション、ノード障害を再現してクォータの挙動を検証します。