BOSH (Bidirectional-streams Over Synchronous HTTP)是一种在客户端和服务器端之间通过HTTP的请求/响应进行客户端和服务器双向通信的技术,BOSH在XMPP系列规范中的XEP-0124中定义,应用场合为基于浏览器的客户端访问XMPP服务器。 下面的内容来自XEP-0124规范。http://www.xmpp.org/extensions/xep-0124.html
其具体应用需求:
1、 能够在手机或者浏览器的运行环境中使用**
2、 浏览器中的客户端能够建立双向的跨域的连接*
3、 兼容缓存部分HTTP Response的HTTP 代理 *
4、 快速通过有HTTP Response生存时间限制的代理 *
5、 兼容HTTP1.0 *
6、 兼容受限的网络连接环境(防火墙、代理、网关)
7、 容错性
8、 扩展性
9、 更小的带宽消耗
10、更快的实时响应时间
11、 支持轮询
12、 按顺序提交数据
13、防止Session中有非法插入的请求(interjecting HTTP requests into a session)
14、防止拒绝服务攻击
15、多路复用的数据流
在规范中声称:打了*号的几项是无法用COMET技术实现(就是2、3、4、5),经过考察,作者是将COMET定义为流的方式推送数据的HTTP长连接技术。因此,无法通过缓存HTTP响应、及有生存时间限制的HTTP代理。另外由于HTTP1.0无法支持块数据的编码(chunked transfer encoding)流的方式推送数据无法在HTTP1.0的环境下使用。(至于第2条,规范作者用了非常奇怪的方式去企图建立跨域的连接,俺决定放弃不追究作者在说啥)要了解HTTP长连接技术,建议看:http://www.ibm.com/developerworks/cn/web/wa-lo-comet/index.html
系统架构:

在架构中,连接管理器(Connection Manager)与 Server之间是原始的数据流(在XMPP的协议中就是XMPP的数据流),HTTP客户端与连接管理器之间是HTTP协议以及Body的TAG封装的数据流。
流程描述:
BOSH技术能够同时减小网络带宽和减小客户端响应的时间。其方案是对客户端的请求连接管理器不给于返回直到数据已经就绪,当客户端收取连接管理器返回的数据会向连接管理器发送下一个请求,于是连接管理器总是保持着一个客户端的请求,当服务器端数据就绪的时候,可以将数据封装在请求的响应包中,“推送”给客户端。

由于大多数的客户端不支持HTTP的Pipeling(单一的连接上承载并发的请求),于是,客户端必须从第二条HTTP连接发送消息。当第二条HTTP连接有新的请求发送的时候,连接管理器将第一条连接中的请求返回,即便此时第一条连接中的返回的是空数据包。这样做的原因是让客户端有需要的话可以发送新的请求过来。客户段同一时间最多只能保持两条HTTP连接,否则的话,客户端必须等待旧的请求处理完之后才能发送新的请求
在网络经常中断的环境下,BOSH退化成每个数据请求一个新HTTP连接。然而,在通常情况下,网络环境良好,客户端可以使用http/1.1,这个时候,一个Session包含两个TCP长连接,所有的请求都在这两个长连接上传输。基本上任何时候,客户端通过一条连接能够推送数据到服务器,与此同时,服务器端可以“推送”数据到客户端。值得注意的是,这两条长连接的角色在客户端每发送一次请求则角色转换一次。

评论
在没有客户端没有发送请求的时候 这个没看太明白. 我设想的情况是这样: 建立这个长HTTP连接时是客户端发出一个空的HTTP请求, 不提交任何请求数据, 只为建立这条HTTP连接; 如果没有数据需要push 服务器可以在连接TimeOut之前不给客户端传任何数据. 然后针对 HTTP/1.1, 可以在快要TimeOut的时候发一个空包维持此连接; 或者可以与 HTTP/1.0 的处理相同, 直接0长度内容结束这条连接, 然后等着客户端发起另外一个 "长连接".
在没有数据这一点上,和bosh是一致的心跳方式
而在客户端有数据发送时,和bosh就不同了,更简单一些
但是问题在于proxy和cache:即使是chunk,proxy cache也可以等所有数据全部接收到了,缓存起来了,再一次性返回给客户端,这样就破坏了这个长连接本来的目的
bosh中response肯定只是一个包,所以能很好地适应proxy和cache
2、不清楚“http1.1的chunk encoding方式实现的长连接 ”与“HTTP Stream”有什么区别?当数据需要分块编码传输的时候,这时候是否可以看作是HTTP的Stream?
PC上大家实现长连接的几种方式:
一、http1.1的chunk encoding方式实现的长连接
二、http1.1的keepalive
三、HTTP Streaming
在没有客户端没有发送请求的时候 这个没看太明白. 我设想的情况是这样: 建立这个长HTTP连接时是客户端发出一个空的HTTP请求, 不提交任何请求数据, 只为建立这条HTTP连接; 如果没有数据需要push 服务器可以在连接TimeOut之前不给客户端传任何数据. 然后针对 HTTP/1.1, 可以在快要TimeOut的时候发一个空包维持此连接; 或者可以与 HTTP/1.0 的处理相同, 直接0长度内容结束这条连接, 然后等着客户端发起另外一个 "长连接".
另外基于HTTP的特性, 即使是长连接, 客户端也应该只发送一次请求数据, 不该有多次roundtrip, 否则proxy/cache的通过性应该就要打折扣了.
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.
这种方式相比于 BOSH 有什么不好的地方?
不可否认BOSH实际上是一种长轮询的技术,但是这种技术的好处也是显而易见的。
1、兼容极端的网络环境,上文所述,穿透各种proxy、网关和http1.0的能力最强,可以退化成每个请求一个连接
2、在http1.1环境下也可以利用http1.1的优点
发表评论
提醒: 该博客已发表在公共论坛,博客所有留言会成为论坛回贴,留言请注意遵守论坛发贴规则
- 浏览: 19065 次
- 性别:

- 来自: 0

- 详细资料
搜索本博客
我的相册
共 20 张
最近加入圈子
最新评论
-
又见内存泄露
说的很好,以后有个解决问题的参考了:)
-- by lean1252 -
一种SSO的实现方案
登录信息的管理中心一旦建立,就会造成所有的系统都对这个管理中心产生依赖。如果这个 ...
-- by downpour -
一种SSO的实现方案
有很多所谓的登陆的话,就是从统一登录系统中想办法把用户信息传递到另外的系统。这似 ...
-- by 香克斯 -
又见内存泄露
很是精髓,但是没有做运维,还不是很懂。
-- by zpple -
SAAS在电子商务中的应用分 ...
淘宝模式不更好?
-- by rtdb






评论排行榜