私はこの記事を読んでいました: http://blog.pusher.com/what-came-before-websockets / 、そして次のテキストが私の注意を引きます:
XHR ストリーミングはすべてのブラウザーで機能し、XMLHttpRequest オブジェクトの responseText は、接続が閉じられるまで増加し続けます。つまり、最終的に再接続を強制してこのバッファーをクリアする必要がありました。
私がこれを正しく理解していれば、バッファが特定のサイズ (ちなみに、実際のサイズは?) に達するたびに、接続がリセットされてこのバッファがクリアされるということですか? つまり、XHR ストリーミングは、このバッファーのサイズと同じくらい長生きしますか?
誰かがこれを確認してください。
XMLHttpRequest は、ストリーミング方式で使用するようには設計されていません。サーバーがさらにデータを送信する限り、ブラウザはそれをresponseTextXHR オブジェクトのフィールドに追加し続けます。
したがって、ストリーミングに XHR を使用する JS コードは、定期的に接続を切断して新しい接続を開く必要があるということであると確信しています。永遠に成長する文字列を再割り当てします。
つまり、この制限は、ブラウザーによって課せられる制限ではなく、許容できる長期パフォーマンスを実現するために実装する必要がある制限です。(ブラウザが課す応答サイズの上限もあるかもしれませんが、あるかどうかはわかりません。)
ストリーミングは XHR の拡張機能であり、受信したデータの一部を取得できます。それ以外の場合は、メッセージ全体が受信されるまで待たなければなりません。とにかく、まだ埋めるバッファがあります。実際には、いくつかのブラウザーでのみ機能します。いずれにしても、通常は Web ソケットの方が適しています。
通常の XHR を使用すると、送信するものがあるまでサーバーが何も送信しないロング ポーリング リクエストを行うことができます。何かを受信したら、クライアントにリクエストを再開させることができます。最適な条件の下では、そのリクエストを永遠に続けることができますが、その間の何かが接続を切断しないことを保証することはできません. そのため、通常、ロング ポーリングでは、クライアントに強制的に接続を更新させるために、一定時間 (5 分など) 後にサーバーにハートビートを送信させます。
実際には、Web サーバー、フロント エンド ロード バランサー、および ISP プロキシの接続の有効期間が最大になるため、接続はかなり早く終了します。これをモバイル ブラウザで使用する場合は、SSL を使用する必要があります。そうしないと、モバイル オペレータのプロキシがデータをバッファリングし、接続が終了したときにストリーミングではなく応答全体が得られなくなります。
ブラウザーには、累積された本文テキストの内部最大サイズがありますが、これは大きいため、ヒットする可能性は低くなります。この場合、xhr リクエストはエラーを発生させて終了します。
堅牢な再試行ロジックを使用してコードを実装します。これを単純な XHR で行うのではなく、HTML5 EventSource を使用することをお勧めします。XHR でストリーミングを行う方法の例として、EventSource の SHIM API ラッパーをいくつか検索することもできます。