当前位置：文江博客话题详情

哪些具体用例需要通过 WebSockets 和长轮询使用 BOSH？

发布于 2024-11-17 01:48:50 字数 401 浏览 3 评论 0原文

BOSH 是...

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

这听起来像 WebSockets 和 HTTP 长轮询，只不过它使用两个打开的 HTTP 连接而不是一个不扩展 HTTP 协议。

这两种协议之间有什么区别，什么用例更喜欢 WebSocket 而不是 BOSH？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

但可醉心 2024-11-24 01:48:50

首先让我谈谈 WebSockets 准备情况：

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

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

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

Mozilla、Opera、Google 和 Microsoft 都在致力于 HyBi 协议实现（尽管 Microsoft 正在将其协议维护为暂时单独下载）。 HyBi 有一个 web-socket-js 分支 -07 支持。

更新：截至 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、Opera Mobile 12.1、Chrome 14 for Android、Firefox 7 for Android 和 Blackberry 7 上的 Safari 支持 IETF6455。原始默认 Android 浏览器不支持任何 WebSocket。

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

BOSH 与 WebSockets：

延迟：当 BOSH 草案时文档声称延迟非常低，BOSH 将很难与 WebSocket 竞争。除非您的理想条件是所有中介和目标服务器都支持 HTTP/1.1，否则 BOSH 客户端和连接管理器将需要在每个数据包和每个请求超时后重新建立连接。这将显着增加延迟和延迟抖动。对于实时应用程序来说，低抖动通常比平均延迟更重要。 WebSocket 连接的延迟和抖动与原始 TCP 连接非常相似。即使在理想条件下，BOSH 通信（以及往返）的客户端到服务器延迟也始终高于 WebSocket：BOSH 仍然必须遵守 HTTP 请求-响应语义。 HTTP 流允许每个请求有多个响应（通过将“单个”响应拆分为多个部分），但反之则不然（每个客户端消息都是一个新请求）。
小数据包开销：在 WebSocket 中，小数据包有两个字节的帧开销
消息。在 BOSH 中，每条消息都有 HTTP 请求和响应标头（每次往返很容易超过 180 个字节）。此外，每条消息都用 XML 封装（据说是可选的，但规范没有定义如何封装），并带有多个与会话相关的属性。
复杂性：虽然 BOSH 使用浏览器中的现有机制，但它需要适度复杂的 JavaScript 库来实现 BOSH 语义。与本机/浏览器（甚至 Flash）实现相比，在 Javascript 中管理此操作也会增加延迟和抖动。
吸引力：BOSH 最初是为了提高 XMPP 的效率。它是从 XMPP 社区中发展起来的，据我所知，它在该社区之外几乎没有受到任何关注。 BOSH 和 XMPP 的草案文档是分开的，但在没有 XMPP 的情况下，BOSH 的实际使用似乎很少。

更新：

刚刚发现 Ian Fette 讨论 WebSocket 相对于类似于 BOSH 的 Channel API 的优势 (at 44:00)

First let me address WebSockets readiness:

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.

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

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, 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.

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 servers are easy to implement. There are numerous standalone and plugin implementations most of which support both Hixie-76 and HyBi protocol versions:

BOSH vs WebSockets:

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.

Update:

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

回复收藏 0 原文

~没有更多了~