初探BOSH （Bidirectional-streams Over Synchronous HTTP）

    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 封装的数据流。

<o:p> </o:p>

流程描述：

BOSH 技术能够同时减小网络带宽和减小客户端响 应的时间。其方案是对客户端的请求连接管理器不给于返回直到数据已经就绪，当客户端收取连接管理器返回的数据会向连接管理器发送下一个请求，于是连接管理 器总是保持着一个客户端的请求，当服务器端数据就绪的时候，可以将数据封装在请求的响应包中，“推送”给客户端。

<o:p> </o:p>

如果双向连接长时间没有数据，连接管理器负责给客户端发送一个空包，空包触发客户端发送新的请求，连接管理器通过这种机制判断连接是否已经中断，由于 BOSH 不是轮询的机制，带宽消耗比标准的 TCP 连接大不了多少。

由于大多数的客户端不支持 HTTP 的 Pipeling （单一的连接上承载并发的请求），于是，客户端必须从第二条 HTTP 连接发送消息。当第二条 HTTP 连接有新的请求发送的时候，连接管理器将第一条连接中的请求返回，即便此时第一条连接中的返回的是空数据包。这样做的原因是让客户端有需要的话可以发送新的请求过来。客户段同一时间最多只能保持两条 HTTP 连接，否则的话，客户端必须等待旧的请求处理完之后才能发送新的请求

在网络经常中断的环境下， BOSH 退化成每个数据请求一个新 HTTP 连接。然而，在通常情况下，网络环境良好，客户端可以使用 http/1.1, 这个时候，一个 Session 包含两个 TCP 长连接，所有的请求都在这两个长连接上传输。基本上任何时候，客户端通过一条连接能够推送数据到服务器，与此同时，服务器端可以“推送”数据到客户端。值得注意的是，这两条长连接的角色在客户端每发送一次请求则角色转换一次。

 

<o:p> </o:p> 尽管大多数时间可以随时推送数据到对端，但是，如果一方刚刚推送完数据，则需要等一个网络来回的时间才能推送下一个数据