3

ユーザーのリアルタイム更新を行うために、長いポーリングを使用してメッセージング システムを実装しています。そうすることで、Hotmail などの一部の Web サイトも xhr 要求を使用していることに気付きましたが、それらは私が実装したものとは少し異なっているようです。

図でわかるように、私の実装ではクライアントがリクエストを行い、サーバーは新しいデータ更新が利用可能になるまでリクエストを保持します。次に、ペイロードを送り返し、接続を閉じます。受信すると、javascript は新しい要求を Web サーバーに送信します。

Hotmail は代わりに、接続を開いたまま要求を送り返します。これはどのように可能ですか?? そして、どうすればこれを自分で実装できますか? そして最も重要なことは、違いは何ですか？

ありがとうございました。

ロングポール

4

3 に答える 3

1

ロングポーリングを使用するよりも良いアプローチがあると思います。WebSocket 接続を実装できます。これで、サーバーへの永続的な双方向接続が確立されます。WebSocket は HTTP に基づくアップグレード プロトコルであり、ロング ポーリングなどの「回避策」を回避するために構築されました。これについてもっと詳しく読みたい場合：

https://www.rfc-editor.org/rfc/rfc6455

http://www.html5rocks.com/en/tutorials/websockets/basics/

WebSocket を確立できない古いブラウザーをサポートしたい場合に備えて、フォールバックとしてロング ポーリングを自動的に使用する Dojox/Socket などを使用できます。

http://dojotoolkit.org/api/1.10/dojox/socket.html

https://www.sitepen.com/blog/2012/11/05/dojo-websocket-with-amd/

于 2015-10-10T18:24:43.443 に答える
1

最も一般的な双方向 HTTP メカニズムは 2 つあります。RFC6202「双方向 HTTP でロング ポーリングとストリーミングを使用するための既知の問題とベスト プラクティス」を参照してください。

  • HTTP ロング ポーリング: サーバーは、配信するイベントがある場合にのみ応答して、各 HTTP 要求を "開いたままにする" (すぐに応答しない) ことを試みます。このように、イベントの発生時にサーバーが応答できる保留中の要求が常に存在するため、メッセージ配信の待ち時間が最小限に抑えられます。

  • HTTP ストリーミング: サーバーはリクエストを無期限に開いたままにします。つまり、クライアントにデータをプッシュした後でも、要求を終了したり、接続を閉じたりすることはありません。

これらのアプローチの問題の詳細なリストは、RFC6202 にも記載されています。これらの方法にはそれぞれ長所と短所があります。

したがって、HTTP ストリーミング中に接続は終了しません。

HTTP ストリーミングを使用するアプリケーションの基本的なライフ サイクルは次のとおりです。

  1. クライアントは最初の要求を行い、応答を待ちます。

  2. サーバーは、更新が利用可能になるか、特定のステータスまたはタイムアウトが発生するまで、ポーリング要求への応答を延期します。

  3. 更新が利用可能になると、サーバーはそれを応答の一部としてクライアントに送り返します。

  4. サーバーによって送信されたデータは、要求または接続を終了しません。サーバーはステップ 3 に戻ります。

于 2015-10-10T17:24:52.953 に答える