WebSocketを使用するためのサーバーコストはありますか？
構文/カプセル化/手続き的なものがイライラする可能性があるため、PHP/MySQLの快適ゾーンから離れてきました。
先週、私は遊んで始め、いくつかのチュートリアルに従ってNode.js /Socket.IOを使用してライブチャットアプリケーションを作成しました。この時点まで、私はWebSocketで何もしたことがなく、WebSocketは本当にクールに見えます。サーバーとクライアント間の即時通信は素晴らしいです。
さて、ここでの私の理解の欠如を許してください、しかしHTTPはあなたがクライアントとサーバーの間の接続を開いたままにできないように設定されています-そしてCometの私の基本的な理解はそれが接続を開いたままにすることを強制するということです書き込みストリームを終了せず、NULバイトを送信するだけです。これは...サーバーを集中的に使用するように聞こえます。
では、WebSocketはどのように機能しますか？チャットアプリに一度に数百人が参加した場合、サーバーが過負荷になりませんか？サーバーでPHP/MySQLを使用する場合、サーバーは一度に1つのリクエストのみを処理します。AJAXを使用して、たとえば1秒ごとにポーリングすると、 1分間に何千ものリクエストがあるため、すぐにエスカレートします。
私の質問は、WebSocketは大規模なアプリケーションに対応できるかということです。本当に高帯域幅のサーバーがなくても実用的ですか？
つまり、AJAX頻繁な間隔でのポーリング、Comet、およびWebSocketの間にサーバーの負荷/ユーザーエクスペリエンスに大きな違いはありますか？
ありがとう！
WebSocketが一般的にどのように機能するかについて読むための良い概要サイトがたくさんあります ここ と ここ 。
一言で言えば、それらは特定のタイプのHTTPリクエストで接続を開始し、その後、クライアントとサーバー間の直接TCP双方向接続になります。
クライアントへのオープンソケットを維持するためにサーバーのオーバーヘッドがいくらかあるため、一度に数万のソケットを予測する場合は、サーバーインフラストラクチャがその規模に対応できることを確認する必要があります。アイドル状態のソケットはCPUを使用しないため、CPUの負荷は、常にビジー状態のソケットの数にのみ比例します。
WebSocketを使用するためのサーバーコストはありますか？
それは本当にあなたがそれを比較しているものに依存します。 webSocketは通常、データが利用可能になったときにサーバーがクライアントにデータを送信できる必要がある場合に使用されます（多くの場合「サーバープッシュ」と呼ばれます）。継続的に接続されたwebSocketを使用する代わりの通常の方法は、クライアントに繰り返しポーリングを行わせ、サーバーに新しいものがあるかどうかをサーバーに何度も尋ねることです。 webSocketを繰り返しクライアントポーリングと比較すると、webSocketは一般的にはるかに効率的であり、頻繁にポーリングするクライアントよりもwebSocketを使用してサーバーを大幅に拡張できます。
サーバーは、数十万の同時（そしてほとんどアイドル状態）のwebSocket接続をサポートするように適切に構成できるため、サーバーのスケーラビリティ制限は、これらすべての接続されたクライアントに送信するトラフィックの量によって制限されます。数秒ごとにクライアントにデータを送信していて、数十万のクライアントが接続されている場合、どのテクノロジーでもそれを行うには多くのサーバーの馬力（および帯域幅）が必要になります。競合するテクノロジー。ただし、webSocketに接続されたクライアントがほとんどアイドル状態であり、データがたまに送信されるだけの場合、webSocketの実装は非常に効率的に拡張できます。
このトピックに関するその他の参考資料は次のとおりです。
リアルタイムデータ用のWebSocketとREST API？
Websocket vs RESTサーバーにデータを送信する場合
WebSocketを使用する理由とそれを使用する利点は何ですか？
HTML5 WebSocket：Webのスケーラビリティの飛躍的進歩
Cometライブラリは、WebSocketが直接サポートされていない場合でも、WebSocketのようなインターフェイスをサポートしようとします。これは、オープンHTTP接続を維持することによって双方向TCPソケットをシミュレートしようとするときに、やや非効率的なハックが現れ始める場所です。実際のWebSocketを使用している場合、これは問題ではありません。
帯域幅を考慮すると、WebSocketは、CometまたはAJAXlong-polling。websocketプロトコルを使用すると、必要な場合にのみデータを送信でき、適用される場合にのみ適用されます。送信する各メッセージへの最小限のパディング（8〜14バイト、および必須のTCPおよびIPフレーミング））。
すべてのアクティブなクライアントが個別の接続を開いているのは正しいことです。したがって、多数（数千）の同時クライアントがある場合、Webサーバー、フレームワーク、またはオペレーティングシステムの接続制限に達する可能性がありますが、これらの制限は通常構成可能です。
WebSocketとその仕組みについて学び始めるのに適した場所は ここ です。 WebSocket接続は、予期しないネットワークの問題が発生した場合、またはクライアントまたはサーバーが接続を終了することを明示的に決定した場合を除いて、「決して」終了しません。
Node.jsは多くのオープン接続を処理できるため（OSのオープンファイル記述子の設定が十分に高い場合）、通常は単一のシステム/スレッドでかなり遠くまで行くことができます。ただし、1つのスレッドを超えてスケーリングする必要がある場合、1つのシステムでは不十分な場合は、常に「クラスター」モジュールや複数のシステム間の負荷分散を使用できます。
どちらかといえば、長いポーリングや同様のソリューションの場合のように接続を作成および切断しないため、WebSocketを使用するとオーバーヘッドを減らすことができます。