プロンプトとコンテキスト
単一の WebTransport セッションで、ライブプレビュー、制御メッセージ、および大容量ファイルを送信する必要があります。プレビューには低遅延が必要であり、制御メッセージは迅速に到着する必要があり、ファイルは帯域幅を譲る場合があります。WebTransportSendGroup、sendOrder、および getStats() を使用して、優先順位の境界、輻輳、再接続、非対応ブラウザ、およびエラーを含む送信ポリシーを設計してください。
MDN では、send group を、相対的な送信優先順位が sendOrder によって決定されるストリームとデータグラムのセットとして説明しています。異なるグループ間での帯域幅の割り当ては実装定義です。このインターフェースは実験的（experimental）なままです。この記事は公開資料をまとめたものであり、特定の企業固有の面接の質問であることを主張するものではありません。
面接官がテストしていること
面接官は、グループ内の相対的な順序付けとグループ間の公平性を区別できるか、ビジネス上の優先順位を観察可能なキューにマッピングできるか、信頼性のないデータグラムと信頼性のある順序保証付きストリームの違いを説明できるかを確認したいと考えています。優れた回答では、createSendGroup()、ストリーム作成時の sendGroup の受け渡し、sendOrder、グループレベルの getStats()、輻輳制御、および機能検出に言及します。不十分な回答では、単に「重要なメッセージに重み付けをする」とだけ述べるにとどまります。
最初に明確にすべき質問
- どのデータを破棄してよく、どのデータを信頼性があり、順序付けされ、永続的である必要がありますか？
- レイテンシ目標、ファイルスループット目標、およびキューの最大保持期間はどれくらいですか？
- 優先順位はセッション全体で固定ですか、それともユーザーのアクションによって変更されますか？
- 対象のブラウザは send group をサポートしていますか、またフォールバックは同じビジネスセマンティクスを表現できますか？
30秒の回答
「信頼性のある制御メッセージ、損失を許容するリアルタイムプレビュー、およびバックグラウンドのファイル転送を明示的なメンバーに分離します。相対的な順序付けが必要なメンバーは同じ send group を共有し、sendOrder によって制御とプレビューをファイルよりも優先させます。これはグループ間の帯域幅保証ではありません。送信側はキューとアイテムサイズを制限し、getStats() を介してキューイングと完了を観察し、古いプレビューを破棄し、輻輳時にはファイルを一時停止します。非対応の場合は、制御メッセージの信頼性を維持しながら、別の接続またはアプリケーションスケジューラにフォールバックします。」
ステップバイステップの解決策
まず信頼性の境界から始めます。制御、認可、および最終確認には信頼性のあるストリームを使用します。データグラムは使い捨てのライブプレビューを運ぶことができます。信頼性のあるストリームは低い優先順位でファイルを運ぶことができます。send group は、メンバー間の相対的な送信順序を解決します。異なるグループを予測可能な重み付けキューに変換したり、ビジネスのリトライを実行したりするものではありません。
グループを作成した後、送信ストリームまたは書き込み可能なデータグラムストリームをそれに関連付け、メンバーに sendOrder を設定します。大きい値と小さい値のどちらが優先されるかについて実装間で不一致が生じないよう、プロトコル内の数値関係を文書化してください。同じグループ内で厳密な順序付けに参加しているメンバーのみが比較されます。未設定の順序は実装定義です。
const group = transport.createSendGroup();
const control = await transport.createUnidirectionalStream({
sendGroup: group,
sendOrder: 30,
});
const preview = transport.datagrams.createWritable({
sendGroup: group,
sendOrder: 20,
});
const archive = await transport.createUnidirectionalStream({
sendGroup: group,
sendOrder: 1,
});アプリケーション側には依然としてバジェット（上限設定）が必要です。プレビューデータグラムのサイズと保持期間を制限し、各オブジェクトの最新状態を合体（coalesce）させます。ファイルチャンクにはキャンセル、リトライ、およびチェックポイントの記録が必要です。キューが制限に近づいたら、まず古いプレビューを破棄し、ファイルを一時停止しますが、制御メッセージは保持します。重要なメッセージには確認応答（ACK）とべき等性キーを使用します。高い送信順序は到達を意味するものではありません。
輻輳制御はトランスポートの選好であり、厳密なビジネス SLA ではありません。congestionControl は低レイテンシまたは高スループットの選好を表現できますが、結果は実装とネットワークの状態に依存します。接続を作成するときに選好を選択し、アプリケーションのメトリクスを使用してプレビュー頻度を減らすか、バックグラウンド処理を一時停止します。単一のオプションからレイテンシ保証を主張しないでください。
グループの getStats() とメンバーレベルのメトリクスを使用して、キューイング、送信、ドロップ、リトライ、および完了レイテンシを観察します。グループ、メッセージタイプ、ネットワーク、およびセッションバージョンのディメンションを記録し、「未送信」、「データグラム損失」、「受信側遅延」を区別します。再接続時には、古いストリームオブジェクトを再利用するのではなく、新しいグループを作成し、信頼性のあるストリームの状態を復元し、信頼できるスナップショットから使い捨てプレビューを再構築します。
セッションを開く前に機能を検出します。send group が利用できない場合でも、コアとなる制御ストリームは機能し続ける必要があります。別の信頼性のある接続またはアプリケーションキューを使用します。視覚的なプレビューを維持するために、ログイン、認可、または送信をブロックしないでください。実験的なインターフェースをリリースする前に、ブラウザコホート、ロールアウトスイッチ、およびキルパス（緊急停止手段）を提供してください。
優れた回答の例
制御メッセージ、ライブプレビュー、およびファイル転送を別々の送信メンバーに分割し、信頼性に応じてストリームまたはデータグラムを選択します。相対的な順序が必要なメンバーは1つの send group を共有します。制御には最も高い sendOrder を付与し、プレビューにはその次、ファイルには最も低い値を割り当てます。順序のないメンバーは厳密な比較の対象外となります。グループの順序は相対的であり、グループ間の公平性は実装定義であるため、帯域幅クォータとしては提示しません。
アプリケーションがバジェット、キャンセル、べき等性、および有効期限を管理します。輻輳時には、古いプレビューを合体または破棄し、ファイルを一時停止する一方で、制御メッセージは信頼性のある確認応答を維持します。congestionControl は選好を表現し、getStats() はキューイングと完了レイテンシを測定します。再接続ではグループを再構築し、スナップショットから復元します。非対応ブラウザは信頼性のある制御パスを維持し、プレビューを劣化させるか無効化します。グループおよびメッセージタイプごとにドロップ、レイテンシ、およびタスクの成功を監視します。
よくある間違い
- 兆候 →
sendOrderをグループ間の帯域幅の重みとして扱う。失敗する理由 → API はグループ内の相対的な送信順序を定義しているため。修正方法 → アプリケーション内でグループ間のスケジューリングを行い、結果を測定する。 - 兆候 → 信頼性のある確認応答を高優先順位で置き換える。失敗する理由 → 送信順序は到達を保証しないため。修正方法 → 重要なメッセージには信頼性のあるストリーム、確認応答、およびべき等性を使用する。
- 兆候 → 輻輳中もすべてのプレビューとファイルをキューに入れ続ける。失敗する理由 → レイテンシとメモリが無制限になるため。修正方法 → バジェットを設定し、最新状態を合体させ、バックグラウンド転送を一時停止する。
- 兆候 → 再接続後に古いストリームオブジェクトを再利用する。失敗する理由 → それらは期限切れのセッションに属しているため。修正方法 → グループを再構築し、信頼できる状態を復元して、再購読する。
- 兆候 → 実験的な API を唯一のチャネルにする。失敗する理由 → ブラウザの違いによってコアアクションがブロックされるため。修正方法 → 機能を検出し、段階的にロールアウトし、信頼性のあるフォールバックを維持する。
フォローアップの質問と回答
グループ内優先順位とグループ間優先順位の違いは何ですか？
1つの send group 内では、参加しているストリームまたはデータグラムが sendOrder によって比較されます。異なるグループ間は公平に扱われることが期待されますが、正確な分割は実装定義です。グループ間の重み付けを行うには、アプリケーション内でキューまたは個別の接続をスケジュールし、メトリクスで検証します。
プレビューを保護するために高い送信順序だけでは不十分なのはなぜですか？
優先順位はキューの順序を変更しますが、データグラムの非信頼性を変えたり、受信側の処理を保証したりするわけではありません。プレビューには依然として有効期限、合体、および破棄のルールが必要です。制御データには信頼性のあるトランスポート、確認応答、および永続性が必要です。
ファイルの一時停止が役立ったかどうかをどのように把握しますか？
ファイルキューの長さ、プレビューのレイテンシ、制御の完了レイテンシ、およびタスクの成功率を追跡します。プレビューが目標を達成している間に制御のレイテンシが改善された場合は継続します。ネットワークやビジネスの優先順位が変化したときは、無期限の飢餓（スターベーション）を避けるためにバジェット内でファイルを再開します。
send group がサポートされていない場合のフォールバックは何ですか？
まず、信頼性のある制御ストリームとコアナビゲーションを保護します。プレビューは別のデータパス、信頼性のあるストリームを経由させるか、プレビューなしにします。認可、送信、およびエラーのセマンティクスが損なわれないように、同じメッセージプロトコルとキャンセルルールを維持します。