WebSocketとは？

Scrapeless Agent Browserは、Chrome DevTools Protocolを介したサポートされているリモートブラウザ制御のためのWebSocket接続を提供します。

WebSocketは、長期間接続を維持しながら双方向メッセージを交換するためのプロトコルです。クライアントはハンドシェイクを通じて接続を開き、その後クライアントとサーバーは独立してメッセージを送信できます。このモデルは、ライブダッシュボード、共同インターフェース、継続的なコマンドやイベントが必要なブラウザ制御セッションに適しています。これは、何かが変更されたかどうかを尋ねるために別々のHTTPリクエストを繰り返し送信することとは異なります。

オープンな接続は、各メッセージの意味についての約束ではなく、輸送手段です。アプリケーションは、メッセージタイプ、認証、順序の期待、およびクローズド接続の取り扱い方法を定義しなければなりません。このガイドは、プロトコルの境界と、それに基づく設計上の決定を説明します。

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

WebSocket接続は、HTTPに関連付けられたハンドシェイクで始まります。クライアントは通信のアップグレードを要求し、サーバーはそのリクエストを受け入れるか拒否することができます。 WebSocketプロトコル仕様 は、ハンドシェイクとメッセージフレーミングを定義します。成功したハンドシェイクの後、当事者は各メッセージについて、通常のHTTPレスポンスボディではなくWebSocketフレームを交換します。

お馴染みのwsおよびwss URLスキームは、保護されていないおよびTLS保護されたWebSocket接続を識別します。資格情報やアプリケーションデータを運ぶリモートサービスには、提供者が文書化した場合は安全な形式を使用してください。正確なパスとクエリパラメータはサービス契約に属し、一般的なWebSocketクライアントは特定のエンドポイントが受け入れるメッセージを推測することはできません。

オープニングリクエストには、ブラウザからのOrigin値を含めることができ、サーバーはそのオリジンがその使用ケースにとって受け入れ可能かどうかを評価するべきです。WebSocketのセキュリティは、ブラウザのCORSとは同一ではありません。アプリケーションの認可は依然として実施される必要があります。成功したプロトコルハンドシェイクはチャンネルを確立するだけで、それを通じて送信されるすべてのメッセージの許可を付与するものではありません。

メッセージ、フレーム、および接続状態

WebSocketは、テキストまたはバイナリのメッセージを転送します。メッセージは1つ以上のフレームによって運ばれることができ、プロトコル制御フレームは接続を閉じたり健全に保ったりするための機能をサポートします。 MDN WebSocket APIガイド は、接続を開き、メッセージを受信するためのブラウザインターフェースを紹介しています。

アプリケーションは、テキストメッセージの意味を決定します。株の更新は、シンボルと価格を持つJSONかもしれません; ブラウザ制御プロトコルは、コマンド識別子とイベント名を運ぶことができます。メッセージ形式を解析し、アプリケーション状態に適用することは、ソケットの維持から独立した作業です。チャートを更新するかアクションをトリガーする前に、各着信メッセージを検証してください。

接続は通常の方法または予期しない方法で閉じることができます。クライアントは、最後のコマンドが確認されたかどうか、更新を逃したかどうか、また後のセッションがどの状態から開始すべきかを知る必要があります。一部のアプリケーションは、それらの質問に答えるためのシーケンス番号やスナップショットを提供します。そのようなアプリケーションレベルの設計がない場合、オープンな接続は世界の不完全なビューを提供する可能性があります。

WebSocketがHTTPポーリングと異なる点

ポーリングを使用すると、クライアントは新しい情報を要求するために繰り返しリクエストを送信します。WebSocketはチャンネルをオープンに保ち、必要なときに任意の当事者がメッセージを送信できます。これにより、繰り返しのリクエストオーバーヘッドを減らし、頻繁に変化するデータの応答性を改善することができます。得られる利点は、トラフィックパターンと展開に依存します; 一時間ごとにステータスをチェックするページは、必ずしも持続的な接続を必要としません。

HTTPは、リソースの作成、静的ドキュメントの取得、および明確なリクエストとレスポンスを伴う操作に役立ちます。WebSocketは、交換が継続的で両側が話す必要がある場合に便利です。システムは両方を利用できます: 最初のページをロードし、コンテキストを確立するためにHTTPを使用し、その後はライブ更新のためにソケットを使用します。一方の輸送手段を選択することは、もう一方を削除する必要はありません。

サーバー送信イベントは、サーバーがHTTPレスポンスを介してクライアントにイベントを送信する別のライブ更新モデルを提供します。それは一方向のフィードにはより簡単かもしれません。WebSocketは双方向メッセージを提供します。新しい機能のためのトランスポートを選択する前に、通信の方向、ブラウザサポート、インフラストラクチャの動作、および状態回復を比較してください。

