HTML WebSocketsは各クライアントに対してオープンな接続を維持していますか？これはスケールしますか？
誰かがHTML WebSocketのスケーラビリティに関する情報を持っているかどうか興味があります。私が読んだすべてについて、すべてのクライアントがサーバーとのオープンな通信回線を維持しているように見えます。サーバーが処理できるオープンなWebSocket接続の規模とその数を、どのように拡張するのか疑問に思っています。これらの接続を開いたままにしておくことは、実際には問題ではないかもしれませんが、実際にはそう感じています。
ほとんどの場合、WebSocketsはおそらくAJAX/HTMLリクエストよりも優れたスケーラビリティを発揮します。ただし、それは、WebSocketsがAJAX/HTMLのすべての使用の代わりになることを意味しません。
各TCP接続自体は、サーバーリソースの点ではほとんど消費しません。多くの場合、接続のセットアップには費用がかかりますが、アイドル接続の維持はほとんど無料です。通常、最初に発生する制限は最大です同時に開くことができるファイル記述子（ソケットはファイル記述子を消費します）の数これはしばしば1024にデフォルト設定されますが、もっと高く設定することは簡単です。
数万の同時AJAXクライアントをサポートするようにWebサーバーを構成しようとしたことがありますか？それらのクライアントをWebSocketsクライアントに変更すると、実行可能になる可能性があります。
HTTP接続は、開いているファイルを作成したり、長期間ポート番号を消費したりすることはありませんが、ほぼすべての点でより高価です。
各HTTP接続には、ほとんどの時間使用されない多くの荷物があります。Cookie、コンテンツタイプ、コーンテントの長さ、ユーザーエージェント、サーバーID、日付、最終変更などです。WebSockets接続が確立されると、アプリケーションに必要なデータをやり取りする必要があります。
通常、HTTPサーバーは、ディスクおよびCPU時間を占有するすべてのHTTP要求の開始と完了を記録するように構成されます。 WebSocketデータの開始と完了を記録することが標準になりますが、二重転送を行うWebSocket接続では、追加のロギングオーバーヘッドはありません（アプリケーション/サービスがそうするように設計されている場合を除く）。
通常、AJAX=を継続的にポーリングするか、ある種のロングポールメカニズムを使用するインタラクティブアプリケーション。WebSocketは、サーバーとクライアントは、既存の接続を介してレポートするものがある場合、互いに通知します。
本番環境で人気のあるWebサーバーのほとんどには、HTTP要求を処理するプロセス（またはスレッド）のプールがあります。各プロセス/スレッドが一度に1つのHTTPリクエストを処理するため、圧力が増加するとプールのサイズが増加します。プロセス/スレッドを追加するたびにより多くのメモリが使用され、新しいプロセス/スレッドを作成することは、新しいソケット接続を作成するよりもかなり高価です（これらのプロセス/スレッドはまだ行う必要があります）。人気のあるWebSocketsサーバーフレームワークのほとんどは、イベントのルートをたどっています。
WebSocketの主な利点は、インタラクティブなWebアプリケーションの低遅延接続です。 HTTP AJAX/long-poll（アプリケーション/サーバーが適切に設計されていると仮定）よりも優れたスケーラビリティと少ないサーバーリソースを使用しますが、IMOの低レイテンシーはWebSocketの主な利点です。 AJAX/long-pollの現在のオーバーヘッドとレイテンシを使用します。
WebSockets標準がより完成し、より広範なサポートを取得したら、サーバーと頻繁に通信する必要があるほとんどの新しいインタラクティブなWebアプリケーションに使用することは理にかなっています。既存のインタラクティブなWebアプリケーションの場合、現在のAJAX/long-pollモデルがどれだけうまく機能しているかに本当に依存します。変換の努力は自明ではないので、多くの場合、コストは利益に見合うだけではありません。
更新：
明確な説明：サーバーは1つのポートでWS/WSS接続のみをリッスンしているため、サーバーがサポートできるクライアント接続の数は、このシナリオのポートとは関係ありません。他のコメンターが参照するつもりだったのは、ファイル記述子だったと思います。ファイル記述子の最大数を非常に高く設定できますが、開いている各TCP/IPソケットのソケットバッファーサイズの合計に注意する必要があります。追加情報は次のとおりです。 https://serverfault.com/questions/48717/practical-maximum-open-file-descriptors-ulimit-n-for-a-high-volume-system
WS vs HTTPを介した遅延の減少に関しては、最初のWSハンドシェイクを超えてHTTPヘッダーの解析がなくなるため、それは事実です。さらに、より多くのパケットが正常に送信されると、TCP輻輳ウィンドウが広がり、RTTが効果的に削減されます。
最新の単一サーバーは、サーバーに接続できます 一度に数千のクライアント 。 HTTPサーバーソフトウェアは、イベント駆動（IOCP）指向である必要があります（古いApacheでは、1つの接続= 1つのスレッド/プロセスの方程式ではなくなりました）。 Windowsに組み込まれているHTTPサーバー（http.sys）でもIOCP指向であり、非常に効率的です（カーネルモードで実行）。この観点から、WebSocketと通常のHTTP接続との間のスケーリングには大きな違いはありません。 1つのTCP/IP接続は少しのリソース（スレッドよりはるかに少ない）を使用し、最新のOSは多くの同時接続を処理するために最適化されています：WebSocketとHTTPは、このTCP/IP仕様を継承するOSI 7アプリケーション層プロトコルです。
しかし、実験から、WebSocketには2つの主な問題があります。
- CDNはサポートされていません。
- 潜在的なセキュリティの問題があります。
だから、私はすべてのプロジェクトのために、以下をお勧めします：
- クライアント通知のみにWebSocketを使用します（ロングポーリングへのフォールバックメカニズムを使用します-周囲には多くのライブラリがあります）。
- キャッシュにCDNまたはプロキシを使用して、他のすべてのデータにRESTful/JSONを使用します。
実際には、完全なWebSocketアプリケーションは適切に拡張されません。 WebSocketsを使用して、サーバーからクライアントに通知をプッシュします。
WebSocketの使用に関する潜在的な問題について：
1。 CDNの使用を検討してください
今日（ほぼ4年後）、Webスケーリングには、静的コンテンツ（html、css、js）だけでなく （JSON）アプリケーションデータ にも Content Delivery Network （CDN）フロントエンドの使用が含まれます。
もちろん、すべてのデータをCDNキャッシュに保存するわけではありませんが、実際には、多くの一般的なコンテンツは頻繁に変更されません。 80％のRESTリソースがキャッシュされている可能性があります...1分（または30秒）CDNの有効期限のタイムアウトは、中央サーバーに新しいライブを提供し、アプリケーションの応答性を大幅に向上させるのに十分な場合があります。CDNは地理的に調整できるためです...
私の知る限り、CDNにはWebSocketsのサポートはまだありません。 WebSocketはステートフルですが、HTTPはステートレスであるため、非常に簡単にキャッシュされます。実際、WebSocketsをCDNに対応させるには、ステートレスRESTfulアプローチに切り替える必要があります...これはWebSocketsではなくなります。
2。セキュリティの問題
WebSocketには、特にDOS攻撃に関する潜在的なセキュリティ問題があります。新しいセキュリティ脆弱性の説明については、 このスライドのセット および このwebkitチケット を参照してください。
WebSocketは、OSI 7アプリケーション層レベルでのパケット検査の機会を回避します。OSI7アプリケーション層レベルは、ビジネスセキュリティにおいて、今日ではかなり標準となっています。実際、WebSocketsは送信を難読化するため、セキュリティリークの重大な違反になる可能性があります。
このように考えてください：安価なもの、開いている接続を維持するもの、またはすべての要求に対して新しい接続を開くもの（ネゴシエーションのオーバーヘッドがあるため、TCPであることを思い出してください）
もちろんアプリケーションに依存しますが、長期のリアルタイム接続（例：AJAX chat）の場合、接続を開いたままにしておく方がはるかに良いです。
接続の最大数は、ソケットの空きポートの最大数によって制限されます。