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