WebSocketとは？ ハンドシェイク、フレーム、フルデュプレックスデータ

紹介

WebSocketは、HTTP互換のオープニングハンドシェイクで始まり、WebSocketフレームを交換する永続的でフルデュプレックスの通信チャネルです。どちらのエンドポイントも、データがあるときにアプリケーションメッセージを送信できます。

プロトコルは、フレーミング、制御メッセージ、マスキングルール、クローズセマンティクス、発信元関連のハンドシェイクフィールドを提供します。アプリケーションのメッセージスキーマ、認証モデル、イベント履歴、または状態回復戦略を定義しません。それらはサービスの設計作業として残ります。

オープニングハンドシェイク

クライアントは、Upgrade、Connection、Sec-WebSocket-Key、Sec-WebSocket-Version、しばしばOriginおよびサブプロトコルの設定を含むHTTPリクエストを送信します。受け入れるサーバーは、必要なSec-WebSocket-Accept値を計算し、101 Switching Protocolsを返します。

その応答の後、通常のHTTPメッセージセマンティクスはその接続上のデータをフレーミングしなくなります。 RFC 6455はWebSocketプロトコルを定義します、ハンドシェイクフィールド、登録されたURIスキーム、フレームレイアウト、およびクローズコードが含まれます。

フレームとメッセージ

アプリケーションデータはテキストまたはバイナリメッセージで運ばれます。メッセージは1つのフレームを占有するか、いくつかのフレームに分散することができます。制御フレームはクローズ、ping、pong信号を運び、接続管理を応答的に保つ制約があります。

ブラウザクライアントはサーバーに送信するフレームをマスクしますが、サーバーはクライアントに送信するフレームをマスクしません。マスキングは暗号化ではありません。wssを使用してTLSが機密性、整合性、およびサーバー認証を提供します。メッセージペイロードの検証はまだアプリケーションに属します。

フルデュプレックスはAPIの形を変えます

リクエストレスポンスのHTTPでは、クライアントのアクションは自然にレスポンスとペアになります。WebSocketトラフィックは、いつでもどちらの方向からも到着する可能性があるため、アプリケーションはメッセージタイプ、相関識別子、順序ルール、エラーエンベロープ、およびバージョン交渉を必要とします。

コマンドは、確認、結果、または更新のストリームを期待するかどうかを示す必要があります。イベントは、冪等的に適用するための十分な識別子とバージョン情報を含む必要があります。明示的な契約がないと、ソケットは進化しにくいあいまいなJSONオブジェクトのストリームになります。

接続ライフサイクルと状態回復

WebSocketはアプリケーションポリシー、サーバーデプロイメント、アイドルネットワーク状態、デバイススリープ、プロキシ動作、またはパスロスのために閉じることがあります。Pingおよびpongフレームは生存をテストできますが、失われたビジネスイベントを復元することはできません。

再接続を状態同期とは別に設計します。新しい接続後、クライアントは最後に見たイベントIDを送信したり、スナップショットをリクエストしたり、トピックに再購読したりすることがあります。 WHATWG WebSockets Standard は、アプリケーション回復をサービスに委ねながらブラウザAPIの動作を定義します。

セキュリティ境界

ブラウザクライアントのOriginを検証し、ユーザーを認証し、すべての購読とコマンドを承認し、メッセージサイズの制限を強制し、サポートされていないサブプロトコルを拒否します。接続されたソケットは永続的な承認ではなく、権限とセッションの有効期限はオープンのままで変わる可能性があります。

耐久性のある秘密をURLに置くのを避けます。エンドポイントはログに表示される可能性があるためです。アイデンティティごとにレートと同時実行の制限を適用し、ペイロードを防御的に解析し、制御されたコードで接続を閉じます。TLSはトランスポートを保護し、ビジネスの承認がリソースを保護します。

スケーリングとバックプレッシャー

WebSocketサーバーは多くのクライアントの接続状態を保持します。マルチインスタンスデプロイメントでは、1つのノードで生成されたイベントが別のノードの接続に届くように、ルーティングまたはパブリッシュサブスクライブ層が必要です。デプロイ中に接続を排水することも明示的なプロセスが必要です。

遅いクライアントは、ネットワークが受け入れるよりも早く外向きメッセージを累積する可能性があります。各送信キューに境界を設け、置き換え可能な状態更新を統合し、文書化されたポリシーの下で追いつけないクライアントの接続を切断します。 MDNのWebSocket APIリファレンス は、クラシックなブラウザインターフェースが組み込みのバックプレッシャーを提供しないことに注意しています。

WebSocketとは？ ハンドシェイク、フレーム、全二重データ検証プラン

