これはどちらかというと未熟な質問ですが、私はその答えを本当に知りませんでした。
では、なぜ websockets プロトコルが必要なのでしょうか?
また、HTTP のコメット スタイル/ロング ポール/ハンギング GET スタイルの使用よりも優れている点は何ですか?
これはどちらかというと未熟な質問ですが、私はその答えを本当に知りませんでした。
では、なぜ websockets プロトコルが必要なのでしょうか?
また、HTTP のコメット スタイル/ロング ポール/ハンギング GET スタイルの使用よりも優れている点は何ですか?
Comet と Ajax はどちらも、デスクトップに似た機能とユーザーが認識する低レイテンシーを提供するエンド ユーザー エクスペリエンスを提供できます。Web ソケットだけが、無視できるレイテンシーでブラウザーとの間でイベントを正確かつ効率的にストリーミングするためのネイティブな手段を提供するという約束を果たします。 .
ポーリングを使用すると、不要な要求が行われ、その結果、メッセージ レートが低い状況で、多くの接続が不必要に開かれたり閉じられたりします (ポーリングと同様に、定期的に HTTP 要求を送信し、すぐに応答を受信します)。
Web ソケットはオーバーヘッドを取り除き、複雑さを大幅に軽減します。
1-WebSocket は本来、全二重、双方向、単一ソケット接続です。WebSocket を使用すると、HTTP 要求は WebSocket 接続を開く単一の要求になり、クライアントからサーバーへ、およびサーバーからクライアントへの同じ接続を再利用します。
2-WebSocket によりレイテンシが短縮されます。たとえば、ポーリングとは異なり、WebSocket は単一の要求を行います。サーバーはクライアントからのリクエストを待つ必要はありません。同様に、クライアントはいつでもサーバーにメッセージを送信できます。メッセージが利用可能かどうかに関係なく、間隔を置いてリクエストを送信するポーリングよりも、この 1 つのリクエストでレイテンシが大幅に短縮されます。
3-WebSocket により、リアルタイム通信がはるかに効率的になります。HTTP を介して通知を受信するために、HTTP を介したポーリング (場合によってはストリーミングも) をいつでも使用できます。ただし、WebSocket は帯域幅、CPU パワー、レイテンシを節約します。WebSocket はパフォーマンスの革新です。
4-WebSocket は、その上に他の標準プロトコルを構築できるようにする、基盤となるネットワーク プロトコルです。
5-WebSocket は、他のプラットフォームと競合するために HTML5 アプリケーションに高度な機能を提供する取り組みの一環です。
6-WebSocket はシンプルさに関するものです
これは、websocket.org でのポーリングに対する websocket の利点に関する記事です。
それらが必要かどうかは明らかではありません。イベントをクライアントにプッシュするシナリオでは、ページは通常の AJAX GET 要求をループで作成でき、サーバーはイベントが利用可能になるまで「ハング」する可能性があります。一定のタイムアウトが経過すると、サーバーは「イベントなし」の応答を返すことができるため、クライアントは再接続します。接続が開いていてクライアントが応答を待っている間、サーバーからクライアントへの有効なプッシュ チャネルが存在します。
タイムアウト期間を調整して、不必要な再接続の量を減らすことができますが、ほとんどのサーバー フレームワークは、サーバー側プロセスが長時間ハングしたように見える場合にサーバー側プロセスを終了するため、通常は無限にすることはできません。
この既存の機能を考えると、問題は次のとおりです。新しい通信フレームワークは、既存のものよりも大きな価値を本当に追加しますか? できないことを本当に可能にするわけではありません。それはそれをわずかに改善するだけです。