1. ホーム
  2. html

[解決済み] HTML WebSocketは、各クライアントに対してオープンな接続を維持するのですか?これはスケールしますか?

2022-05-07 17:47:56

質問

HTML WebSocketsのスケーラビリティについて、どなたか情報をお持ちではないでしょうか。私が読んだ限りでは、すべてのクライアントがサーバーとのオープンな通信回線を維持するようです。私は、それがどのようにスケーリングされるのか、また、サーバーが処理できるオープンなWebSocket接続の数はどのくらいなのかを知りたいと思っています。これらの接続を開いたままにしておくことは、現実には問題ではないのかもしれませんが、そのように感じられます。

解決方法は?

ほとんどの場合、WebSocketはAJAX/HTMLリクエストよりも拡張性が高いでしょう。しかし、だからといって、WebSocketがAJAX/HTMLのすべての用途の代替になるわけではありません。

各TCP接続は、それ自体、サーバーのリソースをほとんど消費しません。接続のセットアップに費用がかかることはよくありますが、アイドル状態の接続を維持するのはほとんど無料です。通常遭遇する最初の制限は、同時に開くことができるファイル記述子の最大数です(ソケットはファイル記述子を消費します)。これはデフォルトで1024に設定されていることが多いですが、簡単にそれ以上に設定することができます。

何万もの同時AJAXクライアントをサポートするために、Webサーバーを構成しようとしたことがありますか?これらのクライアントを WebSocket クライアントに変更すれば、実現可能かもしれません。

HTTP接続は、オープンファイルを作成したり、ポート番号を長期間消費することはありませんが、他のあらゆる点でコストが高くなります。

  • 各HTTP接続は、クッキー、コンテンツタイプ、コンテンツ長、ユーザーエージェント、サーバーID、日付、last-modifiedなど、ほとんどの場合使用されない多くの荷物を運んでいます。WebSocket 接続が確立されると、アプリケーションで必要なデータのみが送受信される必要があります。

  • 通常、HTTPサーバーは、HTTPリクエストの開始と完了をログに記録するように設定されており、ディスクとCPUの時間を消費します。WebSockets のデータの開始と完了を記録することが標準になりますが、WebSockets 接続が二重転送を行っている間は、追加のログ記録オーバーヘッドが発生しません(そうするように設計されている場合はアプリケーション/サービスによる場合を除く)。

  • 通常、AJAXを使用する対話型アプリケーションは、連続的にポーリングするか、ある種のロングポーリングメカニズムを使用するかのどちらかです。WebSocket は、サーバーとクライアントが既存の接続を介して報告するものがあるときに互いに通知する、よりイベント性の高いモデルを行うための、よりクリーンな(そして低リソースの)方法です。

  • 実運用されている一般的なWebサーバーのほとんどは、HTTPリクエストを処理するためのプロセス(またはスレッド)のプールを備えています。各プロセス/スレッドは一度に1つのHTTPリクエストを処理するため、圧力が増加すると、プールのサイズが大きくなります。プロセスやスレッドを追加するたびに多くのメモリを使用し、新しいプロセスやスレッドを作成することは、新しいソケット接続の作成(プロセスやスレッドはまだそれを行う必要がある)よりもかなり高価です。一般的な WebSockets サーバーフレームワークのほとんどは、より良いスケールとパフォーマンスを実現する傾向のあるイベントルートを使用しています。

WebSocketsの主な利点は、インタラクティブなWebアプリケーションのための低遅延接続になります。HTTP AJAX/long-poll(アプリケーション/サーバーが適切に設計されていると仮定して)よりもスケールが良く、サーバーリソースの消費も少なくなりますが、現在の AJAX/Long-poll のオーバーヘッドと遅延では不可能な新しいクラスのウェブアプリケーションが可能になるため、IMO の低遅延は WebSockets の主要メリットとなります。

WebSocketsの規格がより完成され、より幅広いサポートが得られるようになれば、サーバーと頻繁に通信する必要がある、ほとんどの新しいインタラクティブなWebアプリケーションに使用することが理にかなっていると言えるでしょう。既存のインタラクティブなWebアプリケーションについては、現在のAJAX/ロングポールモデルがどの程度うまく機能しているかに依存します。変換のための労力は自明ではないので、多くの場合、そのコストは利点に見合わないでしょう。

更新情報 :

便利なリンク Node.jsを使ったAWSでの600k同時ウェブソケット接続