http - 哪些特定用例需要 BOSH over WebSockets 和长轮询？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




9年前关闭。




BOSH是...

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 协议(protocol)。

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

Answer 1

首先让我谈谈 WebSockets 的准备情况 :

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

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

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

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

更新 :截至2013年2月，最新HyBi/IETF RFC 6455 spec Chrome 14、Firefox 7、IE10、Opera 12.1、Safari 6.0 和 web-socket-js 支持闪光垫片/polyfill。在移动设备上，iOS 6.0 上的 Safari、Opera Mobile 12.1、Android 版 Chrome 14、Android 版 Firefox 7 和 Blackberry 7 支持 IETF6455。原始默认 Android 浏览器不支持任何 WebSocket。

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

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 通信(以及往返)的客户端到服务器延迟始终高于 WebSockets:BOSH 仍然必须遵守 HTTP 请求-响应语义。 HTTP 流支持每个请求的多个响应(通过将“单个”响应拆分为多个部分)，但反之亦然(每个客户端消息都是一个新请求)。

小包开销 :在 WebSockets 中有两个字节的小帧开销
消息。在 BOSH 中，每条消息都有 HTTP 请求和响应 header (每次往返轻松超过 180 个字节)。此外，每条消息都封装在 XML 中(据说是可选的，但规范没有定义如何)，具有几个与 session 相关的属性。

复杂性 :虽然 BOSH 使用浏览器中的现有机制，但它需要一个中等复杂的 JavaScript 库来实现 BOSH 语义。与 native /浏览器(甚至 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)