WebSocketはどの時点でポーリングよりも効率が悪いのですか？

Question

上記の質問に対する答えは、アプリケーションのアーキテクチャによってある程度決定されることは理解していますが、私は主に非常に単純なシナリオに関心があります。

基本的に、アプリが変更について5秒ごと、または1分ごとにpingを実行している場合、開いているWeb Sockets接続を維持するために送信されるデータは、単純なポーリングで無駄になる量を超えるのはいつですか？

基本的に、アプリケーションが必ずしもリアルタイムの更新を必要とせず、定期的なチェックのみを必要とする場合に、Meteorなどのフレームワークを使用して発生する非効率性を定量化する方法があるかどうかに関心があります。

Meteorのようなフレームワークには、データベースの更新のみを要求する高度に最適化された方法があるため、ここでは、必ずしもデータベースアクセス時間ではなく、帯域幅の使用率に焦点を当てていることに注意してください。

jfriend00 · Accepted Answer

WebSocket接続の要点は、変更のためにアプリにpingを実行する必要がないことです。代わりに、クライアントは1回接続するだけで、サーバーはクライアントの変更が利用可能になるたびに直接送信できます。クライアントは決して尋ねる必要はありません。サーバーは、データが利用可能になったときにデータを送信するだけです。

サーバーが開始するあらゆるタイプのデータの場合、これはhttpポーリングよりも帯域幅の方がはるかに効率的です。よりタイムリーな結果を提供することに加えて（結果は、次のポーリング間隔でのみクライアントによって検出されるのではなく、すぐに配信されます）。

純粋な帯域幅の使用については、詳細は正確な状況によって異なります。 httpポーリング要求は、TCP接続を設定し、その接続（SSL接続の場合はさらに多くのデータ）を確認する必要があります。次に、関連するCookieを含むhttp要求を送信する必要があります。そのホストに関連するヘッダーとGETURLを含めてから、サーバーは応答を送信する必要があります。また、レポートする新しいものがないため、ほとんどの場合、ポーリングのこのオーバーヘッドはすべて完全に帯域幅を浪費します。

WebSocketは単純なhttpリクエストで始まり、プロトコルをwebSocketプロトコルにアップグレードします。 webSocket接続自体は、サーバーがクライアントに送信するものを取得するまでデータを送信する必要はありません。クライアントに送信するものがある場合、サーバーはパケットを送信するだけです。データ自体を送信することによるオーバーヘッドもはるかに少なくなります。クッキーやヘッダーなどはなく、データだけです。 webSocketでいくつかのキープアライブを使用している場合でも、その量のデータはHTTPリクエストのオーバーヘッドと比較して非常に少量です。

したがって、帯域幅をどれだけ節約できるかは、状況の詳細によって異なります。有用なデータが見つかるまでに50のポーリング要求が必要な場合、webSocketシナリオと比較して、これらのhttp要求はすべて完全に無駄になります。帯域幅の違いは非常に大きい可能性があります。

定期的なチェックのみが必要なアプリケーションについて質問されました。データが取得されないという定期的なチェックを行うとすぐに、帯域幅が無駄になります。これがwebSocketの全体像です。送信するデータがない場合、帯域幅を消費しません（または帯域幅がほとんどありません）。

Myst · Answer

@ jfriend00が質問に非常に明確に答えたと思います。しかし、私は考えを追加したいと思います。

WebsocketとHTTPの最悪の場合（そしてありそうもない）のシナリオを投げかけることで、Websocket接続が帯域幅（そしておそらくオールラウンドなパフォーマンス）に関して常に利点があることがはっきりとわかります。

これは、Websockets v/sHTTPの最悪のシナリオです。

コードは、ポーリングにHTTPリクエストを使用するのとまったく同じ方法でWebsocket接続を使用します。

（これはあなたがすることではありません、私は知っていますが、それは最悪のシナリオです）。
すべてのポーリングイベントは肯定的に回答されます。つまり、HTTPリクエストは無駄に実行されませんでした。

これは、ポーリングではなくデータをプッシュするように設計されたWebsocketにとって最悪の状況です... Websocketは、帯域幅とCPUサイクルの両方を節約します。

真剣に、DNSクエリ（クライアントによって実行されるので、気にしないかもしれません）とTCP/IPハンドシェイク（クライアントとサーバーの両方にとって高価です）を無視しても、Websocket接続はさらにパフォーマンスが高くコストがかかります-効果的。

説明します：

各HTTPリクエストには、Cookieやその他のヘッダーなどの多くのデータが含まれています。多くの場合、各HTTPリクエストはクライアント認証の対象にもなります...データが誰かに渡されることはめったにありません。

これは、HTTP接続がこのすべてのデータを渡す（そして場合によってはクライアント認証を実行する）リクエストごとに1回。[ステートレス]

ただし、Websocket接続はステートフルです。データは（リクエストが行われるたびにではなく）1回だけ送信されます。クライアント認証は、Websocket接続ネゴシエーション中にのみ発生します。

これは、Websocket接続が同じデータを渡す（そして場合によってはクライアント認証を実行する）接続ごとに1回（すべてのポーリングに対して1回）を意味します。

したがって、ポーリングが常にポジティブであり、データをプッシュする代わりにWebsocketがポーリングに使用されるこの最悪のシナリオでも、Websocketはサーバーの帯域幅とその他のリソース（CPU時間など）の両方を節約します。

簡単に言えば、あなたの質問に対する答えは「決して」ではないと思います。 Websocketは、ポーリングよりも効率が悪くなることはありません。