什么具体的用例通过WebSockets和长期投票调用BOSH？
BOSH是…
传输协议通过有效地使用多个同步HTTP请求/响应对而不需要使用频繁的轮询或分块响应来模拟两个实体（诸如客户端和服务器）之间的长期双向TCP连接的语义。
这听起来像WebSockets和HTTP长轮询，除了它使用两个开放的HTTP连接而不是一个，并且不扩展HTTP协议。
这两种协议有什么区别，哪种用例更喜欢WebSocket而不是BOSH？
首先让我解决WebSocket的准备工作 ：
Chrome，Safari和iOS（iPhone和iPad）默认启用Hixie-76协议的WebSockets实现。 Hixie-76协议也在Firefox 4和Opera 11中默认禁用.web- socket-js项目是一个Flash Shim / polyfill，它可以通过Flash为任何浏览器添加WebSocket（Hixie-76）支持。
换句话说，几乎所有的浏览器都可以使用WebSockets。
Opera和Mozilla之所以select在默认情况下禁用协议，是因为理论上担心可能会有一些破坏的HTTP代理/中介可能被Hixie协议版本攻击/毒害。 同样的担忧适用于Flash，但Mozilla和Opera认为他们所提供代码的责任更高。 该协议的HyBi版本（该协议被转移到IETF HyBi工作组）解决安全问题。
Mozilla，Opera，Google和Microsoft都在研究HyBi协议的实现（尽pipe微软现在将其作为一个单独的下载进行维护）。 有一个支持HyBi-07 的web-socket-js分支 。
更新 ：截至2013年2月，Chrome 14，Firefox 7，IE10，Opera 12.1，Safari 6.0以及web-socket-js Flash Shim / polyfill均支持最新的HyBi / IETF RFC 6455规范 。 在移动设备上，iOS 6.0，Opera Mobile 12.1，Android的Chrome 14，Android的Firefox 7和Blackberry 7支持IETF6455。原始的默认Android浏览器没有任何WebSocket支持。
WebSocket服务器很容易实现。 有许多独立和插件实现，其中大部分都支持Hixie-76和HyBi协议版本：
- libwebsockets
- docker
- pywebsockets
- websockify
- Socket.IO
- phpwebsocket
- Protocol :: WebSocket（perl）
- em-websocket（ruby）
- 节点的WebSocket服务器
BOSH vs WebSockets ：
- 等待时间 ：虽然BOSH草案文件声明的延迟非常低，但是BOSH很难与WebSocket竞争。 BOSH客户端和连接pipe理器需要在每个数据包和每个请求超时之后重新build立连接，除非您有完全支持所有中间层和目标服务器的HTTP / 1.1的理想条件。 这将显着增加延迟和延迟抖动。 对于实时应用，低抖动通常比平均延迟更重要。 WebSocket连接的延迟和抖动与原始TCP连接非常相似。 即使在理想条件下，BOSH通信（因此往返）的客户端到服务器延迟总是会高于WebSocket：BOSH仍然必须遵守HTTP请求 – 响应语义。 HTTPstream式传输为每个请求启用多个响应（通过将“单个”响应拆分为多个部分），而不是相反（每个客户端消息是新的请求）。
- 小数据包开销 ：在WebSockets中，有两个字节的小消息的开销。 在BOSH中，每个消息都有HTTP请求和响应头（每个往返都容易180+字节）。 另外，每个消息都用XML包装（据说是可选的，但是规范没有定义如何）以及几个会话相关的属性。
- 复杂性 ：虽然BOSH在浏览器中使用现有的机制，但它需要一个适度复杂的JavaScript库来实现BOSH语义。 与原生/浏览器（甚至是Flash）实现相比，使用Javascript来pipe理这个function也会增加延迟和抖动。
- 牵引力 ：BOSH开始生命作为使XMPP更有效率的一种方式。 它是从XMPP社区成长起来的，从我所知道的情况来看，在这个社区之外几乎没有什么牵引力。 BOSH和XMPP的文件草案是分开的，但是如果没有XMPP，BOSH的实际应用似乎很less。
更新 ：
刚刚find了一个video，伊恩·菲特（Ian Fette） 在频道API上讨论了WebSockets的优点，这个API类似于BOSH （在44:00）
