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