私はしばらく WebSocket を使ってきましたが、大学の最終学年プロジェクトで Node サーバーと WebSocket を利用してアジャイル プロジェクト管理ツールを作成することにしました。WebSocket を使用すると、アプリケーションが処理できる 1 秒あたりのリクエスト数が 624% 増加することがわかりました。
しかし、プロジェクトを開始して以来、セキュリティ上の抜け穴や、一部のブラウザがデフォルトで WebSocket を無効にすることを選択していることを知りました。
このことから、次のような疑問が湧いてきます。
WebSocket はレイテンシとリソースのオーバーヘッドを大幅に削減できるように見えるのに、なぜ AJAX を使用するのでしょうか。AJAX が WebSocket よりも優れている点はあるのでしょうか。
ベストアンサー1
WebSocket は AJAX を置き換えることを意図したものではなく、厳密に言えば Comet/long-poll の置き換えでもありません (ただし、これが理にかなっている場合も多くあります)。
WebSocket の目的は、ブラウザとサーバーの間で、低遅延、双方向、全二重、長時間接続を実現することです。WebSocket により、HTTP や AJAX では実現できなかった新しいアプリケーション ドメインがブラウザ アプリケーションに開かれます (インタラクティブ ゲーム、ダイナミック メディア ストリーム、既存のネットワーク プロトコルへのブリッジなど)。
ただし、WebSocket と AJAX/Comet の目的には重複する部分があります。たとえば、ブラウザがサーバー イベント (プッシュなど) を通知する必要がある場合、Comet テクニックと WebSocket はどちらも実行可能なオプションです。アプリケーションで低レイテンシのプッシュ イベントが必要な場合は、これが WebSocket の有利な要因になります。一方、既存のフレームワークや導入済みのテクノロジ (OAuth、RESTful API、プロキシ、ロード バランサ) と共存する必要がある場合は、これが (現時点では) Comet テクニックの有利な要因になります。
WebSocket が提供する特定の利点が必要ない場合は、AJAX や Comet などの既存の技術に固執する方がよいでしょう。これにより、ツール、テクノロジ、セキュリティ メカニズム、ナレッジ ベース (つまり、stackoverflow では WebSocket よりも HTTP/Ajax/Comet を知っている人がはるかに多い) などの既存の巨大なエコシステムを再利用して統合できるためです。
一方、HTTP/Ajax/Comet の遅延と接続の制約内でうまく動作しない新しいアプリケーションを作成する場合は、WebSocket の使用を検討してください。
また、いくつかの回答では、WebSocket の欠点の 1 つとして、サーバーとブラウザーのサポートが限られている/混在していることが示されています。この点について少し説明しましょう。iOS (iPhone、iPad) は依然として古いプロトコル (Hixie) をサポートしていますが、ほとんどの WebSocket サーバーは Hixie と HyBi/ IETF 6455バージョンの両方をサポートしています。他のほとんどのプラットフォーム (組み込みサポートがない場合) は、web-socket-js (Flash ベースのポリフィル) を介して WebSocket サポートを取得できます。これにより、大多数の Web ユーザーがカバーされます。また、サーバーのバックエンドに Node を使用している場合は、 web-socket-js をフォールバックとして含むSocket.IOの使用を検討してください。それでも利用できない (または無効になっている) 場合は、特定のブラウザーで利用できる Comet テクニックにフォールバックします。
更新: iOS 6 は、現在の HyBi/IETF 6455 標準をサポートするようになりました。