ブラウザ自動化におけるWebSocket

リモートブラウザ制御は、ブラウザにコマンドを送信し、コントローラーにイベントを返す必要があります。 Scrapeless Agent Browser は、サポートされたブラウザツールを介して接続するための文書化された安全なWebSocketエンドポイントを提供します。 Agent Browserクイックスタート は、セッションを確立する方法を説明します。WebSocketトランスポートはチャンネルであり、ブラウザ制御プロトコルはコマンド語彙を定義します。

そのブラウザ内のページは、ウェブサイトへの独自のWebSocketを開く場合があります。それは、コントローラーのAgent Browserへの接続とは異なる接続です。それらを混同すると、誤った結論を導くことになります: ブラウザ制御ソケットを観察することは、ターゲットページがライブソケットを使用していることを意味するわけではなく、ターゲットページフレームをキャプチャすることは、コントローラーの内部コマンドを明らかにしません。

関連する WebSocketフレームキャプチャガイド は、ブラウザツールが承認されたワークフローでページ作成ソケットトラフィックを観察する方法を示しています。フレームには、公開市場データ、プライベートアカウント情報、または別のアプリケーションメッセージが含まれる場合があります。タスクの権限内のデータのみを検査し、不要にトークンや個人ペイロードをログするのを避けてください。

長期間のチャネルの運用上の課題

オープン接続は両端でリソースを消費します。サーバーはアイドルクライアントを管理し、遅い受信者のためにどれだけの未送信データをバッファするかを制約する必要があります。クライアントは、更新が停止したときに古い状態をどのように表示するかを決定しなければなりません。ブラウザのWebSocketインターフェースは、すべての使用パターンに対してバックプレッシャーを自動的に解決するわけではないため、高ボリュームのストリームは明示的な負荷テストとメッセージ処理設計が必要です。

仲介者は接続のライフタイムに影響を与えることがあります。リバースプロキシ、ゲートウェイ、ネットワークの変更は、アプリケーションが正常な状態であってもアイドル状態または長時間実行中の接続を閉じることがあります。アプリケーションがクローズを検出し、権威あるスナップショットまたはカーソルから正しいビューを復元する方法を定義してください。新しくオープンされたソケットが古いものが見た正確なイベントシーケンスを再開するとは限りません。

セキュリティ制御はアプリケーションプロトコルに属します。接続またはメッセージをサービス契約に従って認証し、各センシティブな操作を認可し、メッセージのサイズとタイプを検証し、アクセスが終了したときにセッションを閉じてください。 WebSocketサーバーガイド はハンドシェイクチェックをカバーしています。安全なトランスポートは移動中のデータを保護します。信頼できないメッセージが処理するのを安全にするわけではありません。

WebSocketを選ぶべきタイミング

実際のユースケースでタイムリーな双方向交換が必要な場合にWebSocketを選択してください：共同編集、インタラクティブコントロール、ライブテレメトリー、またはリモートブラウザセッションがその例です。必要な更新頻度、最大メッセージサイズ、および切断後の動作を定義してください。プロトコルはチャンネルをサポートしますが、アプリケーションが正確性を定義する必要があります。

偶発的な読み取りの場合、最初は通常のHTTP操作から始めてください。アプリケーションがサーバーからクライアントへの更新のみが必要な場合は、サーバー送信イベントを比較してください。同じ進行中のチャンネルでコマンドとイベントが必要な場合、WebSocketはより魅力的になります。デモがよりライブに感じるからプロトコルを選ぶのではなく、代表的な作業負荷を測定してください。

HTTP APIと同じくらい注意深くメッセージを文書化してください。各メッセージタイプに名前を付け、必要なフィールドを特定し、エラーとクローズの動作を指定します。接続からクリーンアップまでの意図されたシーケンスをテストします。明確に定義されたプロトコルを持つアプリケーションはWebSocketを効果的に使用できますが、定義されていない状態遷移を持つアプリケーションは、完全に機能するソケットにもかかわらず失敗する可能性があります。

ライブデータ消費者も明確なスナップショットの境界が必要です。もしそれが以前のイベントが発生した後にストリームに参加する場合、初期のHTTPスナップショットの後にそのスナップショットを更新するメッセージが必要になります。クライアントがスナップショットとストリームの間のギャップをどのように認識するかを定義してください。そのルールがないと、完全に順序付けられたソケットでもクライアントが開始状態を学ばなかったために不完全な残高や在庫数を表示することがあります。

結論

WebSocketはオープニングハンドシェイクの後に永続的な双方向チャネルを提供します。それは継続中のコマンドやイベントに適しており、リモートブラウザコントロールを含みますが、アプリケーションのメッセージの意味や回復動作を定義するものではありません。それらのルールを明示的に設計し、実際の接続条件の下で検証してください。