私はしばらくの間 WebSocket を使用してきましたが、ノード サーバーと WebSocket を利用して、大学での最終学年のプロジェクト用にアジャイル プロジェクト管理ツールを作成することにしました。WebSocket を使用すると、アプリケーションが処理できる 1 秒あたりのリクエスト数が 624% 増加することがわかりました。
ただし、プロジェクトを開始して以来、セキュリティの抜け穴や、一部のブラウザがデフォルトで WebSocket を無効にすることを選択していることを読みました..
これは私を質問に導きます：
WebSocket がレイテンシーとリソースのオーバーヘッドを大幅に削減しているように見えるのに、なぜ AJAX を使用するのでしょうか。
WebSockets は AJAX を置き換えることを意図したものではなく、Comet/long-poll を厳密に置き換えるものでもありません (ただし、これが理にかなっている場合はたくさんあります)。
WebSockets の目的は、ブラウザーとサーバー間で低レイテンシー、双方向、全二重、および長時間実行される接続を提供することです。WebSockets は、HTTP や AJAX (インタラクティブなゲーム、動的メディア ストリーム、既存のネットワーク プロトコルへのブリッジングなど) を使用して実際には実現できなかったブラウザ アプリケーションに新しいアプリケーション ドメインを提供します。
ただし、WebSocket と AJAX/Comet の間には、目的が重複していることは確かです。たとえば、ブラウザーがサーバー イベント (つまり、プッシュ) の通知を受け取る必要がある場合、Comet 手法と WebSocket の両方が確実に実行可能なオプションです。アプリケーションが低遅延のプッシュ イベントを必要とする場合、これは WebSocket を支持する要因になります。一方、既存のフレームワークおよびデプロイされたテクノロジー (OAuth、RESTful API、プロキシ、ロード バランサー) と共存する必要がある場合、これは (今のところ) Comet 手法を支持する要因になります。
WebSockets が提供する特定の利点が必要ない場合は、AJAX や Comet などの既存の手法に固執することをお勧めします。これにより、ツール、テクノロジ、セキュリティ メカニズムの既存の巨大なエコシステムを再利用して統合できるからです。 、ナレッジ ベース (つまり、stackoverflow のはるかに多くの人が WebSockets よりも HTTP/Ajax/Comet を知っています) など。
一方、HTTP/Ajax/Comet の待機時間と接続の制約内でうまく機能しない新しいアプリケーションを作成している場合は、WebSocket の使用を検討してください。
また、いくつかの回答は、WebSockets の欠点の 1 つは、サーバーとブラウザーのサポートが制限されている/混在していることを示しています。それを少し拡散させてください。iOS (iPhone、iPad) は依然として古いプロトコル (Hixie) をサポートしていますが、ほとんどの WebSocket サーバーは Hixie と HyBi/ IETF 6455バージョンの両方をサポートしています。他のほとんどのプラットフォーム (まだサポートが組み込まれていない場合) は、 web-socket-js (Flash ベースのポリフィル)を介して WebSockets サポートを取得できます。これは、Web ユーザーの大部分をカバーしています。また、サーバー バックエンドに Node を使用している場合は、フォールバックとして web-socket-js を含むSocket.IOを使用することを検討してください。それが利用できない (または無効になっている) 場合は、Comet 手法が何であれ使用するようにフォールバックします。特定のブラウザで使用できます。
更新: iOS 6 は、現在の HyBi/IETF 6455 標準をサポートするようになりました。
古いブラウザー (IE9 を含む。WebSocket は IE10 からサポートされる予定です) の問題に加えて、透過プロキシ、リバース プロキシ、ロード バランサーなど、まだ WebSocket をサポートしていないネットワーク仲介者には大きな問題があります。一部のモバイル キャリアでは、WebSocket トラフィックを完全にブロックしています (つまり、HTTP UPGRADE コマンドの後)。
年月が経つにつれて、WebSocket はますますサポートされるようになりますが、それまでの間、ブラウザにデータを送信するための HTTP ベースのフォールバック メソッドを常に用意する必要があります。
WebSocket は古い Web ブラウザーでは機能せず、サポートしている Web ブラウザーの実装は異なることがよくあります。これが、AJAX の代わりに常に使用されない唯一の正当な理由です。
Websocket と HTTP はライバルではなく、同じ問題を解決するものでもないため、両者を明確に比較することはできないと思います。
Websocket は、ほぼリアルタイムで長期の双方向データ ストリーミングを処理する場合に最適な選択肢ですが、REST は不定期の通信に最適です。Websocket の使用はかなりの投資になるため、不定期の接続にはやり過ぎです。
高負荷が存在する場合、Websocket の方が優れていることがわかる場合があります。キャッシュを利用できるため、場合によっては HTTP の方がわずかに高速です。REST と Websockets を比較することは、リンゴとオレンジを比較するようなものです。
どちらがアプリケーションにとってより良いソリューションを提供するかを確認する必要があり、ユースケースに最も適したソリューションが勝ちます。