[解決済み】WebSocketが使えるのに、なぜAJAXを使うのか？

質問

私は、大学の最終学年のプロジェクトで、NodeサーバーとWebSocketを利用して、アジャイルプロジェクト管理ツールを作成することにしました。WebSocketsを使用することで、私のアプリケーションが処理できる1秒あたりのリクエスト数が624%増加することがわかりました。

しかし、このプロジェクトを始めてから、セキュリティの抜け穴や、一部のブラウザがデフォルトでWebSocketを無効にしていることを知りました...。

という疑問が湧いてきます。

WebSocketはレイテンシーとリソースのオーバーヘッドを減らすのに素晴らしい仕事をしているように見えるのに、なぜAJAXを使うのですか？

どのように解決するのですか？

WebSocketsはAJAXを置き換えるためのものではなく、厳密にはComet/long-pollの置き換えでもありません（ただし、これが意味を持つケースはたくさんあります）。

WebSocketsの目的は、ブラウザとサーバーの間に、低遅延の双方向全二重長時間接続を提供することです。WebSockets は、HTTP や AJAX を使用しても実際には不可能だった新しいアプリケーション領域をブラウザアプリケーションに開放します（インタラクティブゲーム、動的メディアストリーム、既存のネットワークプロトコルへのブリッジングなど）。

しかし、WebSocketsとAJAX/Cometの間には、確かに目的が重なる部分があります。たとえば、ブラウザがサーバーイベントの通知を受けたい場合（つまり、プッシュ）、Comet技術とWebSocketは確かに両方実行可能なオプションです。アプリケーションが低遅延のプッシュイベントを必要とする場合、これはWebSocketを支持する要因になります。一方、既存のフレームワークや配備された技術（OAuth、RESTful API、プロキシ、ロードバランサー）と共存する必要がある場合は、（今のところ）Comet技術を支持する要因になるでしょう。

WebSocketsが提供する特定の利点を必要としない場合、AJAXやCometのような既存の技術に固執する方がおそらく良いアイデアです。これは、ツール、技術、セキュリティメカニズム、知識ベース（つまり、stackoverflowではWebSocketsよりもHTTP/Ajax/Cometを知っている人がはるかに多い）などの既存の巨大エコシステムと再利用および統合できるようになるためです。

一方、HTTP/Ajax/Cometのレイテンシーと接続の制約の中でうまく動作しない新しいアプリケーションを作成している場合は、WebSocketの使用を検討する必要があります。

また、WebSocketsの欠点として、サーバーとブラウザのサポートが限定的/混在していることを指摘する回答もあります。それを少し拡散させてください。iOS（iPhone、iPad）はまだ古いプロトコル（Hixie）をサポートしていますが、ほとんどのWebSocketsサーバーはHixieとHyBi/の両方をサポートしています。 IETF 6455 バージョンです。他のほとんどのプラットフォームでは、（まだサポートが組み込まれていない場合）WebSockets のサポートを得るには、次のようにします。 web-socket-js (Flashベースのポリフィル)。これはウェブユーザーの大半をカバーしています。また、サーバーのバックエンドにNodeを使っている場合は ソケット.IO これは、フォールバックとして web-socket-js を含み、それさえも利用できない（または無効）場合、与えられたブラウザで利用可能なあらゆるコメット技術を使用することにフォールバックします。

更新情報 : iOS 6 が現在の HyBi/IETF 6455 標準に対応しました。