哪些特定用例需要通过WebSockets和长轮询进行BOSH

  • 本文关键字:WebSockets BOSH http comet websocket
  • 更新时间 :
  • 英文 :


BOSH是…

一种传输协议,通过有效地使用多个同步HTTP请求/响应对,模拟两个实体(如客户端和服务器)之间的长寿命双向TCP连接的语义,而不需要使用频繁的轮询或分块响应。

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

这两种协议之间有什么区别,什么用例更喜欢WebSockets而不是BOSH?

首先让我解决WebSockets的就绪性

Hixie-76协议的WebSockets实现在Chrome、Safari和iOS(iPhone和iPad)中默认提供并启用。Hixie-76协议也在Firefox 4和Opera 11中提供,但默认情况下已禁用。WebSocket-js项目是一个Flash填充程序/polyfill,它为任何使用Flash的浏览器添加了WebSocket(Hixie-76)支持。

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

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

Mozilla、Opera、谷歌和微软都在致力于HyBi协议的实现(尽管微软目前将其作为单独的下载进行维护)。有一个web套接字js的分支支持HyBi-07。

更新:截至2013年2月,Chrome 14、Firefox 7、IE10、Opera 12.1、Safari 6.0和web套接字js Flash shim/polyfill支持最新的HyBi/IETF RFC 6455规范。在移动设备上,IETF6455由iOS 6.0版Safari、Opera mobile 12.1、Android版Chrome 14、Android版Firefox 7和Blackberry 7支持。最初默认的Android浏览器不支持任何WebSocket。

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

  • libwebsockets
  • 码头
  • pywebsockets
  • webstockify
  • Socket.IO
  • phpwebsocket
  • 协议::WebSocket(perl)
  • em websocket(ruby)
  • 节点websocket服务器

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在现实世界中的使用似乎很少

更新

刚刚找到一个视频,Ian Fette讨论了WebSockets在Channel API上的优势,这与BOSH(44:00)类似

相关内容

  • 没有找到相关文章

最新更新