WebSocketが使用可能な場合にAJAXを使用する理由

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

ただし、プロジェクトを開始して以来、セキュリティの抜け穴や、デフォルトでWebSocketを無効にすることを選択しているブラウザを読んでいます。

これは私に質問を導きます：

WebSocketsがレイテンシとリソースオーバーヘッドを減らすというすばらしい仕事をしているように見えるのに、なぜAJAXを使用するのですか？AJAXがWebSocketsよりも優れている点はありますか？

WebSocketsはAJAXを置き換えることを意図しておらず、厳密にはComet / long-pollの代わりでさえありません（これが理にかなっている多くの場合があります）。

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

ただし、WebSocketsとAJAX / Cometの間には確かに目的の重複があります。たとえば、ブラウザがサーバーイベント（プッシュなど）の通知を必要とする場合、CometテクニックとWebSocketはどちらも実行可能なオプションです。アプリケーションが低レイテンシのプッシュイベントを必要とする場合、これはWebSocketを支持する要因になります。一方、既存のフレームワークやデプロイされたテクノロジー（OAuth、RESTful API、プロキシ、ロードバランサー）と共存する必要がある場合、これは（今のところ）コメットテクニックを支持する要因になります。

WebSocketsが提供する特定の利点が必要ない場合は、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ベースのポリフィル）を介してWebSocketsサポートを取得できます。これは、Webユーザーの大多数をカバーしています。また、サーバーのバックエンドにNodeを使用している場合は、フォールバックとしてweb-socket-jsを含むSocket.IOの使用を検討してください。これが利用できない（または無効になっている）場合でも、Cometの手法を使用するようにフォールバックします。指定されたブラウザで利用できます。

更新：iOS 6が現在のHyBi / IETF 6455標準をサポートするようになりました。

2017年12月まで早速、WebSocketは（実質的に）すべてのブラウザーでサポートされており、その使用は非常に一般的です。

ただし、これはWebSocketがAJAXを完全に置き換えることはできなかったことを意味しません。特に、HTTP / 2の適応が増加しているためです。

簡単に言えば、WebSocketを使用している場合でも、AJAXはほとんどのRESTアプリケーションに最適です。しかし、神は詳細にいるので...：

ポーリング用のAJAX？

ポーリング（またはロングポーリング）にAJAXを使用することはなくなりつつあります（実際にそうなるはずです）が、2つの理由（主に小規模なWebアプリ）のために引き続き使用されています。

1. 多くの開発者にとって、特にバックエンドのコーディングと設計に関しては、AJAXはコーディングが簡単です。

2. HTTP / 2を使用すると、AJAX（新しい接続の確立）に関連する最も高いコストが排除され、特にデータの投稿とアップロードに関して、AJAX呼び出しのパフォーマンスが向上しました。

ただし、WebSocketプッシュはAJAXよりもはるかに優れています（ヘッダーを再認証または再送信する必要はなく、「データなし」のラウンドトリップなども必要ありません）。これは何度も議論されました。

RESTのAJAX？

AJAXのより良い使用法はREST API呼び出しです。この使用により、コードベースが簡略化され、Websocket接続がブロックされるのを防ぎます（特に中規模のデータアップロードの場合）。

REST API呼び出しとデータのアップロードにAJAXを使用することには、多くの説得力のある理由があります。

1. AJAX APIは実質的にREST API呼び出し用に設計されており、非常に適しています。

2. AJAXを使用したREST呼び出しとアップロードは、クライアントとバックエンドの両方で、コーディングが非常に簡単です。

3. データペイロードが増加すると、メッセージの断片化/多重化ロジックがコーディングされていない限り、WebSocket接続がブロックされる可能性があります。

   アップロードが単一のWebsocket send呼び出しで実行される場合、アップロードが完了するまでWebsocketストリームをブロックする可能性があります。これにより、特に低速のクライアントではパフォーマンスが低下します。

一般的な設計では、Websocketを介して転送される小さなBidiメッセージを使用し、RESTおよびデータのアップロード（クライアントからサーバー）は、AJAXの使いやすさを利用してWebsocketのブロックを防ぎます。

ただし、大規模なプロジェクトでは、Websocketによって提供される柔軟性と、コードの複雑さとリソース管理のバランスがWebsocketを支持するバランスを傾けます。

たとえば、Websocketベースのアップロードでは、接続が切断されて再確立された後に大きなアップロードを再開する機能を提供できます（アップロードしたい5GBの映画を覚えていますか？）。

