哪些特定用例需要 BOSH over WebSockets 和长轮询？ [关闭]

Posted 2023-02-24

【中文标题】哪些特定用例需要 BOSH over WebSockets 和长轮询？ [关闭]

【英文标题】：What specific use cases call for BOSH over WebSockets and long-polling? [closed]

【发布时间】：2011-09-20 00:24:17

【问题描述】：

BOSH 是...

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

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

这两种协议有什么区别，哪些用例更喜欢 WebSockets 而不是 BOSH？

【参考方案1】：

首先让我谈谈 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 几乎适用于所有的浏览器。

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

Mozilla、Opera、Google 和 Microsoft 都在致力于 HyBi 协议的实现（尽管 Microsoft 目前将其维护为 separate download）。有一个 branch of web-socket-js 支持 HyBi-07。

更新：截至 2013 年 2 月，Chrome 14、Firefox 7、IE10、Opera 12.1、Safari 6.0 和 web-socket-js Flash shim/polyfill 支持最新的 HyBi/IETF RFC 6455 spec。在移动设备上，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 协议版本：

libwebsockets Jetty 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 通信（以及因此往返）的客户端到服务器延迟也将始终高于 WebSocket：BOSH 仍然必须遵守 HTTP 请求-响应语义。 HTTP 流式处理允许每个请求有多个响应（通过将“单个”响应拆分为多个部分），但反之亦然（每个客户端消息都是一个新请求）。

小包开销

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

复杂性

：虽然 BOSH 使用浏览器中的现有机制，但它需要一个适度复杂的 javascript 库来实现 BOSH 语义。与原生/浏览器（甚至 Flash）实现相比，在 Javascript 中进行管理也会增加延迟和抖动。

牵引力

：BOSH 最初是为了让 XMPP 更高效。它是在 XMPP 社区中发展起来的，据我所知，它在该社区之外几乎没有什么吸引力。 BOSH 和 XMPP 的草案文档是分开的，但在没有 XMPP 的情况下，BOSH 的实际使用似乎很少。

更新：

刚刚找到一个视频，其中 Ian Fette 讨论了 advantages of WebSockets over the Channel API which is similar to BOSH（在 44:00）

【讨论】：

惊人的答案。非常感谢！

我刚刚添加了当前浏览器支持状态的更新。

值得一提的是，Safari 确实不支持 RFC 中指定的 WebSockets。

延迟比较不是同类比较。没有“通过所有中介和目标服务器一直支持 HTTP/1.1 的理想条件”的 WebSockets (WS) 的等价物是“一直不支持 WS”，在这种情况下，您根本没有WS 连接。例如，直到最近，nginx 还没有 WS 支持。因此，使用 HTTP/1.0 的重新建立案例将更公平地描述为“当 WS 不存在时，BOSH 可以继续工作，但性能会很差，并且诊断不如‘未启动’干净”。 WebSockets 在其他方面获胜。

@Pacerier 是的，您可以将 BOSH 视为 HTTP 长轮询技术的标准化：xmpp.org/extensions/xep-0124.html#technique 但它还指定：基于 XML 的消息格式、会话处理等。