长轮询XHR与iframe的区别

Question

我正在实现一个典型的服务器推送（Comet）应用程序。我在长轮询XHR和iFrames之间选择。它们各自有哪些优缺点？我知道跨站点限制和iFrame是一个相当笨重的组件... 还有其他区别吗？例如，传输的“可靠性”或对组件的控制级别？

你认为，有没有一种正确答案来决定哪种方法更好，还是两者都有各自的使用场景？

先提前感谢你。

P.S. 我已经有了一个非常好的XHR实现，但我想考虑其他选择。

- Juriy

Answer 1

我建议第三个选项：websockets。Websockets API 是长轮询的进化，专门用于实时客户端-服务器通信。

该协议并不受所有浏览器支持，因此在 Websockets 不可用时，仍然需要支持长轮询。

有一些库可以很好地降级（如果 Websockets 可用，则使用这些库，否则会退回到长轮询）。您可以使用 socket.io（支持所有浏览器）。还有一个 jQuery 的替代方案是 jquery-graceful-websocket。这两个库都公开了 Websockets API，但必要时会退回到其他通信方式。

- Stefaan Colman

Answer 2

你应该使用socket.io或相当的库。它支持你提到的两种方式以及更多：

http://socket.io/#transports

然而，假设您使用了适当的抽象层，并且现在想决定使用哪种传输方式。 :)

我认为，对于iframe来说，处理错误是一个致命问题。连续加载iframe技术使得处理错误变得非常困难。您无法通过方便的事件收到404或超时的通知，因此必须在JavaScript中设置间隔以监视错误。

据说，与每次消息后重新连接所需的新XHR / HTTP请求相比，iframe的开销较小，但当我尝试时，我看到的只是服务器上增加的内存开销和零响应性改进；可能这取决于您选择的后端。

另一个有趣的事实是，根据标准，浏览器对服务器的并发请求限制为两个，但Mozilla仅针对XHR进行了例外。

https://developer.mozilla.org/en/XMLHttpRequest

当您发出长时间请求时，2个连接限制非常重要：如果您占用了两个管道，其他任何内容都无法通过！您必须小心地设置一个所有页面代码共享的单一通道。但是在Firefox上，您现在可以获得一些余地，但前提是您使用XHR。

Iframe具有跨域请求的优点。

- olooney

Answer 3

如果要使其智能手机友好，可能需要担心的一件事是运营商可以并且会在数据通过他们的网络时进行干扰。通常是为了压缩它。

由于 iframe 方法在某种程度上流式传输带有一些 JS 的网页，因此对于运营商来说，它更像一个网页，更容易被干扰。在这种情况下，我的主要关注点是将其缓存起来，以防止泄漏 - 他们不太可能改变您实际 JS 的含义。

如果您实际返回 XML，则 XHR（特别是）不太可能被运营商干扰。

当然，好的运营商会理解发生了什么，并让两种方法都起作用。但并非所有运营商都是好的。

这是一个难以判断和计划的问题，但值得考虑。

- ADW

Answer 4

我不知道您在比较iframe和longpull时的意思，但我认为iframes非常危险，并且由于您提到的浏览器限制，它们往往使开发变得更加困难。另一方面，使用长轮询XHR应该更容易实现，因为它与您当前的XHR实现相比具有同步性。

- pmaruszczyk

Answer 5

毫无疑问，XHR是更干净的解决方案，并具有先前提到的所有优点。

由于代码易于实现，我建议您同时进行测试，并在多个平台上进行测试。创建两个应用程序，它们将显示错过的投票数量，并请求十几个朋友在尽可能多的设备上运行该应用程序。

然后回报结果！

- bnieland

Answer 6

我认为长轮询XHR是更好的选择，原因如下：

1. 这是未来的趋势。iFrames正在迅速失去市场。

2. 我认为这是数据和显示更好的分离方式。您可以获取数据，然后在客户端处理显示。这也将允许您使用相同的数据源并针对不同平台以不同方式显示它。在PC Web浏览器上显示将与在iPhone上显示不同。

- Elad Lachmi