問題タブ [forever-frame]

私は SignalR の使い方を学んでいますが、これまでのところ成功しています。ハブを実装したり、ビジネス ロジックを実装したり、必要なサーバーからクライアント側関数を呼び出したり、クライアント側からサーバー側メソッドを呼び出したりできます。これは素晴らしいことです。私を困惑させているのは理論です。

実際、このビデオから情報を収集しました。SignalR は、単一のTCP接続を介して全二重チャネルを提供するWebSocketsを使用しています。利用可能な WebSocket がない場合、フォールバック プロトコルはEventSourceになります。それが利用できない場合は、Forever Frame が使用されます。それが利用できない場合は、ロング ポーリングが使用されます。永遠のフレームのような非常にハックなソリューションが古い慣習よりも好まれるのは私にとってかなり奇妙であり、3番目のオプションとして永遠のフレームを持ち、4番目のオプションとしてポーリングするというSignalRの決定の背後にある理論的根拠に興味があります。

私はこの質問に対する答えを見つけようとしましたが、長いポーリングの場合、永遠のフレームと比較して 3 倍の最大待ち時間があると噂されていることがわかりました。これは事実ですか? もしそうなら、それはすべてのブラウザの事実ですか、それともサブセットの事実ですか?

この質問は、次の質問とよく似ています: Web ソケット、ロング ポーリング、サーバー送信イベント、永久フレームの違いは何ですか?

ただし、この質問の回答では、SSE と Forever-frame の違いについては言及されていません。
それらについて簡単に説明します。

SSEに関しては、システムはCometと非常に似ていますが、Cometと異なる点は、データが送信された後に接続が切断されないことです。そのため、サーバーからクライアントへの接続は長続きし、クライアントはデータ全体の一連のフラグメントを受信します。

一方でフォーエバーフレームは自分にとても似ているようです。Forever フレームでは、最初にクライアントが iframe タグを含むページを受け取り、非表示の iframe 内で長期間接続を確立します。次に、クライアントはサーバーからチャンク データを受信し、クライアントが既に持っている最初のドキュメントに対していくつかの関数を使用して DOM を操作します。

Forever-frame はメカニズムに iframe タグを使用しますが、SSE は iframe タグを使用せず、より多くの方法で SSE を実現できるという違いがあると思います。私は正しいですか？

HTTP ストリーミングを使用した WebSocket フォールバックでXmlHttpRequest#responseTextは、変更のたびに呼び出されるreadystate(そして >= 3) ことがわかります。

WHATWGの生活水準によると、テキスト応答は

...decodeフォールバック エンコーディング文字セットを使用して受信したバイトを実行した結果。

このような変更のたびに、HTTP ストリーミングのリクエスト以降に受信したデータをすべてUTF-16 にエンコードした結果に対応するサイズの新しい文字列が作成されるということだと思います。readystate

毎秒約 5 つのメッセージがクライアントに着信するこの手法を使用すると、JavaScript ヒープで大量のメモリ チャーンが定期的に (つまり、HTTP ストリーミング応答バッファが大きくなる期間 - 定期的にリセットされる) 観察されました。上記のアプローチにリンクされています。

これは合理的な分析に聞こえますか?

この HTTP ストリーミング手法のメモリ サブシステムへの影響を軽減する手法を見つけた人はいますか (たとえば、各 HTTP ストリーミング接続の寿命を短くするなど)?