什么具体使用情况需要使用BOSH而不是WebSockets和长轮询？

Question

什么具体使用情况需要使用BOSH而不是WebSockets和长轮询？

httpcometwebsocket

43

BOSH 是一种传输协议，通过高效利用多个同步的HTTP请求/响应对模拟了两个实体（例如客户端和服务器）之间的长期双向TCP连接语义，而不需要频繁轮询或分块响应。

BOSH使用两个开放的HTTP连接而不是一个，并且不扩展HTTP协议。这听起来像WebSockets和HTTP长轮询，那么这两个协议有什么区别，并且在什么情况下会优先选择使用WebSockets而不是BOSH呢？

- a paid nerd

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- kanaka · Accepted Answer

首先让我谈一下WebSockets的准备情况:

Chrome、Safari和iOS（iPhone和iPad）默认安装并启用了实现Hixie-76协议的WebSockets。Firefox 4和Opera 11也默认安装但禁用了Hixie-76协议。web-socket-js项目是一个Flash shim/polyfill，可以将WebSocket（Hixie-76）支持添加到任何带有Flash的浏览器中。

换句话说，WebSockets几乎适用于所有主流浏览器。

Opera和Mozilla选择禁用该协议的原因是理论上存在一些破损的HTTP代理/中介可能会被使用Hixie版本的协议攻击/污染。Flash也存在同样的问题，但Mozilla和Opera认为他们对所提供的代码有更高的责任感。HyBi版本的协议（该协议已移至IETF HyBi工作组）解决了安全问题。

Mozilla、Opera、Google和Microsoft都在开发HyBi协议实现（尽管Microsoft目前仍将其维护为单独下载）。web-socket-js也有一个支持HyBi-07的分支。

更新：截至2013年2月，Chrome 14、Firefox 7、IE10、Opera 12.1、Safari 6.0支持最新的HyBi/IETF RFC 6455规范，并由web-socket-js Flash shim/polyfill提供支持。在移动设备上，iOS 6.0上的Safari、Opera Mobile 12.1、Android上的Chrome 14、Android上的Firefox 7和Blackberry 7都支持IETF6455。原始的默认Android浏览器没有任何WebSocket支持。

WebSocket服务器易于实现。有许多独立的和插件实现，其中大部分支持Hixie-76和HyBi协议版本:

BOSH vs WebSockets:

BOSH与WebSockets的比较：

延迟：虽然BOSH草案文档声称具有非常低的延迟，但与WebSockets竞争将会很困难。除非您处于理想条件下，即所有中间人和目标服务器都支持HTTP/1.1，否则BOSH客户端和连接管理器将需要在每个数据包和每个请求超时后重新建立连接。这将显著增加延迟和延迟抖动。对于实时应用程序而言，低抖动通常比平均延迟更重要。WebSocket连接的延迟和抖动将非常类似于原始TCP连接。即使在理想条件下，BOSH通信的客户端到服务器延迟（因此来回）也始终比WebSockets高：BOSH仍然必须遵守HTTP请求-响应语义。HTTP流式传输允许多个响应每个请求（通过将“单个”响应拆分为多个部分），但反之不行（每个客户端消息都是一个新的请求）。
小数据包开销：在WebSockets中，小消息有两个字节的帧头开销。在BOSH中，每个消息都有HTTP请求和响应头（每个往返通信轻松达到180个字节以上）。此外，每个消息都包装在XML中（据说是可选的，但规范没有定义如何），带有几个会话相关属性。
复杂性：虽然BOSH在浏览器中使用现有机制，但需要一个相当复杂的JavaScript库来实现BOSH语义。在JavaScript中管理这一点也会增加延迟和抖动，与本机/浏览器（甚至Flash）实现相比。
牵引力：BOSH起源于使XMPP更高效的方法。它从XMPP社区中成长起来，据我所知，在该社区之外几乎没有真正的BOSH使用情况。BOSH和XMPP的草案文档被分开，但似乎很少有人在没有XMPP的情况下真正使用BOSH。

更新:

刚刚发现一段视频，Ian Fette在其中讨论了WebSockets相比于类似BOSH的Channel API的优势（在44:00处）