プロンプトとコンテキスト
アプリケーションは、履歴上のすべての更新よりも最新の状態が重要であるカーソル、ポーズ、ドラッグプレビューの高頻度な更新を送信します。順序保証のないパケット損失、サイズ予算、バックプレッシャー、再接続、非対応ブラウザへの対処を含め、WebTransportのdatagramsを使用する方法を説明してください。単にWebSocketとHTTP/3を比較するだけに留めないでください。
面接官が評価するポイント
- データグラムは到達や順序を保証せず、重要な確定情報を伝送できないことを理解しているか。
- メッセージのバージョン管理、有効期限、破棄ルール、トラフィック予算を設計できるか。
- データグラムを信頼性のあるストリームと分離し、キュー、輻輳、再接続を処理できるか。
- HTTPS、機能検出、フォールバック、可観測性を提供できるか。
尋ねるべき明確化のための質問
- どのメッセージが再構築可能な一時的状態であり、どれが信頼性のある順序通りの永続化を必要としますか？
- 許容されるデータグラムサイズ、更新頻度、目標レイテンシ、パケット損失率はどの程度ですか？
- クライアントはスナップショットから復旧できますか？また、再接続時に信頼できる状態（authoritative state）をどこから取得しますか？
- ブラウザおよびネットワークはWebTransport、HTTPS、HTTP/3をサポートしていますか？フォールバックは何ですか？
30秒の回答フレームワーク
破棄可能な現在の状態にはデータグラムを割り当て、操作、権限、最終結果は信頼性のあるストリームまたはサーバーのストレージに配置します。各状態更新にはシーケンス、タイムスタンプ、オブジェクトバージョンを付与し、受信側は新しいバージョンのみを適用して古いデータを破棄します。送信側は無制限にバッファリングするのではなく、サイズ、レート、キューの長さに上限を設けます。接続は信頼性のあるスナップショットから開始し、再接続時には再び権限のある状態を取得し、機能がサポートされていない場合は既存の信頼性のあるチャネルにフォールバックします。
ステップごとの詳細解説
1. 信頼性の境界を設定する
カーソルやプレビューは再構築可能であり、データグラムに適しています。ドキュメントの操作、権限の変更、コミット結果には、信頼性のある順序通りのパスが必要です。1つの接続を共有しているからといって、2つのトランスポートセマンティクスが相互に置き換え可能になるわけではありません。
2. 破棄可能なメッセージを設計する
各オブジェクトに単調増加シーケンス、作成日時、セッションバージョンを付加します。より新しいバージョンのみを受け入れ、鮮度ウィンドウから外れたメッセージ、削除済みオブジェクトに関するメッセージ、または現在のバージョンより古いメッセージは破棄します。スナップショットで復元できない唯一無二の事実をデータグラムに含めるべきではありません。
3. 予算とリカバリを制御する
メッセージサイズ、送信レート、キューの長さに上限を設けます。キューが上限に近づいた場合は、オブジェクトごとに最新の状態を合体（coalesce）させます。再接続後は、古い一時的な状態が上書きしないよう、新しいデータグラムを適用する前に信頼性のあるストリーム経由でスナップショットを取得します。
4. 互換性と可観測性
セキュアコンテキストでのみ接続を確立し、ブラウザの機能を検出します。破棄率、キューの長さ、送信失敗、再接続、スナップショットによる修復時間を記録します。WebTransportが利用できない場合は、同一の状態バージョンプロトコルを維持したまま、WebSocketまたはポーリングにフォールバックします。
モデル回答
メッセージを「再構築可能な一時的状態」と「損失を許容しない確定情報」に分類します。カーソルとドラッグプレビューにはデータグラムを使用し、ドキュメント操作、権限、コミット結果には信頼性のあるストリームを使用します。すべてのデータグラムにはオブジェクトバージョン、シーケンス、タイムスタンプを含めます。受信側は新しいバージョンを受け入れて古いものを破棄し、送信側はサイズ、レート、キューを制限して更新を合体させます。接続時または再接続時には、データグラムを再開する前に信頼性のあるスナップショットで正当性を確立します。HTTPS、機能検出、WebSocketまたはポーリングへのフォールバック、そして損失、キュー、再接続、修復時間のメトリクスによって設計を完成させます。
よくある間違い
- データグラムを信頼性のある順序付きキューとして扱うこと。
- 権限、支払い、または再構築不可能な確定情報をデータグラムとして送信すること。
- バージョンや鮮度情報を省略し、古い状態で新しい状態を上書きしてしまうこと。
- 輻輳時に送信キューを無制限に増大させること。
- 再接続後に権限のあるスナップショットを取得せず、古い状態を再開すること。
- HTTPS、ブラウザ検出、フォールバックを無視すること。
フォローアップ質問と回答
パケット損失が増加した場合はどうしますか？
状態ウィンドウを短縮し、送信レートを下げ、オブジェクトごとに更新を合体させます。重要な確定情報は信頼性のあるストリーム上に保持します。スナップショットから状態を再構築できない場合は、データグラムの採用を再検討します。
順序不同による上書きをどのように防ぎますか？
オブジェクトバージョンまたは単調増加シーケンスを比較し、より大きな値のみを受け入れます。再接続時にはセッションエポックを進め、古いセッションからのメッセージを拒否します。
なぜ信頼性のあるストリームを維持するのですか？
データグラムは到着や順序を保証せず、「新しい値が古い値を置き換える」状態に適しています。ログ、スナップショット、権限、最終確認には、信頼性のある転送と永続化が必要です。