どのような状況でAJAXロング/ショートポーリングがHTML5 WebSocketよりも好まれるでしょうか？
私は友達のための小さなチャットアプリケーションを構築していますが、手動でもページの更新を強制するのと同じくらい初歩的でもないタイムリーな方法で情報を取得する方法についてはよくわかりません。
現在、私は単純なAJAXを使用してこれを実装していますが、これには短いタイマーが経過したときに定期的にサーバーにアクセスするというデメリットがあります。
ロング/ショートポーリングを調査する際に、私はHTML5 WebSocketに出会いました。これは思われる簡単に実装できますが、隠れた欠点があるかどうかはわかりません。たとえば、WebSocketは特定のブラウザでのみサポートされていると思います。私が知っておくべきWebSocketの他の不利な点はありますか？
両方の技術が同じことをしているように思われるので、どのようなシナリオで一方が他方を使用するのを好むでしょうか。具体的には、HTML5 WebSocketはAJAXロング/ショートポーリングを廃止しましたか、それともWebSocketよりAJAXを好むべき説得力のある理由がありますか。
WebSocketsは間違いなく未来です。
ロングポーリングは、AJAXのように、リクエストごとに接続が作成されないようにするための厄介な回避策です - ただし、WebSocketが存在しないときにロングポーリングが作成されました。現在はWebSocketのおかげで、ロングポーリングはなくなりました。
WebRTCはピアツーピア通信を可能にします。
私は WebSockets を学ぶことを勧めます。
比較：
ウェブ上のさまざまなコミュニケーション手法
AJAX -
request→response。サーバーへの接続を作成し、オプションのデータと共に要求ヘッダーを送信し、サーバーから応答を取得して、接続を閉じます。 すべての主要ブラウザでサポートされています。ロングポール -
request→wait→response。 AJAXのようにサーバーへの接続を作成しますが、しばらくの間キープアライブ接続を開いたままにします（ただしそれほど長くはありません）。接続中に、オープンクライアントはサーバからデータを受信できます。タイムアウトまたはデータeofのために、接続が閉じられた後、クライアントは定期的に再接続する必要があります。サーバーサイドでは、それはAJAXと同じHTTPリクエストのように扱われますが、リクエストに対する回答はアプリケーションロジックによって定義された現在または将来的に発生するでしょう。 サポート表（フル）| ウィキペディアWebSockets -
client↔server。サーバーへのTCP接続を作成し、必要に応じて開いたままにします。サーバーまたはクライアントは簡単に接続を閉じることができます。クライアントはHTTP互換のハンドシェイクプロセスを通過します。成功すれば、サーバーとクライアントはいつでも双方向でデータを交換できます。アプリケーションが両方向で頻繁なデータ交換を必要とする場合は効率的です。 WebSocketには、クライアントからサーバーに送信される各メッセージのマスキングを含むデータフレーミングがあるため、データは単純に暗号化されています。 サポート表（とても良い） | ウィキペディアWebRTC -
peer↔peer。クライアント間の通信を確立するためのトランスポートはトランスポートに依存しないため、UDP、TCP、またはさらに抽象化されたレイヤを使用できます。これは一般に、信頼性が二次的であり、応答時間および少なくとも一部のデータ転送のために、数フレームまたは品質進行の低下を犠牲にすることができる、ビデオ／オーディオストリーミングなどの大容量データ転送に使用される。両側（ピア）は互いに独立してデータをプッシュできます。集中型サーバーから完全に独立して使用することはできますが、エンドポイントデータを交換する何らかの方法が依然として必要です。ほとんどの場合、開発者はピアを「リンク」するために集中型サーバーを使用します。これは、接続を確立するために不可欠なデータを交換するためにのみ必要です。その後、集中型サーバーは必要ありません。 サポート表（中） | ウィキペディアサーバー送信イベント -
client←server。クライアントはサーバーへの持続的かつ長期的な接続を確立します。サーバーだけがクライアントにデータを送信できます。クライアントがサーバーにデータを送信したい場合は、それを行うために別のテクノロジ/プロトコルを使用する必要があります。このプロトコルはHTTP互換であり、ほとんどのサーバーサイドプラットフォームで簡単に実装できます。これはLong Pollingの代わりに使用されるのが望ましいプロトコルです。 サポート表（IEを除く、良好） | ウィキペディア
利点：
WebSocketsサーバーサイドの主な利点は、それが（ハンドシェイク後の）HTTPリクエストではなく、適切なメッセージベースの通信プロトコルであるということです。これはあなたが莫大なパフォーマンスとアーキテクチャの利点を達成することを可能にします。たとえば、node.jsでは、異なるソケット接続で同じメモリを共有できるため、それぞれが共有変数にアクセスできます。そのため、データベースを途中で交換点として使用する必要はありません（AJAXやLong PollingをPHPのような言語で使用する場合のように）。データをRAMに保存することも、ソケット間で直接再公開することもできます。
セキュリティ上の考慮事項
人々はしばしばWebSocketのセキュリティを心配しています。現実には、ほとんど違いがないか、あるいはWebSocketをより良い選択肢としています。まず第一に、AJAXでは、各要求はインターネットインフラストラクチャを通過する新しいTCP接続であるため、 MITM の可能性が高くなります。 WebSocketでは、一度接続すると、データがクライアントからサーバーへストリーミングされるときのフレームマスキングの強化や、データのプローブにさらに手間がかかるため、途中で傍受するのははるかに困難です。 最近のプロトコルはすべてHTTPとHTTPS（暗号化）の両方をサポートしています。
P.S.
WebSocketは一般的にネットワーキングに関して非常に異なるロジックのアプローチを持っていることを忘れないでください。
省略した競合技術の1つは、Server-Sent Events/Event Sourceです。 ロングポーリング、Webソケット、サーバー送信イベント（SSE）、Cometとは何ですか？ これらすべてについての十分な議論があります。これらのいくつかは他のものよりもサーバー側で統合するのが簡単であることを覚えておいてください。
チャットアプリケーションや、サーバーと常に対話しているその他のアプリケーションの場合は、__ome_variable_name__が最適な選択肢です。ただし、WebSocketsname__はそれらをサポートするサーバーでしか使用できないため、必要なライブラリをインストールできない場合はWebSocketsname__を使用できなくなります。その場合は、同様の機能を得るためにLong Pollingを使用する必要があります。
XHRポーリングイベントが発生したときにリクエストに応答します（すぐに発生することも、遅れて発生することもあります）。それ以降のイベントでは、さらにイベントを受け取る必要があります。
ブラウザはサーバに非同期要求を出します。サーバは応答する前にデータが利用可能になるのを待ちます。応答には、クライアントによって実行されるエンコードされたデータ（通常はXMLまたはJSON）またはJavascriptを含めることができます。応答の処理が終了すると、ブラウザは別のXHRを作成して送信し、次のイベントを待ちます。このように、ブラウザは常に各サーバーで未処理の要求を保持し、各イベントが発生したときに応答します。 ウィキペディア
サーバー送信イベントクライアントがサーバーに要求を送信します。サーバーはいつでも新しいデータをWebページに送信します。
伝統的に、Webページは新しいデータを受け取るためにサーバに要求を送らなければなりません。つまり、ページはサーバーからデータを要求します。サーバー送信イベントでは、メッセージをWebページにプッシュすることで、サーバーがいつでも新しいデータをWebページに送信することができます。これらの着信メッセージは、Webページ内のイベント+データとして扱うことができます。 モジラ
WebSockets最初のハンドシェイク後（HTTPプロトコル経由）。通信はWebSocketプロトコルを使用して双方向に行われます。
ハンドシェイクはHTTPリクエスト/レスポンスから始まり、サーバーはHTTP接続と同じポート上のWebSocket接続を扱うことができます。接続が確立されると、通信はHTTPプロトコルに準拠していない双方向バイナリプロトコルに切り替わります。 ウィキペディア