基于HTTP长连接的“服务器推”技术

参考文章:http://www.ibm.com/developerworks/cn/web/wa-lo-comet/


服务器推送

技术的基础思想是将浏览器主动查询信息改为服务器主动发送信息。
服务器发送一批数据,浏览器显示这些数据,同时保证与服务器的连接。当服务器需要再次发送一批数据时,浏览器显示数据并保持连接。以后,服务器仍然可以发送批量数据,浏览器继续显示数据,依次类推 。


应用举例:

监控系统:报警提示;
即时通信系统:其它用户登录、发送信息;
即时报价系统:后台数据库内容发生变化; 
实现基于web的实时事件通知 。

比如秒杀应用也用到了该技术。

 

server push技术方案:

基于客户端套接口 :
     采用RMI、CORBA或者自定义TCP/IP信息的applet来实现 。或者flash xml socket,貌似web旺旺那边有采用该技术来着。

Comet:
     基于 HTTP 长连接、无须在浏览器端安装插件的技术 。

 

比较

客户端拉曳(pull):客户端定时去查询服务器上的最新数据。

comet

优点:服务器完全能够控制客户端更新数据的时间和频率 。
缺点:保持连接状态会浪费服务器端的资源。服务器推送还比较容易中断 。

 

comet应用实现模型

基于 AJAX 的长轮询(long-polling)
    即服务端阻断前一次对客户端的回应,在事件发生后将事件内容绑定在回应中返回给客户端,同时回应结束,此时客户端立即发送第二次请求,服务器阻塞回应等待下一次事件发生。
基于 Iframe 及 htmlfile 的流(streaming)方式
    通过在 HTML 页面里嵌入一个隐蔵帧,然后将这个隐蔵帧的 SRC 属性设为对一个长连接的请求,服务器端就能源源不断地往客户端输入数据。即服务器阻断客户端的回应,服务器没有关闭回应而是一直保留这这个到客户端的输出流。

 

 

实现了comet的相关开源框架

pushlet
dwr
cometD


pushlet简介
工作原理:
     通过servlet(或者JSP)把JavaScript代码作为HTTP流推送到浏览器。这些代码被浏览器的JavaScript引擎解释并完成一些有趣的工作。于是便轻松地完成了从server端的Java到浏览器中的JavaScript的回调。

Pushlet优缺点
优点:
    (1)直接与浏览器中的DHTML集成。   
    (2)标准的HTTP端口和协议:消息和RMI/CORBA使用非标准端口(相对HTTP标准端口而言),遇到“防火墙”、“禁止回调”、“禁止接收UDP数据”的浏览器安全限制时可能无法工作。    
    (3)client负载:基于CORBA/RMI的Java applet使client在启动时更加沉重,并消耗更多的资源。    
    (4)无需额外的server:消息和RMI/CORBA需要单独的server产品。Pushlet理论上可以在任何server引擎上运行,并具备连接管理和多线程能力。

 

缺点:
    (1)跨越浏览器的DHTML:Pushlet需要使用能工作在任何平台、所有浏览器版本的DHTML库。       
    (2)可测量性:当100个以上的client通过Pushlet连接到server时,server上的线程和socket资源都将出现紧张。而解决这一问题的方式就是使用单独的Pushlet服务器。       
    (3)Web server问题:一般的web server往往不是为长连接而设计的。针对这一问题的解决方案与上面的可测量性相同。       
    (4)代理缓存:一些代理服务器可能缓存HTTP数据。

 

long-polling 简单实现

一个基于web的聊天程序的话,大致代码如下:

客户端定时的发送请求到服务器端,取得新的聊天内容,更新页面相关文本。

 

function refresh_chat() {  
     $.ajax({  
         url: "/chat",  
         data: "format=xhr&chat_id={{chat_id}}&cur_len=" + chat_content.length,  
           complete: function(xhr){  
                if (xhr.status == 200) render_chat(xhr.responseText);  
                 setTimeout("refresh_chat()", 5000)  
           }  
      });  
 } 

 

服务器端,比较当前聊天内容是否有变化,是的话,就返回最新的信息,否则返回304.  

cur_len = self.request.get("cur_len", 0)  
 if len(chat.content) == int(cur_len):  
     self.error(304) # return 304 Not Modified  
 else:  
     self.response.out.write(chat.content) # return new content 

 

 以上的代码带来的问题是,不断的轮询(poll),每次发送请求后,服务器端很快就返回结果。这种方式可以理解为pull的方式。

 

其实我们更希望的方式是,push的机制。当服务器发现有内容更新时,可以主动的将相关内容推送给客户端。

客户端得代码基本不变。

function refresh_chat() {  

     $.ajax({  
         url: "/chat",  
         data: "format=xhr&chat_id={{chat_id}}&cur_len=" + chat_content.length,  
           complete: function(xhr){  
                 if (xhr.status == 200) render_chat(xhr.responseText);  
                 setTimeout("refresh_chat()", 1000);  
           }  
      });  
 } 

 

服务端得代码做了一点变更:增加了一个时间delay,发现如果有内容更新则立即返回,否则在未超过delay的时间范围里,一直进行检测,不向客户端返回结果。这样带来的效果就是,客户端与服务端保持了一个长连接

 

cur_len = self.request.get("cur_len", 0)
end_by = int(time.time()) + 30
while int(time.time()) < end_by:
	if len(chat.content) != int(cur_len):
		return self.response.out.write(chat.content) # return new content
	time.sleep(1)
self.error(304) # return 304 Not Modified

 

这种方式,跟我们平常编写web应用程序有点不同,一般我们希望服务器能够尽快的返回结果。延迟返回跟我们的经验直觉有所冲突。However, this also makes production use a bit complicated, since most web server stacks are optimized for maximum requests/second rather than long concurrent requests. Content-rich sites often use separate servers for big media content for this reason, and Comet also has its own server (er “HTTP-based event routing bus”) in cometd .

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值