WebSocketは全二重です。クライアントとサーバーはハンドシェイク後に独立して送信できます。実際のプロダクションパス全体でその主張を検証します。小さな代表的な交換から始め、クライアントとエッジで交渉された動作を記録し、アプリケーションが同じゲートウェイ、プロキシ、証明書終了点、および実際のトラフィックで使用されるネットワークポリシーを通じて期待するフィールド、フレーム、またはイベントを受信することを確認します。

最初の設計仮定を失敗演習に変えます：プロダクションエンドポイントにはwssを要求します。その後、2番目の仮定の周囲のリソース圧力を調査します：ブラウザのOrigin値を検証します。正しい実装は記載された制限内で失敗し、接続やバッファの状態を解放し、資格情報やプライベートペイロードを公開することなく結果を説明するトレースを残すべきです。

共同編集とインタラクティブダッシュボードは設計の異なる部分を演習するので、互換性テストには関連するトラフィック形状の両方が含まれるべきです。現在のブラウザ、非ブラウザクライアント、遅いネットワークパス、および最も古いサポートされた仲介者を追加します。バージョン選択、接続ライフタイム、メッセージまたは応答の年齢、キュー深度、優先パスおよびそのフォールバックの理由を記録します。

テスト中に意味論とトランスポートを別々のレイヤーとしてレビューします。成功した接続は、アプリケーションが順序付け、認証、キャンセル、キャッシング、再生、または状態回復を正しく処理したことを証明するものではありません。同様に、アプリケーションエラーは交渉されたプロトコルが失敗したことを証明するものではありません。リソース、ユーザー範囲、論理操作、および接続識別子で観察をタグ付けし、それぞれのエンドポイントが何が起こったと信じていたかを比較します。この分離により、キャパシティワークがより有用になります：チームは、遅延が接続設定、ネットワーク配信、キューイング、アプリケーション処理、シリアル化、または遅い受信者から来たかを確認できます。ルーチンテレメトリーからプライベートコンテンツを除外し、決定を再現するために十分なタイミングと結果データを保持します。

WebSocketとは？ ハンドシェイク、フレーム、全二重データが実際に現れる場所

WebSocketとは？ ハンドシェイク、フレーム、全二重データのプロダクションチェックリスト

• プロダクションエンドポイントにはwssを要求します。 レビュアーが意図した動作と偶発的な実装の詳細を区別できるように、これを文書化された受け入れテストに変換します。
• ブラウザのOrigin値を検証します。 設定を所有しているコンポーネントと、観察された動作が変わるときに応答する人またはチームの名前を付けます。
• 特権サブスクリプションを受け入れる前に認証します。 関連する信号をログまたはトレースにキャプチャし、その後信号が実際のパスのすべてのプロキシ、ゲートウェイ、サービス境界を生き残ることを検証します。
• すべてのメッセージタイプを承認します。 通常のケース、遅いピア、閉じた接続、オーバーサイズの入力、およびバージョンまたは機能不一致でその決定をテストします。
• 最大フレームおよびメッセージサイズを設定します。 安全なデフォルトと例外を許可する正確な条件を文書化します。隠れた例外は後の変更中の相互運用性の問題になります。
• ping、アイドル、および閉じるポリシーを定義します。 その動作を代表的なブラウザまたはクライアントから確認し、ローカルユニットテストまたはサーバーサイドの構成画面にのみ依存するのではなく、確認します。
• 接続ごとに外向きキューをバウンドします。 有限リソース制限を設定し、結果として得られた拒否をオペレーターと呼び出しアプリケーションの両方に可視化します。
• アプリケーションメッセージ契約のバージョン管理。 クライアント、エッジ、アプリケーション、および任意の非同期ワーカー間で1つの論理交換を関連付けるために十分な識別子を保持します。
• スナップショットまたはカーソルベースの状態復元を提供します。 トラフィック形状の変更後に選択をレビューします。接続数、ペイロードサイズ、メッセージ頻度は正しい設計を変更する可能性があります。
• デプロイ中に接続を排出して観察します。 フォールバックパスは観察可能でテスト済みであり、互換性が古いパスに依存して静かに動作しなくならないようにします。

結論

WebSocketはフルデュプレックスです。クライアントとサーバーはハンドシェイク後に独立して送信できます。アプリケーションは独自の契約を定義します。プロトコルのフレーミングはトピック、コマンド、権限、再生を作成しません。明示的な制限、観察可能な状態、および設定ではなく代表的なクライアントによってテストされたフォールバックを使用してください。

参考文献

• Scrapeless Scraping Browserのドキュメント
• Scrapeless Scraping Browserの製品概要
• Scrapeless WebSocketフレームキャプチャガイド