我正在实现典型的服务器推送（彗星）应用程序。我在两个选项之间进行选择：longpoll XHR 和 iFrames。这些有什么好处和坏处？我知道跨站点限制并且 iFrame 是相当重量级的组件......还有其他区别吗？例如传输的“可靠性”或对组件的控制级别？ 您认为，是否有一个正确的答案，哪种方法更好，或者两者都有用例？
提前致谢。
附：我有一个很好的 XHR 实现，但我想考虑替代方案。
【问题讨论】：
标签： javascript iframe xmlhttprequest comet
您应该使用 socket.io 或等效的库。它支持您提到的两种方式以及更多方式：
但是，让我们假设您使用了适当的抽象层，现在想要决定使用哪种传输方式。 :)
IMO，iframe 的交易破坏者是错误处理。持续加载 iframe 技术使错误处理变得更加困难。您不会通过方便的 404 或超时事件得到通知，因此您必须在 JavaScript 中设置一个时间间隔来监视错误。
据说 iframe 的开销比在每条消息后发出新的 XHR/HTTP 请求重新连接的开销要少，但是当我尝试它时，我看到的只是服务器上的内存开销增加和零响应改进；可能这取决于您选择的后端。
另一个有趣的事实是，浏览器被标准限制为对服务器的两个并发请求，但 Mozilla 仅对 XHR 做了一个例外：
https://developer.mozilla.org/en/XMLHttpRequest
当您发出长请求时，2 个连接的限制非常重要：如果您将两个管道都捆绑起来，其他任何东西都无法通过！您必须小心设置页面上所有代码共享的单个通道。但在 Firefox 上，当且仅当您使用 XHR 时，您现在可以获得一些回旋余地。
iframe 确实具有能够发出跨域请求的优势。
【讨论】：
我建议第三个选项：websockets。 websockets api 是从长轮询演变而来的，是为实时客户端-服务器通信而开发的。
并非所有浏览器都支持该协议，因此当 websocket 不可用时，您实际上仍然需要支持长轮询。
有些库可以很好地降级（如果 websockets 可用，它们会使用它们，否则它们会退回到长轮询）。你有socket.io（支持所有浏览器）。一个 jQuery 替代方案是 jquery-graceful-websocket。这两个库都公开了 websocket api，但如有必要，可以使用其他通信方式。
【讨论】：
如果它对智能手机友好，可能会担心的一件事是，运营商可以并且将会在数据通过其网络时弄乱数据。通常是压缩它。
由于 iframe 方法会流式传输包含一些 JS 的网页，它看起来更像是运营商的网页，并且更可能被运营商弄乱。在这种情况下，他们将其缓存起来以防泄漏将是我的主要关注点——他们不太可能改变您实际 JS 的含义。
XHR（尤其是在您实际返回 XML 的情况下）不太可能被运营商弄乱。
当然，一个好的运营商会了解发生了什么，并让这两种方法都起作用。不过，并非所有运营商都很好。
很难判断和计划，但值得考虑。
【讨论】：
我不知道您将 iframe 与 longpull 进行比较是什么意思，但在我看来，iframe 非常危险，并且由于您提到的浏览器限制而使开发变得更加困难。另一方面，longpull XHR 应该更容易使用您当前的 XHR 实现来实现。与异步 XHR 相比，它还提供了同步。
【讨论】：
当然，XHR 是更清洁的解决方案，并且具有前面提到的所有好处。
由于代码很容易实现，我建议你两者都做，并在多个平台上进行测试。创建两个应用程序来显示错过投票的数量，并请求十几个朋友在尽可能多的设备上运行该应用程序。
那就回来汇报吧！
【讨论】：
我认为 longpoll XHR 是更好的选择，原因如下：
这是未来。 iFrame 正在迅速消失。
我认为这是更好的数据和显示分离。您可以获取数据，然后在客户端处理显示。这也将允许您拥有相同的数据源并针对不同的平台以不同的方式显示它。 PC 网络浏览器中的显示与 iPhone 上的显示不同。
【讨论】：