欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

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

程序员文章站 2022-05-24 08:21:11
...

参考文章: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 .