Forever-frame 和服务器发送的事件有什么区别?
What is the difference between Forever-frame and server sent events?
这个问题和这个问题很相似:What is the difference between web sockets, long polling, server-sent events and forever frame?
但是这个问题的答案没有提到SSE和Forever-frame的区别
让我给你简单的解释一下。
关于SSE,这个系统确实很像Comet,但与Comet不同的一点是发送数据后不断开连接。
因此,从服务器到客户端的连接是长期有效的,并且客户端接收到整个数据的一系列片段。
另一方面,forever frame好像和我很像。在 Forever frame 中,首先客户端收到包含 iframe 标签的页面,在隐藏的 iframe 中建立长期连接。然后客户端从服务器接收分块数据,并在客户端已有的第一个文档上使用一些函数操作 DOM。
我假设不同之处在于Forever-frame在机制中使用了iframe标签,而SSE没有,SSE可以通过更多方式实现。
我说得对吗?
我以前从未听说过 Forever-frame 这个名字! (它在我的书的第 7 章中有介绍,Data Push Apps with HTML5 SSE,在 "iframe" 部分)。
长轮询:发出请求(使用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(如果可用)
- else XHR(如果可用)
- else iframe 如果 IE8 或 IE9
- else longpoll
还有一个区别:XHR 和 iframe 技术将整个消息历史记录存储在内存中。因此,如果您打算长时间保持套接字打开 and/or 发送大量大消息,这可能会导致 SSE 不会发生的内存问题。
执行摘要:不要担心 "forever-frame" 除非您有足够多的客户仍在使用 IE8/IE9 长轮询方法会给您的基础架构带来明显的额外负载。
由于缺乏浏览器支持,SSE 并不是一个真正的选择,所以您的问题的答案是....
I assume the difference is Forever-frame uses iframe tag in the
mechanism, but SSE doesn't and SSE can be realized by more ways
没有。
iframe实际上是最容易实现的,开销也最少。唯一的缺点是随着时间的推移内存使用。
XHR 非常干净高效,但有一些 IE 版本限制。如果您的用户仍在使用这些版本的 IE,他们可能不会对具有实时消息传递的应用程序有任何用处:)
你总是可以使用:
<script>
window.setTimeout(poll, 3000);
function poll() {
$.ajax({
url: "/",
type: "POST",
data: {},
dataType: "json",
traditional: true,
contentType: "application/json; charset=utf-8",
success: function (data) {
// do something
},
error: function () {
// handle it
},
complete: function() {
window.setTimeout(poll, 3000);
}
});
}
这个问题和这个问题很相似:What is the difference between web sockets, long polling, server-sent events and forever frame?
但是这个问题的答案没有提到SSE和Forever-frame的区别
让我给你简单的解释一下。
关于SSE,这个系统确实很像Comet,但与Comet不同的一点是发送数据后不断开连接。 因此,从服务器到客户端的连接是长期有效的,并且客户端接收到整个数据的一系列片段。
另一方面,forever frame好像和我很像。在 Forever frame 中,首先客户端收到包含 iframe 标签的页面,在隐藏的 iframe 中建立长期连接。然后客户端从服务器接收分块数据,并在客户端已有的第一个文档上使用一些函数操作 DOM。
我假设不同之处在于Forever-frame在机制中使用了iframe标签,而SSE没有,SSE可以通过更多方式实现。 我说得对吗?
我以前从未听说过 Forever-frame 这个名字! (它在我的书的第 7 章中有介绍,Data Push Apps with HTML5 SSE,在 "iframe" 部分)。
长轮询:发出请求(使用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(如果可用)
- else XHR(如果可用)
- else iframe 如果 IE8 或 IE9
- else longpoll
还有一个区别:XHR 和 iframe 技术将整个消息历史记录存储在内存中。因此,如果您打算长时间保持套接字打开 and/or 发送大量大消息,这可能会导致 SSE 不会发生的内存问题。
执行摘要:不要担心 "forever-frame" 除非您有足够多的客户仍在使用 IE8/IE9 长轮询方法会给您的基础架构带来明显的额外负载。
由于缺乏浏览器支持,SSE 并不是一个真正的选择,所以您的问题的答案是....
I assume the difference is Forever-frame uses iframe tag in the mechanism, but SSE doesn't and SSE can be realized by more ways
没有。
iframe实际上是最容易实现的,开销也最少。唯一的缺点是随着时间的推移内存使用。
XHR 非常干净高效,但有一些 IE 版本限制。如果您的用户仍在使用这些版本的 IE,他们可能不会对具有实时消息传递的应用程序有任何用处:)
你总是可以使用:
<script>
window.setTimeout(poll, 3000);
function poll() {
$.ajax({
url: "/",
type: "POST",
data: {},
dataType: "json",
traditional: true,
contentType: "application/json; charset=utf-8",
success: function (data) {
// do something
},
error: function () {
// handle it
},
complete: function() {
window.setTimeout(poll, 3000);
}
});
}