哪些特定用例通过WebSockets和长轮询调用BOSH？ [英] What specific use cases call for BOSH over WebSockets and long-polling?

问题描述

BOSH 是......

一种传输协议，它通过有效地使用多个同步HTTP请求/响应对来模拟两个实体（例如客户端和服务器）之间的长期双向TCP连接的语义无需使用频繁的轮询或分组响应。

a transport protocol that emulates the semantics of a long-lived, bidirectional TCP connection between two entities (such as a client and a server) by efficiently using multiple synchronous HTTP request/response pairs without requiring the use of frequent polling or chunked responses.

这听起来像 WebSockets 和HTTP长轮询，除了它使用两个开放的HTTP连接而不是一个，并且不扩展HTTP协议。

This sounds like WebSockets and HTTP long-polling except that it uses two open HTTP connections instead of one and doesn't extend the HTTP protocol.

两个协议之间有什么区别，哪个用例更喜欢WebSockets而不是BOSH？

What are the differences between the two protocols, and what use case would prefer WebSockets over BOSH?

推荐答案

首先让我解决WebSockets就绪问题：

Hixie-76 协议默认在Chrome，Safari和iOS（iPhone和iPad）中提供并启用。 Hixie-76协议也在Firefox 4和Opera 11中默认发布但禁用。 web-socket -js 项目是一个Flash shim / polyfill，它为任何带Flash的浏览器添加了WebSocket（Hixie-76）支持。

WebSockets implementation of the Hixie-76 protocol are shipped and enabled by default in Chrome, Safari and iOS (iPhone and iPad). The Hixie-76 protocol is also shipped but disabled by default in Firefox 4 and Opera 11. The web-socket-js project is a Flash shim/polyfill that adds WebSocket (Hixie-76) support to any browser with Flash.

换句话说，WebSockets可用对于几乎所有浏览器都是如此。

In other words, WebSockets is available for almost every browser in the wild.

Opera和Mozilla默认选择禁用协议的原因是理论上担心可能存在一些损坏的HTTP代理/中间人可能使用协议的Hixie版本攻击/中毒。同样的问题也适用于Flash，但Mozilla和Opera对他们发布的代码负有更高的责任。 HyBi版本的协议（该协议被移至IETF HyBi工作组）解决了安全问题。

The reason why Opera and Mozilla chose to disable the protocol by default is because of a theoretical concern that there might be some broken HTTP proxies/intermediaries that could be attacked/poisoned using the Hixie versions of the protocol. The same concern applies to Flash but Mozilla and Opera felt a higher duty of responsibility for code that they ship. The HyBi versions of the protocol (the protocol was moved to the IETF HyBi working group) address the security concern.

Mozilla，Opera，Google和Microsoft都在努力HyBi协议实现（尽管微软目前将其作为单独下载）进行维护。 Hybi-有一个 web-socket-js分支 07支持。

Mozilla, Opera, Google, and Microsoft are all working on HyBi protocol implementations (although Microsoft is maintaining theirs as a separate download for now). There is a branch of web-socket-js with HyBi-07 support.

更新：截至2013年2月，最新 HyBi / IETF RFC 6455规范受Chrome 14，Firefox 7，IE10，Opera 12.1，Safari 6.0和 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支持。

Update: As of Feb, 2013, the latest HyBi/IETF RFC 6455 spec is supported by Chrome 14, Firefox 7, IE10, Opera 12.1, Safari 6.0 and by the web-socket-js Flash shim/polyfill. On mobile devices IETF6455 is supported by Safari on iOS 6.0, Opera Mobile 12.1, Chrome 14 for Android, Firefox 7 for Android, and Blackberry 7. The original default Android browser does not have any WebSocket support.

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

WebSocket servers are easy to implement. There are numerous standalone and plugin implementations most of which support both Hixie-76 and HyBi protocol versions:

• libwebsockets


• Jetty


• pywebsockets


