プロンプトと適用範囲
共同編集ホワイトボードでは、カーソル、バッチ編集、ファイルチャンクが送受信されます。WebTransport と WebSocket を比較し、配信保証、順序保証、輻輳制御、ブラウザサポート、運用面がどのように選択を左右するかを説明してください。
WebSocket は成熟した双方向メッセージチャネルを提供します。WebTransport は HTTP/3 を使用し、信頼性のある単方向または双方向ストリームに加え、パケット損失を許容するデータグラムを公開します。この設問では、「HTTP/3 の方が高速である」と単に繰り返すのではなく、システムの制約に合わせてトランスポートのセマンティクスを適切に選定できるかを評価します。
面接官が評価するポイント
必ず届くべきデータと期限切れになってもよいデータの切り分けができているか、順序保証、バックプレッシャー、輻輳制御、接続終了の理解があるか、そして HTTP/3 サーバー、証明書、プロキシ、ブラウザサポート、フォールバック、可観測性についての現実的な評価ができているかを確認します。
30秒の回答フレームワーク
「まずデータを分類します。編集操作やファイルチャンクには、バックプレッシャーを備えた信頼性のある双方向ストリームを使用し、カーソル位置にはデータグラムを使用します。古い位置情報には価値がないためです。対象のブラウザ、ゲートウェイ、またはサーバーが WebTransport を安定してサポートしていない場合は、WebSocket から開始し、機能検出によるフォールバックを維持します。どちらの経路でも、認証、クォータ、ハートビート、再接続、メトリクスが必要です。エンドツーエンドの損失率、レイテンシ、再接続、運用コストのデータに基づいて判断します。」
ステップごとの詳細な回答
ステップ 1: メッセージごとの配信規約を定義する
編集操作には信頼性のある配信と順序保証が必要であり、通常は重複排除のための操作 ID を付与します。ファイルチャンクには信頼性のあるストリーム、チェックサム、再開可能なオフセットが必要です。カーソルやドラッグプレビューの状態は最新の値のみを保持すればよく、損失や順序の入れ替わりを許容できます。
ステップ 2: WebSocket の境界を理解する
WebSocket は、1 つの信頼性のある双方向チャネルに対するシンプルで成熟したメッセージモデルを持っています。メッセージタイプ、バックプレッシャー、ハートビート、再接続、ブロードキャスト、大きなメッセージのフレーミングは、依然としてアプリケーション側で定義します。すべてのペイロードが 1 つのチャネルを共有する場合、サイズの大きいメッセージによってスケジューリングが複雑になることがあります。
ステップ 3: WebTransport の機能を理解する
WebTransport は、信頼性のある単方向または双方向ストリームと、信頼性のないデータグラムを組み合わせたものです。ストリームは順序付けられたバイト列を転送し、データグラムは損失する可能性がある低レイテンシの更新をサポートします。実装では、データグラムが必ず届くと想定するのではなく、ストリームの準備状態、終了、エラーを適切に処理する必要があります。
ステップ 4: データグラムに有効期限と重複排除を組み込む
各データグラムにエンティティ ID、シーケンス番号、またはタイムスタンプを含めます。受信側は、パケット損失をビジネスロジック上の障害として扱うのではなく、古い状態を破棄します。ユーザーごとに最新のカーソルのみを保持し、アナリティクスや編集の確認応答は信頼性のあるストリーム経由で送信します。
ステップ 5: ストリームのバックプレッシャーとリカバリを処理する
書き込み準備状態を待機し、セッションごとのキューに上限を設けます。上限を超えた場合は、優先度の低い更新を一時停止するか、過度な負荷をかけるクライアントを隔離します。ファイルチャンクのチェックサムを検証し、オフセットを永続化します。再接続後は、ファイル全体を再送信するのではなく、最後に確認応答があったチャンクから再開します。
ステップ 6: デプロイと互換性を評価する
WebTransport には、互換性のある HTTP/3 サーバーと証明書の設定に加え、プロキシ、ファイアウォール、ロードバランサーの検証が必要です。ロールアウト前に、ブラウザサポート、接続障害、HTTP/3 のダウングレード、リージョン間ネットワークをテストします。同じビジネスセマンティクスを維持したまま、WebSocket または HTTP にフォールバックします。
ステップ 7: 認証とリソースの分離を設計する
接続確立時にセッションとオリジンを認証します。接続数、ストリーム数、データグラムレート、バイト数に対して、ユーザーごとおよびテナントごとの制限を適用します。クライアントが宣言したストリームの優先度は認可を意味しません。ファイル書き込みには依然として権限、チェックサム、監査ログが必要です。
ステップ 8: エンドツーエンドのメトリクスに基づいて決定する
メッセージタイプごとに、送信および到達時間、再接続、ストリームエラー、推定データグラム損失、キュー長、CPU、帯域幅を記録します。実ネットワーク、モバイルのハンドオーバー、プロキシ、同時接続の環境下で、両方のトランスポートとフォールバックを比較します。
トレードオフと境界
単一チャネル vs 複数のセマンティクス
1 つの信頼性のある WebSocket チャネルの方が保守は容易です。WebTransport は信頼性のあるストリームと低レイテンシのデータグラムを分離できますが、プロトコル、テスト、運用の複雑さが増します。そのコストをかけるのは、プロダクトが両方のセマンティクスを必要とする場合のみに限定します。
レイテンシ vs リカバリ性
データグラムは待機時間を短縮しますが、ビジネス側で損失や期限切れを許容する必要があります。重要な状態は、操作 ID、チェックポイント、リプレイ防止を備えた信頼性のあるストリームに配置します。
新プロトコルのメリット vs デプロイリスク
HTTP/3 の機能があっても、サポートされていないブラウザやネットワーク機器によって引き起こされる障害を排除できるわけではありません。対象範囲を拡大する前に、小規模なロールアウトで接続率とフォールバック率を検証します。
障害訓練とシステム進化
企業内ネットワークで HTTP/3 が利用できない場合
プロキシによるブロックやハンドシェイクの失敗をシミュレートします。WebSocket への迅速なフォールバック、重要な編集の重複や損失がないこと、アクションにつながる障害メトリクスが取得できることを確認します。
カーソル更新が滞留する場合
データグラムレートを制限し、低速なネットワークを再現します。編集操作の信頼性を維持しながら、古いカーソル情報が破棄されることを検証します。
ファイルストリームが中断された場合
中断後に再接続し、チャンクのチェックサム、オフセットのリカバリ、再認証を検証します。クライアントが任意のオフセットを不正に上書きできないようにする必要があります。
よくある間違いとフォローアップ
間違い 1: WebTransport が常に高速であると思い込む
対象ネットワークにおける接続成功率、ハンドシェイク時間、フォールバック率について問いかけます。
間違い 2: 重要な編集操作をデータグラムとして送信する
損失、順序の入れ替わり、重複がどのように処理されるかを問いかけます。回答として、操作 ID を持つ信頼性のあるストリームに編集操作を移すべきです。
間違い 3: ブラウザ API の話に終始する
HTTP/3 サーバー、ロードバランサー、証明書、プロキシ、可観測性がどのようにデプロイされるかを問いかけます。
間違い 4: バックプレッシャーとクォータを省略する
低速なクライアントがどのように隔離され、テナントごとのストリームやバイト数の制限がどのように適用されるかを問いかけます。
間違い 5: フォールバック用に別のビジネスプロトコルを作成する
WebSocket と WebTransport がどのように同一のメッセージ規約と冪等性セマンティクスを維持するかを問いかけます。
発展的なフォローアップと模範回答
なぜカーソルと編集のトラフィックを分離するのか？
カーソル情報は一時的なものでありすぐに古くなるため、レイテンシを低減するために損失を許容できます。編集操作は信頼性、順序性、リカバリ性が必要であるため、信頼性のあるストリームに配置する必要があります。
WebTransport が利用できない場合はどうするか？
機能をプローブし、認証、メッセージ ID、再接続、ビジネス確認応答を維持しながら、WebSocket または HTTP にフォールバックします。
その選択が適切であることをどのように証明するか？
実ネットワーク環境のコホートにおいて、レイテンシ、推定損失、再接続、キュー、CPU、帯域幅、フォールバックを比較し、重要な操作が失われたり重複したりしていないことを検証します。