リアルタイムデータ用のWebSocketとREST API
金融商品のリアルタイムデータを取得するには、常にサーバーにアクセスする必要があります。価格は常に変化しているので、0.5秒ごとに新しい価格をリクエストする必要があります。 RESTブローカーのAPIでこれを行うことができますが、サーバーに接続するときにかなりの遅延があることに気づきました。ただし、WebSocket APIもあることに気付きました。どちらも長所と短所がありますが、私がやりたいことと、ここでは速度が特に重要であるため、APIをどのようにすすめますか？WebSocketは本当に高速ですか？
ありがとうございました！
あなたが説明していることの最も効率的な操作は、クライアントとサーバーの間のwebSocket接続を使用し、価格が意味のある量または最小量だけ変化した場合にのみ、サーバーが更新された価格情報をwebSocket経由でクライアントに直接送信することです時間の経過と価格の変化。
これは、クライアントに常に新しい価格の変更を要求するよりもはるかに効率的であり、新しい情報がクライアントに届くタイミングをよりタイムリーにすることができます。
したがって、新しい価格レベルの情報がクライアントにどれだけ早く届くかに興味がある場合は、サーバーが新しい価格情報を変更した瞬間にクライアントに直接送信できるので、webSocketはよりタイムリーに情報を取得できます。サーバー上。 REST呼び出しを使用するのに対し、クライアントは一定の時間間隔でポーリングする必要があり、ポーリング間隔の時点でのみ新しいデータを取得します。
すでに開いているwebSocket接続を介してパケットを送信するだけで、REST/Ajax呼び出しごとに新しい接続を作成し、新しいデータを送信して接続を閉じるために必要なネットワーク操作が少ないため、ネットワークインフラストラクチャでのwebSocketはより速く簡単になります。 。これが特定のアプリケーションでどの程度の違い/改善をもたらすかは、実際に知るために測定する必要があるものです。
しかし、webSocketsは、サーバーで何かが変更されたときにクライアントが知りたい特定のシナリオを支援するように設計されています（実用に近いリアルタイムで）、このタイプの推奨設計パターンであると私は間違いなく思います。使用する。
ここでは、既に開いているwebSocketを介して価格変更を送信する場合と、RESTを呼び出す場合とで、.
webSocket
- サーバーは価格が変更されたことを確認し、すぐに各クライアントにメッセージを送信します。
- クライアントは新しい価格に関するメッセージを受け取ります。
休憩/ Ajax
- クライアントはポーリング間隔を設定します
- 次のポーリング間隔トリガーで、クライアントはサーバーへのソケット接続を作成します
- サーバーは新しいソケットを開く要求を受け取ります
- サーバーとの接続が確立すると、クライアントは新しい価格情報の要求をサーバーに送信します
- サーバーは新しい価格情報の要求を受け取り、新しいデータ（ある場合）を返信します。
- クライアントは新しい価格データを受け取ります
- クライアントがソケットを閉じる
- サーバーがソケットを閉じる
ご覧のとおり、ネットワーキングの観点から見ると、Rest/Ajax呼び出しでは、WebSocketがすでに開いている呼び出しを使用するのに対して、新しい呼び出しごとに新しい接続を確立する必要があるため、さらに多くのことが行われています。さらに、webSocketの場合、新しいデータが利用可能になったときにサーバーがクライアントに新しいデータを送信するだけです。クライアントは定期的にそれを要求する必要はありません。
価格設定情報がそれほど頻繁に変更されない場合、REST/Ajaxシナリオでは、クライアントが更新を要求する「何もしない」呼び出しも頻繁に行われますが、新しいデータはありません。サーバーは新しいデータが利用可能になったときに新しいデータを送信するだけなので、webSocketのケースにはそのような無駄なケースはありません。