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