WebSocketsが利用可能なときにAJAXを使用する理由
私はしばらくの間WebSocketsを使用していますが、NodeサーバーとWebSocketsを利用して、大学での最終年度プロジェクト用のアジャイルプロジェクト管理ツールを作成することを選択しました。 WebSocketsを使用すると、アプリケーションが処理できる1秒あたりのリクエスト数が624％増加することがわかりました。
しかし、プロジェクトを開始して以来、セキュリティの抜け穴と、デフォルトでWebSocketを無効にすることを選択している一部のブラウザーについて読みました。
これは私を質問に導きます：
WebSocketsがレイテンシとリソースのオーバーヘッドを下げるという非常に優れた仕事をしているように思えるときにAJAXを使用する理由は、AJAXがWebSocketsよりも優れていることはありますか？
WebSocketsはAJAXを置き換えることを意図しておらず、Comet/long-pollの厳密な置き換えでさえありません（これは理にかなっている場合が多くありますが）。
WebSocketの目的は、ブラウザーとサーバー間の低遅延、双方向、全二重、および長時間の接続を提供することです。 WebSocketsは、HTTPおよびAJAX（インタラクティブゲーム、動的メディアストリーム、既存のネットワークプロトコルへのブリッジなど）を使用して実際には不可能だったブラウザーアプリケーションに対して新しいアプリケーションドメインを開きます。
ただし、WebSocketとAJAX/Cometの目的には確かに重複があります。たとえば、ブラウザにサーバーイベント（つまり、プッシュ）の通知を希望する場合、CometテクニックとWebSocketは確かに実行可能なオプションです。アプリケーションで低レイテンシのプッシュイベントが必要な場合、これはWebSocketを支持する要因になります。一方、既存のフレームワークとデプロイされたテクノロジー（OAuth、RESTful API、プロキシ、ロードバランサー）と共存する必要がある場合、これはCometテクニック（今のところ）を支持する要因になります。
WebSocketsが提供する特定の利点が必要ない場合は、AJAXやCometのような既存の手法に固執することをお勧めします。これにより、ツール、テクノロジー、セキュリティメカニズム、ナレッジベース（つまり、WebSocketsよりもはるかに多くの人々が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テクニックを使用するようにフォールバックします。
Update：iOS 6は現在のHyBi/IETF 6455標準をサポートしています。
2017年12月に早送りします Websocketは（実際に）すべてのブラウザーでサポートされます で、その使用は非常に一般的です。
ただし、これは、特にHTTP/2の適応が増加しているため、Websocketsが少なくとも完全ではないがAJAXに取って代わったことを意味するものではありません。
簡単な答えは、AJAXは、Websocketを使用している場合でも、ほとんどのRESTアプリケーションにとって依然として優れているということです。しかし、神は詳細にあるので...：
ポーリング用のAJAX？
ポーリング（または長いポーリング）でのAJAXの使用はなくなりつつあります （そうする必要があります）が、2つの正当な理由で使用され続けています（主に小さなWebアプリの場合） ）：
多くの開発者にとって、特にバックエンドのコーディングと設計に関しては、AJAXはコーディングが簡単です。
HTTP/2では、AJAX（新しい接続の確立）に関連する最高コストが排除され、AJAX呼び出しが特にデータの投稿とアップロードに対して非常にパフォーマンスが向上しました。
ただし、 Websocket PushはAJAXよりもはるかに優れています （ヘッダーを再認証または再送信する必要はありません。「データなし」の往復は不要です）。これ 議論された 何度も。
REST用のAJAX？
AJAXのより良い使用法は、REST API呼び出しです。この使用により、コードベースが簡素化され、Websocket接続がブロックされるのを防ぎます（特に中規模のデータアップロードの場合）。
多くの AJAX API呼び出しにRESTを好む理由 とデータのアップロードがあります：
AJAX APIはREST API呼び出し用に実際に設計されており、最適です。
AJAXを使用したREST呼び出しとアップロードは、クライアントとバックエンドの両方でコーディングが非常に簡単です。
データペイロードが増加すると、メッセージの断片化/多重化ロジックがコーディングされていない限り、Websocket接続がブロックされる可能性があります。
単一のWebsocket
send呼び出しでアップロードが実行されると、アップロードが完了するまでWebsocketストリームがブロックされる可能性があります。これにより、特に低速のクライアントでパフォーマンスが低下します。
一般的な設計では、RESTおよびデータアップロード（クライアントからサーバー）がAJAXの使いやすさを活用してWebsocketのブロックを防止する一方で、Websocket経由で転送される小さなbidiメッセージを使用します。
ただし、大規模なプロジェクトでは、Websocketが提供する柔軟性と、コードの複雑さとリソース管理のバランスにより、Websocketが有利になります。
たとえば、Websocketベースのアップロードでは、接続が切断されて再確立された後に大規模なアップロードを再開する機能を提供できます（アップロードしたい5GBの映画を覚えていますか？）。
アップロードの断片化ロジックをコーディングすることで、中断したアップロードを簡単に再開できます（難しい部分はコーディングしていました）。
HTTP/2プッシュはどうですか？
おそらく、HTTP/2プッシュ機能はWebsocketに代わるものではない（おそらく代用できない）ことを付け加える必要があります。
これは ここで説明 でしたが、単一のHTTP/2接続がブラウザ全体（すべてのタブ/ウィンドウ）に対応しているため、HTTP/2によってプッシュされるデータは、タブ/ウィンドウが属しているため、特定のブラウザのタブ/ウィンドウにデータを直接プッシュするWebsocketの機能を置き換えることができません。
Websocketは小さな双方向データ通信に最適ですが、AJAXはまだ多くの利点をもたらしました-特に大きなペイロード（アップロードなど）を検討する場合。
そしてセキュリティ？
まあ、一般的に、プログラマーに信頼と制御が提供されるほど、ツールはより強力になります...そして、忍び寄るセキュリティ上の懸念が増えます。
AJAXのセキュリティはブラウザのコードに組み込まれているため（本来は疑わしい場合もありますが、依然として存在しているため）、本来AJAXが優勢になります。
一方、AJAX呼び出しは「中間者」攻撃を受けやすくなりますが、Websocketのセキュリティ問題は通常、セキュリティ上の欠陥を導入したアプリケーションコードのバグです（通常、バックエンド認証ロジックはこれらを見つけます）。
個人的には、特にあなたが何をしているのかを知っているとき、Websocketsがわずかに優れていると思うなら、これはそれほど大きな違いではないと思います。
私の謙虚な意見
私見、REST API呼び出し以外のすべてにWebsocketを使用します。ビッグデータのアップロード可能であれば、断片化してWebsocket経由で送信します。
ポーリング（IMHO）は禁止されるべきであり、ネットワークトラフィックのコストは恐ろしく、Websocket Pushは新しい開発者にとっても管理が容易です。
古いブラウザの問題（IE10からWebSocketがサポートされるためIE9を含む）に加えて、透過プロキシ、リバースプロキシ、ロードバランサなど、WebSocketをまだサポートしていないネットワーク仲介者には大きな問題が残っています。 WebSocketトラフィックを完全にブロックする（つまり、HTTP UPGRADEコマンドの後）モバイルキャリアがいくつかあります。
数年が経過すると、WebSocketはますますサポートされるようになりますが、当面は、ブラウザーにデータを送信するためのHTTPベースのフォールバックメソッドを常に用意する必要があります。
私がウェブソケットとセキュリティについて読んだ不満のほとんどは、ウェブブラウザのセキュリティとファイアウォールのセキュリティツールのセキュリティベンダーからのものです。問題は、Websocketトラフィックのセキュリティ分析を行う方法を知らないことです。HTTPからwebsocketバイナリプロトコルへのアップグレードが完了すると、パケットの内容とその意味はアプリケーション固有（プログラムに基づいて）になります。これは明らかに、すべてのインターネットトラフィックの分析と分類に基づいて生計を立てているこれらの企業にとって、ロジスティックの悪夢です。 :)
WebSocketは古いWebブラウザーでは機能せず、 それをサポートするもの はしばしば異なる実装を持っています。これが、AJAXの代わりに常に使用されない唯一の正当な理由です。
WebsocketとHTTPは、ライバルでもなければ、同じ問題を解決するものでもないので、明確に比較できるとは思いません。
RESTは時折の通信に最適ですが、Websocketは、ほぼリアルタイムで長寿命の双方向データストリーミングを処理するのに最適な選択肢です。 websocketの使用はかなりの投資であるため、ときどき接続するのはやり過ぎです。
Websocketsは、高負荷が存在する場合にパフォーマンスが向上する場合があります。HTTPは、キャッシングを利用できるため、場合によってはわずかに高速になります。 RESTをWebsocketと比較することは、リンゴとオレンジを比較するようなものです。
アプリケーションに適したソリューションを提供し、ユースケースに最も適しているソリューションを確認する必要があります。
REST APIのようなWebsocketエンドポイントと、クライアント上のWebsocketのようなRESTfulエンドポイントを処理できるクライアントサイズのライブラリの形式でのHTTPとWebsocketの違いの例。 https://github.com/mikedeshazer/sockrest また、クライアントでwebsocket APIを使用しようとしている人、またはその逆を使用する場合。 libs/sockrest.jsを使用すると、違いが明確になります（むしろそうなるはずです）。