1. ホーム
  2. ジャバスクリプト

[解決済み】どのような状況で、AJAXのロング/ショートポーリングがHTML5 WebSocketよりも好ましいですか?

2022-03-28 11:19:37

質問

私は友人のための小さなチャットアプリケーションを構築していますが、手動や強制的なページ更新のような初歩的なものではないタイムリーな方法で情報を取得する方法について不明です。

現在、単純なAJAXで実装していますが、短いタイマーが経過すると定期的にサーバーに負荷がかかるという欠点があります。

ロング/ショートポーリングについて調べているうちに、HTML5 WebSocketに行き当たりました。これは と思われる 簡単に実装できるのですが、何かデメリットが隠れているのでは?例えば、WebSocketは特定のブラウザにしか対応していないと思うのですが。他にもWebSocketには注意すべきデメリットがあるのでしょうか?

どちらの技術も同じことをするように思えますが、どのような場面でどちらを使うのがよいのでしょうか?より具体的には、HTML5 WebSocketはAJAXのロング/ショートポーリングを時代遅れにしたのでしょうか、それともWebSocketよりもAJAXを優先する説得力のある理由があるのでしょうか?

どのように解決するのですか?

WebSocketsは <ストライク 間違いなく未来 今

ロングポーリングは、AJAXのようにリクエストごとにコネクションを作成するのを防ぐための汚い回避策です - しかし、ロングポーリングはWebSocketが存在しなかったときに作成されました。今はWebSocketのおかげで ロングポーリングは <ストライク 消える はもうない。

WebRTCは、ピアツーピア通信を可能にします。

学習することをお勧めします ウェブソケット .

比較する。

ウェブ上のさまざまなコミュニケーション手法の

  • AJAX - requestresponse . サーバーへの接続を作成し、オプションのデータを含むリクエストヘッダを送信し、サーバーから応答を取得し、接続を閉じます。 主要なブラウザでサポートされています。

  • ロングポール - requestwaitresponse . AJAXが行うようにサーバーへの接続を作成しますが、キープアライブ接続をしばらく開いたままにします(長くはありませんが)。接続中、開いているクライアントはサーバーからデータを受け取ることができます。タイムアウトやデータの消失により接続を閉じた後、クライアントは定期的に再接続しなければなりません。サーバー側では、HTTPリクエストのように扱われ、AJAXと同じです。ただし、リクエストに対する応答は、アプリケーションロジックによって定義された、現在または将来のある時点で発生します。 サポートチャート(全文) | ウィキペディア

  • ウェブソケット - clientserver . サーバーへのTCPコネクションを作成し、必要なだけオープンにしておく。サーバーまたはクライアントは、簡単に接続を閉じることができます。クライアントは、HTTP互換のハンドシェイクプロセスを通過します。それが成功すれば、サーバーとクライアントはいつでも双方向にデータを交換することができる。アプリケーションで頻繁に双方向のデータ交換が必要な場合、効率的です。WebSocketは、クライアントからサーバーに送信される各メッセージのマスキングを含むデータフレームワークを持っているので、データは単に暗号化されます。 サポートチャート(非常に良い) | ウィキペディア

  • WebRTC - peerpeer . クライアント間の通信を確立するためのトランスポートで、トランスポートにとらわれないため、UDP、TCP、あるいはもっと抽象的なレイヤーを使用することができます。これは一般的に、ビデオ/オーディオストリーミングのような大容量のデータ転送に使用され、信頼性は二の次で、応答時間と少なくとも一部のデータ転送を優先して、数フレームや品質進歩の低下を犠牲にすることができます。双方(ピア)は独立してデータをプッシュし合うことができる。集中管理されたサーバーから完全に独立して使用することができますが、それでもエンドポイントのデータを交換する何らかの方法が必要であり、ほとんどの場合、開発者は集中管理されたサーバーを使用してピアをリンクさせます。これは、接続を確立するための必須データを交換するためにのみ必要で、それ以降は集中型サーバーは必要ありません。 サポートチャート(中) | ウィキペディア

  • サーバーから送信されるイベント - clientserver . クライアントはサーバーとの間で持続的かつ長期的な接続を確立する。サーバーだけがクライアントにデータを送ることができる。クライアントがサーバにデータを送信したい場合は、別の技術/プロトコルを使用する必要があります。このプロトコルはHTTPと互換性があり、ほとんどのサーバー側プラットフォームで簡単に実装することができます。Long Pollingの代わりに使用するのが望ましいプロトコルです。 サポートチャート(IE以外良好) | ウィキペディア

メリット

の主な利点は、以下のとおりです。 ウェブソケット サーバーサイドで、HTTPリクエスト(ハンドシェイク後)ではなく、適切なメッセージベースの通信プロトコルであることです。これは これにより、パフォーマンスとアーキテクチャの面で大きな利点を得ることができます。 . 例えば、node.jsでは、異なるソケット接続で同じメモリを共有できるので、それぞれが共有変数にアクセスすることができます。そのため、AJAXやPHPのような言語でのLong Pollingのように、途中の交換ポイントとしてデータベースを使用する必要がありません。 RAMにデータを保存したり、ソケット間ですぐにリパブリッシュすることも可能です。

セキュリティに関する考察

WebSocketのセキュリティについて心配されることがよくあります。現実には、ほとんど違いはなく、むしろWebSocketの方が優れているとさえ言えます。まず第一に、AJAXでは、以下の可能性が高くなります。 マイトム リクエストのたびに新しいTCP接続が発生し、インターネットのインフラを通過することになるからです。WebSocket では、一度接続されると、その間の傍受ははるかに困難です。データがクライアントからサーバーにストリーミングされる際にフレームマスクが追加で適用され、さらに圧縮も行われるため、データを調べるのにもっと労力が必要になります。 最近のプロトコルはすべて、その両方をサポートしています。HTTP と HTTPS(暗号化)の両方をサポートしています。

追伸

WebSocketは一般的に、ネットワークのためのロジックが非常に異なるアプローチであることを覚えておいてください。 リアルタイムゲームのようなものであり、httpのようなものではありません。