ajaxが行う場所でwebsocket / socket.ioを使用することの欠点は何ですか？
同様の質問が以前に行われたことがあり、AJAXは廃止されないという結論に達しました。しかし、どのようにWebSocketよりAjaxが優れているのでしょうか？
Socket.ioを使用すると、フラッシュまたはロングポーリングに簡単にフォールバックできるため、ブラウザーの互換性は問題ではないようです。
WebSocketは双方向です。 ajaxが非同期リクエストを行う場合、websocketクライアントはサーバーにメッセージを送信します。 POST/GETパラメータはJSONでエンコードできます。
では、100％WebSocketを使用することの何が問題になっていますか？すべての訪問者がサーバーへの永続的なWebSocket接続を維持している場合、訪問セッション全体でいくつかのAjaxリクエストを行うよりも無駄になりますか？
もっと無駄になると思います。接続されているクライアントごとに、サーバー上にある1つのクライアントとペアになっているオブジェクト/関数/コードなどが必要です。ソケットハンドラー、またはファイル記述子、またはサーバーが接続を処理するように設定されている。
AJAXを使用すると、サーバー側のリソースからクライアントへの1：1マッピングは必要ありません。クライアントの数は、サーバー側のリソースよりも依存性が低くなる可能性があります。node.jsにも制限があります処理し、開いたままにできる接続の数。
考慮すべきもう1つのことは、特定のAJAX応答もキャッシュできることです。スケールアップするときに、頻繁な負荷を減らすためにHTTPキャッシュを追加できますAJAX =リクエスト。
短い答え
WebSocketをアクティブにしておくと、クライアントとサーバーの両方にコストがかかります。Ajaxで何をするかによって、Ajaxのコストは1回だけになるかどうかです。
長い回答
Webソケットは、「ねえ、Ajaxを使ってください、それで十分です！」という全体的な理由から誤解されることがよくあります。いいえ、WebSocketはAjaxの代わりにはなりません。それらは同じフィールドに適用できる可能性がありますが、Websocketの使用がばかげている場合があります。
簡単な例を見てみましょう：クライアント側でページが読み込まれた後にデータを読み込む動的ページ。簡単です。Ajax呼び出しを行います。サーバーからクライアントへの一方向のみが必要です。クライアントはこれらのデータを要求し、サーバーはそれらをクライアントに送信します。なぜあなたはそのようなタスクのためにwebsocketを実装するのですか？接続を常に開いておく必要はありません。クライアントがサーバーに常に問い合わせる必要はありません。サーバーがクライアントに通知する必要はありません。接続を開いたままにしておくと、リソースを浪費します。接続を開いたままにするには、常に確認する必要があるためです。
チャットアプリケーションでは、状況がまったく異なります。何か新しいものがある場合、クライアントにサーバーにx秒またはミリ秒ごとに問い合わせるのではなく、サーバーからクライアントに通知する必要があります。それは意味がありません。
よりよく理解するために、二人としてそれを見てください。 2つのうちの1つはサーバー、それ以上がクライアントです。 Ajaxは手紙を送るようなものです。クライアントは手紙を送り、サーバーは別の手紙で応答します。実際のところ、チャットアプリケーションの場合、会話は次のようになります。
「サーバーさん、私に何かをもらいましたか？
- 番号。
-ちょっとサーバー、私のために何かを得ましたか？
- 番号。
-ちょっとサーバー、私のために何かを得ましたか？
- はいこちらでございます。"
クライアントが回答を要求しなかった場合、サーバーは実際にクライアントに手紙を送ることができません。これはリソースの無駄遣いです。すべてのAjaxリクエストは、たとえそれがキャッシュされていても、サーバー側で操作を行う必要があるためです。
ここで、Ajaxでロードされたデータを使用して先に説明したケースです。クライアントがサーバーと電話をしていると想像してください。接続をアクティブに保つにはコストがかかります。それは電気代がかかり、あなたはあなたのオペレーターに支払う必要があります。さて、その人に3語だけ言ってもらいたいのであれば、なぜ誰かに電話して1時間電話をかけ続ける必要があるのでしょうか。くだらない手紙を送ってください。
結論として、WebSocketはAjaxの完全な代替品ではありません！
たまに必要 Ajax Websocketの使用がばかげている。
編集：SSEケース
そのテクノロジーはあまり広くは使用されていませんが、役立つ場合があります。その名前が示すように、サーバー送信イベントはサーバーからクライアントへの一方向のプッシュです。クライアントは何も要求せず、サーバーはデータを送信するだけです。
要するに ：
-クライアントからの単一方向：Ajax
-サーバーからの単一方向：SSE
-双方向：Webソケット
個人的には、AJAXの代わりにWebソケットがWebアプリケーションでますます使用されると思います。 Webサイトにはあまり適していませんが、キャッシングとSEOが大きな関心事ですが、Webアプリケーションには不思議です。
DNodeやsocketstreamなどのプロジェクトは、複雑さを取り除き、単純なRPCスタイルのコーディングを可能にします。つまり、クライアントコードはサーバー上の関数を呼び出すだけで、必要なデータをその関数に渡します。また、サーバーはクライアント上の関数を呼び出し、それにデータを渡すこともできます。 TCPの本質について気にする必要はありません。
さらに、AJAX呼び出しには多くのオーバーヘッドがあります。たとえば、接続を確立する必要があり、リクエストごとにHTTPヘッダー（Cookieなど）が渡されます。WebSocketはその多くを排除します。一部の人は、WebSocketの方が無駄であり、おそらく正しいと言いますが、その違いが本当にそれほど重要であるとは思いません。
関連するリソースへの多くのリンクを含む、別の関連する質問に詳細に回答しました。あなたはそれをチェックするかもしれません：
遅かれ早かれ、WebSocketベースのフレームワークは、Webアプリの一部のようなリアルタイムチャットを記述するためだけでなく、スタンドアロンのWebフレームワークとしてもポップアップし始めると思います。永続的な接続が作成されると、これを使用して、たとえばAJAX要求を介して現在提供されているWebアプリケーションのUI部分を含むあらゆる種類のものを受信できます。このアプローチは、何らかの方法でSEOに悪影響を与える可能性がありますが、冗長HTTPヘッダーを含む非同期リクエストによって生成されるトラフィックと負荷の量を減らすことができます。
ただし、永続的な接続が不要または不要なシナリオは多数あるため、WebSocketがAJAXに置き換わるか危険にさらされることはないと思います。たとえば、クライアントと永続的に接続する必要のない、単一目的のRESTベースのサービスを（1回）使用しているマッシュアップアプリケーション。
それについて「間違っている」ことは何もありません。
唯一の違いは主に読みやすさです。 Ajaxの主な利点は、ほとんどの機能が作成されているため、開発を迅速に行えることです。
ソケットを開くたびにホイールを作り直す必要がないことには大きな利点があります。
WS：//接続は、「AJAX」リクエストよりもはるかにオーバーヘッドが少ないです。
サーバーへの接続を開きたい場合、サーバーへの継続的なポーリングが存在する場合はソケットを使用し、それ以外の場合はajaxを使用することをお勧めします。
単純な類推：Ajaxはサーバーに質問（要求）を行い、サーバーはこれらの質問に回答（応答）を返します。継続的な質問をしたい場合、ajaxは機能しません。両端にリソースを必要とする大きなオーバーヘッドがあります。
他の人が言ったように、サーバーからクライアントへの通知が不要な場合や、クライアントからサーバーへのリクエストが低頻度で発生する場合、接続を開いたままにしておくのはやり過ぎになることがあります。
しかし、もう1つの欠点は、websocketが低レベルのプロトコルであり、最初のハンドシェイクが実行されるとTCPに追加の機能が提供されないことです。したがって、websocketで要求/応答パラダイムを実装する場合、おそらく見落とすでしょう- HTTP（非常に成熟した拡張プロトコルファミリー）が提供する機能、キャッシング（クライアントキャッシュと共有キャッシュ）、検証（条件付きリクエスト）、安全性とべき等（エージェントの動作に影響を与える）、範囲リクエストなど、コンテンツタイプ、ステータスコード、...
つまり、メッセージサイズを犠牲にして削減します。
だから私の選択はAJAXリクエスト-レスポンス、サーバープッシュ用のWebソケット、高頻度の低レイテンシーメッセージング用です