プロンプトとコンテキスト
エンコーダーまたはメディアプロデューサー向けのWHIP（WebRTC-HTTP Ingestion Protocol）エンドポイントが必要です。クライアントはHTTP POSTを使用してapplication/sdpオファーを送信し、サーバーはICEおよびDTLSをネゴシエートしてSDPアンサーを返します。API、セッションライフサイクル、認証、リソース保護、オブザーバビリティについて説明してください。単方向のメディア取り込みを想定し、録画とトランスコーディングは対象外とします。
面接官が評価するポイント
- HTTPシグナリングリソースとWebRTCメディアリソースが個別にモデル化されているか。
- 単一のPOSTが、認証、制限、タイムアウト、クリーンアップの具体的な順序につながっているか。
- 候補者がWHIPをメディアトランスポートとして扱うのではなく、HTTPS、ICE、DTLS-SRTP、ブラウザAPI間の境界を理解しているか。
- リトライ、重複作成、ハーフオープンセッション、悪意のあるSDPが考慮されているか。
明確化のための質問
- パブリッシャーは制御されたエンコーダーですか、それともオープンなユーザーですか？認証情報は有効期間が短く、単一ストリーム用として扱えますか？
- エンドポイントは単一リージョンですか、マルチリージョンですか？セッション状態はリージョン間を移動できますか？
- 低遅延が優先事項ですか、それとも録画の完全性と再生可能性を保証する必要がありますか？
- trickle ICEやその他のWHIP拡張機能はサポートされますか？また、そのネゴシエーションと認可は誰が管轄しますか？
30秒の回答
エンドポイントを認証ゲートウェイ、セッションコントロールプレーン、WebRTCメディアノードに分割します。ゲートウェイは、SDPオファーをセッションサービスに渡す前に、短期間有効な認証情報、リクエスト制限、テナントクォータを検証します。サービスは制限されたリソースを割り当て、ICE/DTLSを完了し、201 Created、SDPアンサー、セッションLocationを返します。不完全なネゴシエーションはすべてリソースを解放する必要があり、DELETEは冪等であり、制限はテナントおよび送信元ごとに適用されます。POSTの成功を可用性メトリクスとして使用するのではなく、HTTPシグナリング、ICE/DTLS状態、最初のメディアパケット遅延を個別に測定します。
ステップバイステップの解決策
- プロトコルの境界を設定する。 WHIPは1回のHTTPオファー/アンサー交換を実行し、その後にWebRTCがメディアを伝送します。W3Cはブラウザの制御を公開し、サーバーはICE、DTLS、メディア受信を引き続き処理します。
- コストの低いチェックを先に実行する。 ICEやメディアノードを割り当てる前に、HTTPS、認証、テナントステータス、
Content-Type: application/sdp、リクエストサイズ、チャネル認可、レートクォータを確認します。拒否によってコストの高いSDP解析や接続割り当てがトリガーされてはなりません。 - セッションリソースをモデル化する。
pending → connected → closing → closedを持つ、推測不能で列挙不可能なセッションURLを使用します。作成時は201 Created、Location、およびSDPアンサーを返します。エラーは内部トポロジーを公開することなく診断可能である必要があります。 - ハーフオープンの処理を制限する。 SDP解析、ICE/DTLS確立、最初のメディアパケットに対してそれぞれ個別の期限を設定します。RFC 9725はPOSTフラッディングについて警告しています。認証情報を持つ攻撃者が割り当てを強制し、ICE/DTLSのタイムアウトを待つ可能性があります。エッジレート制限、セッション同時実行クォータ、タイムアウト回収を強制します。
- リトライと削除を処理する。 ネットワークのリトライにより、同じオファーが複数回送信される可能性があります。認証情報をチャネルまたは冪等性キーにバインドします。同一性が証明できない場合は、同時実行制限内でのみ新しいセッションを作成します。
DELETE /sessionを冪等にし、繰り返しの呼び出しに対して同じ終端状態を返します。 - トランスポートと認証情報を保護する。 RFC 9725では、WebRTCセキュリティモデルを維持するためにHTTPSを要求しています。認証情報をクエリ文字列から除外し、ハッシュ化されたセッション識別子のみをログに記録します。メディアノードは、広くコピーされたチャネルキーではなく、セッションサービスからの短期間有効な認可を受け入れる必要があります。
- 拡張機能を明示的にネゴシエートする。 trickle ICEまたはサーバーイベントがサポートされている場合は、
Linkなどのメカニズムを通じて機能をアドバタイズします。クライアントはすべてのWHIPサーバーがそれをサポートしていると想定してはなりません。拡張機能に障害が発生した場合は、ベースの交換にフォールバックするか、明示的に終了します。 - 実際の準備完了境界をテストする。 テナントレベルのPOST受け入れ、SDP解析失敗、ICE成功、DTLSセットアップ時間、最初のメディア遅延、タイムアウト回収、DELETE遅延を追跡します。重複したPOST、サイズ超過のSDP、到達不能なICE、ノードの再起動、認証情報の取り消しを注入してテストします。
モデル回答
まずこれをコントロールプレーンのエンドポイントとして位置付けます。HTTP POSTがSDPオファーをセッションサービスに渡し、その後にWebRTCがメディアを伝送します。ゲートウェイは、SDPを解析する前にHTTPS、短期間有効な認証情報、チャネル権限、コンテンツタイプ、サイズ、テナントの同時実行数を検証します。すべての拒否はメディアリソースが割り当てられる前に行われます。リクエストが成功すると、列挙不可能なセッションが作成され、201 Created、Location、アンサーが返され、期限付きの保留状態に入ります。ICEまたはDTLSが完了しない場合、サービスは候補（candidates）とノードを回収し、ハーフオープンセッションが容量を枯渇させないようにします。DELETEは冪等であり、短期間有効な認証情報と冪等性キーによってリトライが制限されます。HTTP、ICE/DTLS、最初のメディアのメトリクスを分離し、POSTフラッド、悪意のあるSDP、再起動、認証情報の取り消しに対する負荷テストを実行して、安全性と回復性の両方を証明します。
よくある間違い
- WHIPをメディアチャネルとして扱う → ICE、DTLS、ノードの状態が設計から消えてしまう → コントロールプレーンとメディアプレーンを分離する。
- すべてのPOSTで完全なノードを割り当てる → 敵対的なリクエストによってハーフオープンな処理が蓄積される → コストの低いチェックと段階的なクォータを先に実施する。
- グローバルレート制限のみを使用する → 1つのテナントまたはチャネルが全員に影響を与える → テナント、認証情報、チャネル、送信元ごとに制限する。
- 生のSDPをログに記録する → アドレスやトポロジーが漏洩する可能性がある → ダイジェスト、エラークラス、関連付けIDを記録する。
- DELETEを非冪等にする → リトライによってクリーンアップの競合や不要な404ノイズが発生する → 終端状態と反復可能なレスポンスを定義する。
- あらゆる結果に対してHTTP 200を返す → クライアントが作成、拒否、リトライを区別できなくなる → セマンティックなステータスと安全なエラー本文を使用する。
フォローアップの質問と回答
攻撃者が有効な認証情報を持っており、POSTを送信し続けています。サービスをどのように保護しますか？
認証情報をテナント、チャネル、有効期限にバインドします。エッジでトークンバケットと同時実行の上限を適用し、コントロールプレーンで保留中のセッションと合計待機時間を制限します。しきい値を繰り返し超える認証情報を取り消し、監査証跡を保持します。
ICEは成功したがDTLSが成功しません。リトライしますか、それとも成功を報告しますか？
ICEの成功はメディアの準備完了を意味しません。DTLSと最初のメディア条件を通過するまでセッションを保留状態にしておきます。タイムアウト時にはセッションを閉じ、リトライ可能な障害クラスを返し、候補とノードを解放します。
クライアントが同じSDPオファーを2回送信しました。重複した取り込みを回避するにはどうすればよいですか？
短期間有効な冪等性キーを要求し、それを認証情報、チャネル、オファーのダイジェストにバインドします。重複が証明された場合は元のセッションを返します。同等性が証明できない場合は、同時実行クォータの範囲内でのみ新しいセッションを作成します。
障害発生時にWHIPセッションを別のリージョンに移動できますか？
確立されたICE/DTLSセッションを透過的に移動することは原則として不可能です。新しいエンドポイントが新しいセッションURLを発行し、クライアントが再度POSTを送信し、古いセッションはタイムアウトまたは明示的なDELETEによって解放される必要があります。複製された認証情報の状態が公開スコープを拡大してはなりません。