アップロードの断片化ロジックをコーディングすることで、中断されたアップロードを簡単に再開できます（難しい部分はコーディングされていました）。

HTTP / 2プッシュについてはどうですか？

おそらく、HTTP / 2プッシュ機能がWebsocketに取って代わらない（そしておそらくできない）ことを付け加えておきます。

これについては前に説明しましたが、単一のHTTP / 2接続がブラウザ全体（すべてのタブ/ウィンドウ）にサービスを提供するため、HTTP / 2によってプッシュされたデータは、どのタブ/ウィンドウに属しているかがわかりません。 Websocketの特定のブラウザタブ/ウィンドウにデータを直接プッシュする機能を置き換える容量を排除します。

Websocketは小さな双方向データ通信に最適ですが、AJAXには、特に大きなペイロード（アップロードなど）を検討する場合に、多くの利点があります。

そしてセキュリティ？

まあ、一般的に、プログラマーに提供される信頼と制御が多ければ多いほど、ツールは強力になり、セキュリティ上の懸念が高まります。

セキュリティはブラウザのコードに組み込まれているため、AJAXの方が有利です（これは問題になることもありますが、依然として存在します）。

一方、AJAX呼び出しは「中間者」攻撃の影響を受けやすくなりますが、Websocketのセキュリティ問題は、通常、アプリケーションコードのバグであり、セキュリティ上の欠陥がありました（通常、バックエンドの認証ロジックにあります）。

個人的には、これがそれほど大きな違いであるとは思いませんが、特にあなたが何をしているのかを知っている場合は、WebSocketの方が少し良いと思います。

私の謙虚な意見

私見、私はREST API呼び出し以外のすべてにWebsocketを使用します。可能な場合は、断片化してWebSocket経由で送信するビッグデータのアップロード。

ポーリング、私見は非合法である必要があります。ネットワークトラフィックのコストは恐ろしいものであり、Websocketプッシュは新しい開発者であっても管理するのに十分簡単です。

古いブラウザの問題（IE9を含み、WebSocketはIE10からサポートされる予定です）に加えて、透過プロキシ、リバースプロキシ、ロードバランサなど、まだWebSocketをサポートしていないネットワーク仲介者には大きな問題があります。WebSocketトラフィックを完全にブロックするモバイルキャリアがいくつかあります（つまり、HTTP UPGRADEコマンドの後）。

年月が経つにつれ、WebSocketはますますサポートされるようになりますが、それまでの間、ブラウザにデータを送信するためのHTTPベースのフォールバックメソッドが常に必要です。

私がWebソケットとセキュリティについて読んだ不満のほとんどは、Webブラウザセキュリティとファイアウォールセキュリティツールのセキュリティベンダーからのものです。問題は、HTTPからWebSocketバイナリプロトコルへのアップグレードが完了すると、パケットの内容とその意味がアプリケーション固有（プログラムに基づく）になるため、WebSocketトラフィックのセキュリティ分析の方法がわからないことです。これは明らかに、すべてのインターネットトラフィックの分析と分類に基づいて生計を立てている企業にとって、ロジスティックな悪夢です。:)

WebSocketは古いWebブラウザーでは機能せず、それをサポートするブラウザーは実装が異なる場合がよくあります。これが、AJAXの代わりに常に使用されていない唯一の良い理由です。

WebsocketとHTTPはライバルではなく、同じ問題を解決するものでもないため、明確な比較ができるとは思いません。

RESTは不定期の通信に最適であるのに対し、WebSocketは、長寿命の双方向データストリーミングをほぼリアルタイムで処理するのに最適です。websocketの使用はかなりの投資であるため、不定期の接続には過剰です。

高負荷が存在する場合、WebSocketの方が優れていることがあります。HTTPはキャッシュを利用できるため、場合によっては少し高速です。RESTとWebsocketの比較は、リンゴをオレンジと比較するようなものです。

どのアプリケーションがアプリケーションに最適なソリューションを提供しているかを確認する必要があります。

REST APIなどのWebsocketエンドポイントとクライアント上のWebsocketsなどのRESTfulエンドポイントを処理できるクライアントサイズのlib形式のHTTPとWebsocketの違いの例。 https://github.com/mikedeshazer/sockrest また、クライアントでWebsocket APIを使用しようとしている場合、またはその逆の場合も同様です。libs / sockrest.jsは、ほとんどの場合、違いを明確にします（または、そうすべきです）。