• websockify


• Socket.IO


• < a href =http://code.google.com/p/phpwebsocket/ =noreferrer> phpwebsocket


• Protocol :: WebSocket（perl）


• em-websocket（ruby）


• node-websocket-server

• libwebsockets
• Jetty
• pywebsockets
• websockify
• Socket.IO
• phpwebsocket
• Protocol::WebSocket (perl)
• em-websocket (ruby)
• node-websocket-server

BOSH vs WebSockets ：

• 延迟：虽然BOSH草案文档声称延迟非常低，BOSH很难与WebSockets竞争。除非你有理想的条件，所有中介和目标服务器都支持HTTP / 1.1，否则BOSH客户端和连接管理器需要在每个数据包和每个请求超时后重新建立连接。这将显着增加延迟和延迟抖动。对于实时应用，低抖动通常比平均延迟更重要。 WebSocket连接在延迟和抖动方面与原始TCP连接非常相似。即使在理想条件下，BOSH通信（因此往返）的客户端到服务器延迟也总是高于WebSockets：BOSH仍然必须遵守HTTP请求 - 响应语义。 HTTP流式传输允许每个请求多个响应（通过将单个响应分成多个部分），反之则不然（每个客户端消息都是新请求）。


• small-数据包开销：在WebSockets中，对于小的
  消息，有两个字节的成帧开销。在BOSH中，每条消息都有HTTP请求和响应头（每次往返很容易180多字节）。此外，每条消息都包含在XML中（据说是可选的，但规范没有定义如何）与几个会话相关的属性。


• 复杂性：而BOSH使用在浏览器中的现有机制中，它需要一个中等复杂的JavaScript库来实现BOSH语义。与原生/浏览器（甚至Flash）实施相比，在Javascript中管理此操作也会增加延迟和抖动。


• 牵引力：BOSH开始以生命的方式开始使XMPP更有效率。它是从XMPP社区中长大的，而且据我所知，在该社区之外几乎没有什么牵引力。 BOSH和XMPP的文件草案分开，但没有XMPP，BOSH的实际使用情况似乎很少。

• latency: While the BOSH draft document claims very low-latency, it will be difficult for BOSH to compete with WebSockets. Unless you have ideal conditions where HTTP/1.1 is supported all the way through all intermediaries and by the target server, the BOSH client and connection manager will need to re-establish connections after every packet and every request timeout. This will significantly increase latency and latency jitter. Low jitter is often more important for real-time applications than average latency. WebSocket connections will be very similar in latency and jitter to raw TCP connections. And even under ideal conditions, the client-to-server latency of BOSH communication (and therefore round-trip) will always be higher than WebSockets: BOSH still has to abide by HTTP request-response semantics. HTTP streaming enables multiple responses per request (by splitting a "single" response into multiple parts) but not vice-versa (each client message is a new request).
• small-packet overhead: In WebSockets there are two bytes of framing overhead for small messages. In BOSH, every message has HTTP request and response headers (easily 180+ bytes for each round-trip). In addition, each message is wrapped in XML (supposedly optional but the spec doesn't define how) with several session related attributes.
• complexity: while BOSH uses existing mechanisms in the browser, it requires a moderately complex JavaScript library to implement the BOSH semantics. Managing this in Javascript will also increase latency and jitter compared to a native/browser (or even Flash) implementation.
• traction: BOSH started life as a way to make XMPP more efficient. It grew up out of the XMPP community and from what I can tell has gotten very little traction outside of that community. The draft documents for BOSH and XMPP are split apart, but there seems to be very little real world use of BOSH without XMPP.

更新：

刚刚找到Ian Fette讨论 WebSockets优于Channel API的优势，类似于BOSH （44:00）

Just found a video where Ian Fette discusses the advantages of WebSockets over the Channel API which is similar to BOSH (at 44:00)

这篇关于哪些特定用例通过WebSockets和长轮询调用BOSH？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！