フォーエバーフレームという名前は聞いたことがありません!(これは、私の著書 Data Push Apps with HTML5 SSE の「iframe」セクションの第 7 章で説明されています)。
ロング ポーリング: (XMLHttpRequest、つまり ajax を使用して) 要求を行い、データがサーバー上で準備できるまで開いたままにします。その後、ソケットが閉じます。データの次のビットを取得するために再接続します。
XHR ポーリング: (XMLHttpRequest2、つまり ajax を使用して) 要求を行いますが、readyState==3 シグナルをリッスンします。バックエンド サーバーは接続を開いたままにしておく必要があり、クライアントは readyState==3 をリッスンする必要があります。(IE9 以前では動作しません。そのブラウザーは readyState==3 メッセージを配信せず、readyState==4 に直接進むためです)
iframe:バックエンド プロセスに対して非表示の iframe を開きます。定期的に iframe のソース コードを調べて、何か新しいものがないか確認してください。(技術的にはすべてのブラウザーで動作しますが、IE8 と IE9 だけが、私の (2013) のテストでは、アップデートが有用であるのに十分なほど低いレイテンシーを備えていました。)
SSE:基本的に XHR ポーリングのように機能する HTML5 標準 (少なくとも Firefox と Chrome では、XMLHttpRequest2 の上に直接実装されています) が、複雑な詳細が隠されています。また、ソケットがダウンした場合の自動再接続、およびそのような他のいくつかの高レベル機能も追加します。
前述の本の第 7 章の最後に、ほぼすべてのブラウザーで機能するすべての手法を取得するためのコードを示します。優先順位は次のとおりです。
- 利用可能な場合は SSE
- それ以外の場合は XHR
- IE8 または IE9 の場合は iframe
- そうでなければロングポール
もう 1 つ違いがあります。XHR と iframe の手法では、メッセージ履歴全体がメモリに保存されます。そのため、ソケットを長時間開いたままにしたり、大量の大きなメッセージを送信したりする場合は、SSE では発生しないメモリの問題が発生する可能性があります。
エグゼクティブ サマリー: IE8/IE9 をまだ使用している顧客が十分にいて、ロングポール アプローチによってインフラストラクチャに顕著な追加負荷が発生しない限り、「永久フレーム」について心配する必要はありません。