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

最新推荐文章于 2024-05-24 09:12:41 发布

iteye_19096

最新推荐文章于 2024-05-24 09:12:41 发布

阅读量164

点赞数

分类专栏： WEB应用开发 J2EE 文章标签： javascript 数据库网络 ViewUI

本文链接：https://blog.csdn.net/iteye_19096/article/details/82101509

版权

WEB应用开发同时被 2 个专栏收录

9 篇文章 0 订阅

订阅专栏

J2EE

7 篇文章 0 订阅

订阅专栏

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