问题描述
BOSH 是...
一种传输协议，它通过有效地使用多个同步 HTTP 请求/响应对来模拟两个实体(例如客户端和服务器)之间长期存在的双向 TCP 连接的语义，而无需使用频繁的轮询或分块回复.
这听起来像 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 协议的
WebSockets 实现是在 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 协议的实现(尽管 Microsoft 将他们的实现作为 单独下载).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/Chrome 14、Firefox 7、IE10、Opera 12.1、Safari 6.0 和 "nofollow noreferrer">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
- 码头
- pywebsockets
- websockify
- Socket.IO
- phpwebsocket
- Protocol::WebSocket (perl)
- em-websocket (ruby)
- node-websocket-server
BOSH 与 WebSockets:
- 延迟:虽然 BOSH 草案文件声称延迟非常低，但 BOSH 很难与 WebSockets 竞争.除非您的所有中介和目标服务器都支持 HTTP/1.1 的理想条件，否则 BOSH 客户端和连接管理器将需要在每个数据包和每个请求超时后重新建立连接.这将显着增加延迟和延迟抖动.对于实时应用程序而言，低抖动通常比平均延迟更重要.WebSocket 连接在延迟和抖动方面与原始 TCP 连接非常相似.即使在理想条件下，BOSH 通信(以及往返)的客户端到服务器延迟始终高于 WebSockets:BOSH 仍然必须遵守 HTTP 请求-响应语义.HTTP 流支持每个请求的多个响应(通过将单个"响应拆分为多个部分)，但反之亦然(每个客户端消息都是一个新请求).
- 小数据包开销:在 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 smallmessages. 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 讨论了 优势通道 API 上的 WebSockets，类似于 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)
这篇关于哪些特定用例需要 BOSH over WebSockets 和长轮询?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！