server-sent-events - Forever-frame 和服务器发送的事件有什么区别？

Question

这个问题和这个问题真的很相似:What is the difference between web sockets, long polling, server-sent events and forever frame?

但是，这个问题的答案并没有提到 SSE 和 Forever-frame 之间的区别。
让我给你简要解释一下。

对于SSE，这个系统确实很像Comet，但与Comet不同的地方在于发送数据后不断开连接。
因此，从服务器到客户端的连接是长期存在的，并且客户端会收到整个数据的一系列片段。

另一方面，forever frame似乎和我很相似。在 Forever 框架中，客户端首先接收包含 iframe 标记的页面，在隐藏的 iframe 内建立长期连接。然后客户端从服务器接收分块数据，并在客户端已经拥有的第一个文档上使用一些函数操作 DOM。

我认为不同之处在于 Forever-frame 在机制中使用了 iframe 标签，但 SSE 没有，SSE 可以通过更多方式实现。
我对吗？

Answer 1

我以前从没听说过 Forever-frame 这个名字! (它在我的书“带有 HTML5 SSE 的数据推送应用程序”的“iframe”部分的第 7 章中有所介绍)。

长轮询:发出请求(使用 XMLHttpRequest，即 ajax)，保持打开状态，直到服务器上的数据准备就绪。然后套接字关闭。重新连接以获取下一位数据。

XHR 轮询:发出请求(使用 XMLHttpRequest2，即 ajax)，但监听 readyState==3 信号。后端服务器必须知道保持连接打开，客户端必须知道监听 readyState==3。 (在 IE9 及更早版本中不起作用，因为该浏览器从不传递 readyState==3 消息，而是直接进入 readyState==4)

iframe:向后端进程打开一个隐藏的 iframe。定期去看看 iframe 的源代码，看看有没有新的东西。 (从技术上讲，它适用于所有浏览器，但 IE8 和 IE9 是我(2013 年)测试中唯一具有足够低延迟以便更新有用的浏览器。)

上海证券交易所:一种 HTML5 标准，基本上类似于 XHR 轮询(至少 Firefox 和 Chrome，直接在 XMLHttpRequest2 之上实现它)，但对您隐藏了复杂的细节。如果套接字出现故障，它还添加了自动重新连接，以及其他一些类似的高级功能。

在上述书的第 7 章末尾，我展示了代码，使所有技术几乎可以在任何浏览器中工作。优先顺序是:

上证所(如有)

否则 XHR 如果可用

否则 iframe 如果 IE8 或 IE9

否则长轮询

还有一个区别:XHR 和 iframe 技术将整个消息历史存储在内存中。因此，如果您打算长时间保持套接字打开和/或发送大量大消息，这可能会导致 SSE 不会发生的内存问题。

执行摘要:不要担心“永久框架”，除非您有足够多的客户仍在使用 IE8/IE9，否则 longpoll 方法会在您的基础架构上产生明显的额外负载。