polling轮询和comet

comet:（原意：彗星）

Comet is a web application model in which a long-held(held:保留） HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it.^[1]^[2] Comet is an umbrella term,(概括词) encompassing multiple techniques for achieving this interaction. All these methods rely on features included by default in browsers, such as JavaScript, rather than on non-default plugins. The Comet approach differs from the original model of the web, in which a browser requests a complete web page at a time.^[3]

The use of Comet techniques in web development predates the use of the word Comet as a neologism for the collective techniques. Comet is known by several other names, including Ajax Push,^[4]^[5] Reverse Ajax,^[6] Two-way-web,^[7] HTTP Streaming,^[7] and HTTP server push^[8] among others.

comet主要实现有ajax和hidden iframe.主要是服务器端向客户端推送数据。

来自：http://en.wikipedia.org/wiki/Comet_(programming)

push technology:

Push, or server push, describes a style of Internet-based communication where the request for a given transaction is initiated by the publisher or centralserver. It is contrasted with pull, where the request for the transmission of information is initiated by the receiver or client.

包括：

Long polling

Long polling is itself not a true push; long polling is a variation of the traditional polling technique, but it allows emulating a push mechanism under circumstances where a real push is not possible.

长轮询不是真正的push，long polling 是传统polling的变体。但是它模拟了push机制，在真正的push不可能的情况下。

With long polling, the client requests information from the server in a way similar to a normal polling; however, if the server does not have any information available for the client, then instead of sending an empty response, the server holds the request and waits for information to become available (or for a suitable timeout event), after which a complete response is finally sent to the client.

For example, BOSH is a popular, long-lived HTTP technique used as a long-polling alternative to TCP when TCP is difficult or impossible to employ directly (e.g., in a web browser);^[9] it is also an underlying technology in the XMPP, which Apple uses for its iCloud push support.

来自：http://en.wikipedia.org/wiki/Push_technology

pull:

Pull coding or client pull is a style of network communication where the initial request for data originates from the client, and then is responded to by the server. The reverse is known as push technology, where the server pushes data to clients. Usually, customers will look for a site and visit only if it provides helpful and attractive contents and display. The pull code is effective and economical when advertising to open, unidentified potential customers world wide. It is more effective for the customer when he searches for a specific item.

Pull requests form the foundation of network computing, where many clients request data from centralised servers. Pull is used extensively on the Internet forHTTP page requests from websites.

A push can also be simulated using multiple pulls within a short amount of time. For example, when pulling POP3 email messages from a server, a client can make regular pull requests every few minutes. To the user, the email then appears to be pushed, as emails appear to arrive close to real-time. The tradeoff is this places a heavier load on both the server and network in order to function correctly.

Most web feeds, such as RSS are technically pulled by the client. With RSS, the user's RSS reader polls the server periodically for new content; the server does not send information to the client unrequested. This continual polling is inefficient and has contributed to the shutdown or reduction of several popular RSS feeds that could not handle the bandwidth.^[1]^[2] For solving this problem, the PubSubHubbub protocol as another example of a push code was devised.

来自：http://en.wikipedia.org/wiki/Pull_technology

一篇文章：

实现一个简单的服务端推方案

Posted on 2012-09-28

客户端和服务端的交互有推和拉两种方式：如果是客户端拉的话，通常就是Polling；如果是服务端推的话，一般就是Comet，目前比较流行的Comet实现方式是Long Polling。

注：如果不清楚相关名词含义，可以参考：Browser 與 Server 持續同步的作法介紹。

先来看看Polling，它其实就是我们平常所说的轮询，大致如下所示：

因为服务端不会主动告诉客户端它是否有新数据，所以Polling的实时性较差。虽然可以通过加快轮询频率的方式来缓解这个问题，但相应付出的代价也不小：一来会使负载居高不下，二来也会让带宽捉襟见肘。

再来说说Long Polling，如果使用传统的LAMP技术去实现的话，大致如下所示：

客户端不会频繁的轮询服务端，而是对服务端发起一个长连接，服务端通过轮询数据库来确定是否有新数据，一旦发现新数据便给客户端发出响应，这次交互便结束了。客户端处理好新数据后再重新发起一个长连接，如此周而复始。

在上面这个Long Polling方案里，我们解决了Polling中客户端轮询造成的负载和带宽的问题，但是依然存在服务端轮询，数据库的压力可想而知，此时我们虽然可以通过针对数据库使用主从复制，分片等技术来缓解问题，但那毕竟只是治标不治本。

我们的目标是实现一个简单的服务端推方案，但简单绝对不意味着简陋，轮询数据库是不可以接受的，下面我们来看看如何解决这个问题。在这里我们放弃了传统的LAMP技术，转而使用Nginx与Lua来实现。

此方案的主要思路是这样的：使用Nginx作为服务端，通过Lua协程来创建长连接，一旦数据库里有新数据，它便主动通知Nginx，并把相应的标识（比如一个自增的整数ID）保存在Nginx共享内存中，接下来，Nginx不会再去轮询数据库，而是改为轮询本地的共享内存，通过比对标识来判断是否有新消息，如果有便给客户端发出响应。

注：服务端维持大量长连接时内核参数的调整请参考：http长连接200万尝试及调优。

首先，我们简单写一点代码实现轮询（篇幅所限省略了查询数据库的操作）：

lua_shared_dict config 1m;

server {
    location /push {
        content_by_lua '
            local id = 0;

            local ttl = 100;

            local now = ngx.time();

            local config = ngx.shared.config;

            if not config:get("id") then
                config:set("id", "0");
            end

            while id >= tonumber(config:get("id")) do
                local random = math.random(ttl - 10, ttl + 10);

                if ngx.time() - now > random then
                    ngx.say("NO");
                    ngx.exit(ngx.HTTP_OK);
                end

                ngx.sleep(1);
            end

            ngx.say("YES");
            ngx.exit(ngx.HTTP_OK);
        ';
    }

    ...
}

注：为了处理服务端不知道客户端何时断开连接的情况，代码中引入超时机制。

其次，我们需要做一些基础工作，以便操作Nginx的共享内存：

lua_shared_dict config 1m;

server {
    location /config {
        content_by_lua '
            local config = ngx.shared.config;

            if ngx.var.request_method == "GET" then
                local field = ngx.var.arg_field;

                if not field then
                    ngx.exit(ngx.HTTP_BAD_REQUEST);
                end

                local content = config:get(field);

                if not content then
                    ngx.exit(ngx.HTTP_BAD_REQUEST);
                end

                ngx.say(content);
                ngx.exit(ngx.HTTP_OK);
            end

            if ngx.var.request_method == "POST" then
                ngx.req.read_body();

                local args = ngx.req.get_post_args();

                for field, value in pairs(args) do
                    if type(value) ~= "table" then
                        config:set(field, value);
                    end
                end

                ngx.say("OK");
                ngx.exit(ngx.HTTP_OK);
            end
        ';
    }

    ...
}

如果要写Nginx共享内存的话，可以这样操作：

shell> curl -d "id=123" http://<HOST>/config

如果要读Nginx共享内存的话，可以这样操作：

shell> curl http://<HOST>/config?field=id

注：实际应用时，应该加上权限判断逻辑，比如只有限定的IP地址才能使用此功能。

当数据库有新数据的时候，可以通过触发器来写Nginx共享内存，当然，在应用层通过观察者模式来写Nginx共享内存通常会是一个更优雅的选择。

如此一来，数据库就彻底翻身做主人了，虽然系统仍然存在轮询，但已经从轮询别人变成了轮询自己，效率不可相提并论，相应的，我们可以加快轮询的频率而不会造成太大的压力，从而在根本上提升用户体验。

突然想起另一个有趣的服务端推的做法，不妨在一起唠唠：如果DB使用Redis的话，那么可以利用其提供的BLPOP方法来实现服务端推，这样的话，连sleep都不用了，不过有一点需要注意的是，一旦使用了BLPOP方法，那么Nginx和Redis之间的连接便会一直保持下去，从Redis的角度看，Nginx是客户端，而客户端的可用端口数量是有限的，这就意味着一台Nginx至多只能建立六万多个连接（net.ipv4.ip_local_port_range），有点儿少。

…

当然，本文的描述只是沧海一粟，还有很多技术可供选择，比如Pub/Sub，WebSocket等等，篇幅所限，这里就不多说了，有兴趣的读者请自己查阅。

转自：http://huoding.com/2012/09/28/174

--------------------------------------------------------------------------------

PHP服务端推送技术Long Polling

Long Polling与Polling概述

服务端推送技术应用越来越普遍，应用范围也越来越宽广，技术解决方案也越来越成熟且丰富。很多SNS网站的chat功能就有用到了Long Polling技术。比如fackebook, kaixin001。

Long Polling原理其实很简单，也很讨巧。与Polling相比，Long Polling客户端也许不会马上收到来自服务端的响应，需要等待一些时间(直到有新消息，或者连接timeout了等等)。同样的，客户端也不再需要定时向服务发送请求了，而是直到收到服务端响应之后，或者连接丢失之后，客户端接着马上请求客户端。这里，我打个比方，传统的Polling一般是由C向S询问:”有我的信件吗？”。S接到询问之后，会立即查询，并且把查询结果告诉C，不管有没有C的信件，要码回复:”嗯，你有X封信。”，要码回复:”没，没有你的信”.而Long Polling更像是这样，C向S发出询问:”有我的信件吗？”，S开始查询，如果有则回复C:”嗯，有你x封信”。如果没有，则不作任何回复，而是让C等着，自己一遍一遍地查询是否有订阅者的信。换句话说：当S收到C的查询请求之后，Polling则只查询一次，并且把查询结果告诉C;而Long Polling收到请求之后，则会一遍一遍地查询，直到有消息才会响应C，不然一直hold Client。

Long Polling相较传统的Polling而言，最大的实惠在于：减少了请求次数。举个例子，假定一个用户每2小时内，有可能收到2条新消息。如果采用传通的Polling方式，每30秒发向服务端发送一次查询请求的话。则在这2小时内，服务器需要处理240(60*60*2/30)次请求，其中至少有238次请求是没有实际意义的。试想，如果是10000的并发量的话，这种浪费是很惊人的。相较而方，Long Polling没有那么浪费服务器资源来处理这些没有实际意义的请求。

Polling

传统的Polling实现方式比较单一，由客户端javascript脚本定时发送http请求。服务端脚本如下:

<?php
header("Expires: Sun, 19 Nov 1978 05:00:00 GMT");
header("Last-Modified: ". gmdate("D, d M Y H:i:s") ." GMT");
header("Cache-Control: store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", FALSE);
 
$msg = get_msg();
if ($msg) {
 echo $msg;
} else {
 echo '0';
}
?>

上面是一个传统polling简单的服务端脚本。很简单，收到客户端请求后，服务端马上执行脚本查询，并且立即响应客户端。客户端等待的时间很短，客户端唯一要做的事情就是定时向服务端发出查询请求。下面是请求时，通过tcpdump抓到的包:

1>17:49:03.533760 IP 192.168.0.98.4383 > devhome.http: S 3235664319:3235664319(0) win 65535 <mss 1460,nop,nop,sackOK>
2>17:49:03.534336 IP devhome.http > 192.168.0.98.4383: S 2018732723:2018732723(0) ack 3235664320 win 5840 <mss 1460,nop,nop,sackOK>
3>17:49:03.533841 IP 192.168.0.98.4383 > devhome.http: . ack 1 win 65535
4>17:49:03.534404 IP 192.168.0.98.4383 > devhome.http: P 1:781(780) ack 1 win 65535
5>17:49:03.534416 IP devhome.http > 192.168.0.98.4383: . ack 781 win 7020
6>17:49:03.535033 IP devhome.http > 192.168.0.98.4383: P 1:369(368) ack 781 win 7020
7>17:49:03.535110 IP devhome.http > 192.168.0.98.4383: F 369:369(0) ack 781 win 7020
8>17:49:03.535263 IP 192.168.0.98.4383 > devhome.http: . ack 370 win 65167
9>17:49:03.536105 IP 192.168.0.98.4383 > devhome.http: F 781:781(0) ack 370 win 65167
10>17:49:03.536111 IP devhome.http > 192.168.0.98.4383: . ack 782 win 7020

第1、2、3行，TCP三次握手，建立连接。
第4行，由192.168.0.98向服务端devhome发送httpd请求。
第5行，由服务端devhome确认收到了来自客户端192.168.0.98的http请求。
第6行，服务器响devhom响应客户端192.168.0.98刚才发的httpd请求。注意:特别注意一下第一列时间截，http请求与http响应的时间间隔很短，才0.001s
第7、8、9、10共4行，TCP四次挥手，断开连接。由服务端主动断开连接。

Long Polling

Long Polling较之Polling稍微有些不一样，Long Polling持续执行，以此延迟对客户端的响应。请查看代码:

<?php
header("Expires: Sun, 19 Nov 1978 05:00:00 GMT");
header("Last-Modified: ". gmdate("D, d M Y H:i:s") ." GMT");
header("Cache-Control: store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", FALSE);
//在$timeout之后，关闭连接，并且要求客户3秒后重新请求
for ($i = 0, $timeout = 60; $i < $timeout; $i++ ) {
 $msg = get_msg();
 if ($msg) {
     echo json_encode(array('t' => 'info' , 'c' => $msg));
     flush();
     exit(0);
 }  
 usleep(3000000);
}
echo json_encode(array('t' => 'refresh', 'c' => 3000));
flush();
?>

上面是Long Polling服务端代码。语意也很明了，如果有$msg，则会马上响应客户端请求，并且关闭该TCP连接。如果在$timeout之内，没有$msg，则会让客户端一直保持该TCP连接，不中断(关闭)。直到超过了$timeout(具体时间主要取决于$timeout * $usleep_time)，服务端会要求客户端重新请求(重新建立TCP连接)，同时关闭当前TCP连接。下面是通过 tcpdump抓到的包:

1>18:39:46.449563 IP 192.168.0.98.4407 > devhome.http: S 174149200:174149200(0) win 65535 <mss 1460,nop,nop,sackOK>
2>18:39:46.449587 IP devhome.http > 192.168.0.98.4407: S 938669730:938669730(0) ack 174149201 win 5840 <mss 1460,nop,nop,sackOK>
3>18:39:46.449692 IP 192.168.0.98.4407 > devhome.http: . ack 1 win 65535
4>18:39:46.450308 IP 192.168.0.98.4407 > devhome.http: P 1:793(792) ack 1 win 65535
5>18:39:46.450320 IP devhome.http > 192.168.0.98.4407: . ack 793 win 7128
6>18:42:46.521749 IP devhome.http > 192.168.0.98.4407: P 1:377(376) ack 793 win 7128
7>18:42:46.521825 IP devhome.http > 192.168.0.98.4407: P 377:412(35) ack 793 win 7128
8>18:42:46.521859 IP devhome.http > 192.168.0.98.4407: F 412:412(0) ack 793 win 7128
9>18:42:46.521997 IP 192.168.0.98.4407 > devhome.http: . ack 412 win 65124
10>18:42:46.522021 IP 192.168.0.98.4407 > devhome.http: . ack 413 win 65124
11>18:42:46.522965 IP 192.168.0.98.4407 > devhome.http: F 793:793(0) ack 413 win 65124
12>18:42:46.522970 IP devhome.http > 192.168.0.98.4407: . ack 794 win 7128

第1、2、3行，TCP三次握手，建立连接。
第4行，由192.168.0.98向服务端192.168.0.6发送http请求。
第5行，由192.168.0.6确认收到192.168.0.98刚刚发送的请求。
第6、7行，服务器host_6响应3分钟前客户端192.168.0.98发出的http请求。注意，第一列的时间截，第5行与第6行之差为3分钟。这与服务端脚本，客户端监控是相呼应的。
最后4行，TCP四次挥手，断开连接，同样由服务端devhome发起。

由上图可见(httpwatch绘制),正好验证了，响应客户端host_98的http请求，在3分钟之后。这也说明了，Long Polling与Polling的区别在于，客户端有可能需要等待更长时间才能收到服务端的响应。

转自：http://www.perfgeeks.com/?p=139

一篇好文章：

ibm:Comet：基于 HTTP 长连接的“服务器推”技术

很多应用譬如监控、即时通信、即时报价系统都需要将后台发生的变化实时传送到客户端而无须客户端不停地刷新、发送请求。本文首先介绍、比较了常用的“服务器推”方案，着重介绍了 Comet －使用 HTTP 长连接、无须浏览器安装插件的两种“服务器推”方案：基于 AJAX 的长轮询方式；基于 iframe 及 htmlfile 的流方式。最后分析了开发 Comet 应用需要注意的一些问题，以及如何借助开源的 Comet 框架－pushlet 构建自己的“服务器推”应用。

“服务器推”技术的应用


		订阅 Ajax 相关文章和教程的 RSS 提要

传统模式的 Web 系统以客户端发出请求、服务器端响应的方式工作。这种方式并不能满足很多现实应用的需求，譬如：

监控系统：后台硬件热插拔、LED、温度、电压发生变化；
即时通信系统：其它用户登录、发送信息；
即时报价系统：后台数据库内容发生变化；

这些应用都需要服务器能实时地将更新的信息传送到客户端，而无须客户端发出请求。“服务器推”技术在现实应用中有一些解决方案，本文将这些解决方案分为两类：一类需要在浏览器端安装插件，基于套接口传送信息，或是使用 RMI、CORBA 进行远程调用；而另一类则无须浏览器安装任何插件、基于 HTTP 长连接。

将“服务器推”应用在 Web 程序中，首先考虑的是如何在功能有限的浏览器端接收、处理信息：

客户端如何接收、处理信息，是否需要使用套接口或是使用远程调用。客户端呈现给用户的是 HTML 页面还是 Java applet 或 Flash 窗口。如果使用套接口和远程调用，怎么和 JavaScript 结合修改 HTML 的显示。
客户与服务器端通信的信息格式，采取怎样的出错处理机制。
客户端是否需要支持不同类型的浏览器如 IE、Firefox，是否需要同时支持 Windows 和 Linux 平台。

回页首

基于客户端套接口的“服务器推”技术

Flash XMLSocket

如果 Web 应用的用户接受应用只有在安装了 Flash 播放器才能正常运行，那么使用 Flash 的 XMLSocket 也是一个可行的方案。

这种方案实现的基础是：

Flash 提供了 XMLSocket 类。
JavaScript 和 Flash 的紧密结合：在 JavaScript 可以直接调用 Flash 程序提供的接口。

具体实现方法：在 HTML 页面中内嵌入一个使用了 XMLSocket 类的 Flash 程序。JavaScript 通过调用此 Flash 程序提供的套接口接口与服务器端的套接口进行通信。JavaScript 在收到服务器端以 XML 格式传送的信息后可以很容易地控制 HTML 页面的内容显示。

关于如何去构建充当了 JavaScript 与 Flash XMLSocket 桥梁的 Flash 程序，以及如何在 JavaScript 里调用 Flash 提供的接口，我们可以参考 AFLAX（Asynchronous Flash and XML）项目提供的 Socket Demo 以及 SocketJS（请参见参考资源）。

Javascript 与 Flash 的紧密结合，极大增强了客户端的处理能力。从 Flash 播放器 V7.0.19 开始，已经取消了 XMLSocket 的端口必须大于 1023 的限制。Linux 平台也支持 Flash XMLSocket 方案。但此方案的缺点在于：

客户端必须安装 Flash 播放器；
因为 XMLSocket 没有 HTTP 隧道功能，XMLSocket 类不能自动穿过防火墙；
因为是使用套接口，需要设置一个通信端口，防火墙、代理服务器也可能对非 HTTP 通道端口进行限制；

不过这种方案在一些网络聊天室，网络互动游戏中已得到广泛使用。

Java Applet 套接口

在客户端使用 Java Applet，通过 java.net.Socket 或 java.net.DatagramSocket 或 java.net.MulticastSocket 建立与服务器端的套接口连接，从而实现“服务器推”。

这种方案最大的不足在于 Java applet 在收到服务器端返回的信息后，无法通过 JavaScript 去更新 HTML 页面的内容。

回页首

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

Comet 简介

浏览器作为 Web 应用的前台，自身的处理功能比较有限。浏览器的发展需要客户端升级软件，同时由于客户端浏览器软件的多样性，在某种意义上，也影响了浏览器新技术的推广。在 Web 应用中，浏览器的主要工作是发送请求、解析服务器返回的信息以不同的风格显示。AJAX 是浏览器技术发展的成果，通过在浏览器端发送异步请求，提高了单用户操作的响应性。但 Web 本质上是一个多用户的系统，对任何用户来说，可以认为服务器是另外一个用户。现有 AJAX 技术的发展并不能解决在一个多用户的 Web 应用中，将更新的信息实时传送给客户端，从而用户可能在“过时”的信息下进行操作。而 AJAX 的应用又使后台数据更新更加频繁成为可能。

图 1. 传统的 Web 应用模型与基于 AJAX 的模型之比较

“服务器推”是一种很早就存在的技术，以前在实现上主要是通过客户端的套接口，或是服务器端的远程调用。因为浏览器技术的发展比较缓慢，没有为“服务器推”的实现提供很好的支持，在纯浏览器的应用中很难有一个完善的方案去实现“服务器推”并用于商业程序。最近几年，因为 AJAX 技术的普及，以及把 IFrame 嵌在“htmlfile“的 ActiveX 组件中可以解决 IE 的加载显示问题，一些受欢迎的应用如 meebo，gmail+gtalk 在实现中使用了这些新技术；同时“服务器推”在现实应用中确实存在很多需求。因为这些原因，基于纯浏览器的“服务器推”技术开始受到较多关注，Alex Russell（Dojo Toolkit 的项目 Lead）称这种基于 HTTP 长连接、无须在浏览器端安装插件的“服务器推”技术为“Comet”。目前已经出现了一些成熟的 Comet 应用以及各种开源框架；一些 Web 服务器如 Jetty 也在为支持大量并发的长连接进行了很多改进。关于 Comet 技术最新的发展状况请参考关于 Comet 的 wiki。

下面将介绍两种 Comet 应用的实现模型。

基于 AJAX 的长轮询（long-polling）方式

如图 1 所示，AJAX 的出现使得 JavaScript 可以调用 XMLHttpRequest 对象发出 HTTP 请求，JavaScript 响应处理函数根据服务器返回的信息对 HTML 页面的显示进行更新。使用 AJAX 实现“服务器推”与传统的 AJAX 应用不同之处在于：

服务器端会阻塞请求直到有数据传递或超时才返回。
客户端 JavaScript 响应处理函数会在处理完服务器返回的信息后，再次发出请求，重新建立连接。
当客户端处理接收的数据、重新建立连接时，服务器端可能有新的数据到达；这些信息会被服务器端保存直到客户端重新建立连接，客户端会一次把当前服务器端所有的信息取回。

图 2. 基于长轮询的服务器推模型

一些应用及示例如 “Meebo”, “Pushlet Chat” 都采用了这种长轮询的方式。相对于“轮询”（poll），这种长轮询方式也可以称为“拉”（pull）。因为这种方案基于 AJAX，具有以下一些优点：请求异步发出；无须安装插件；IE、Mozilla FireFox 都支持 AJAX。

在这种长轮询方式下，客户端是在 XMLHttpRequest 的 readystate 为 4（即数据传输结束）时调用回调函数，进行信息处理。当 readystate 为 4 时，数据传输结束，连接已经关闭。Mozilla Firefox 提供了对 Streaming AJAX 的支持，即 readystate 为 3 时（数据仍在传输中），客户端可以读取数据，从而无须关闭连接，就能读取处理服务器端返回的信息。IE 在 readystate 为 3 时，不能读取服务器返回的数据，目前 IE 不支持基于 Streaming AJAX。

基于 Iframe 及 htmlfile 的流（streaming）方式

iframe 是很早就存在的一种 HTML 标记，通过在 HTML 页面里嵌入一个隐蔵帧，然后将这个隐蔵帧的 SRC 属性设为对一个长连接的请求，服务器端就能源源不断地往客户端输入数据。

图 3. 基于流方式的服务器推模型

上节提到的 AJAX 方案是在 JavaScript 里处理 XMLHttpRequest 从服务器取回的数据，然后 Javascript 可以很方便的去控制 HTML 页面的显示。同样的思路用在 iframe 方案的客户端，iframe 服务器端并不返回直接显示在页面的数据，而是返回对客户端 Javascript 函数的调用，如“<script type="text/javascript">js_func(“data from server ”)</script>”。服务器端将返回的数据作为客户端 JavaScript 函数的参数传递；客户端浏览器的 Javascript 引擎在收到服务器返回的 JavaScript 调用时就会去执行代码。

从图 3 可以看到，每次数据传送不会关闭连接，连接只会在通信出现错误时，或是连接重建时关闭（一些防火墙常被设置为丢弃过长的连接，服务器端可以设置一个超时时间，超时后通知客户端重新建立连接，并关闭原来的连接）。

使用 iframe 请求一个长连接有一个很明显的不足之处：IE、Morzilla Firefox 下端的进度栏都会显示加载没有完成，而且 IE 上方的图标会不停的转动，表示加载正在进行。Google 的天才们使用一个称为“htmlfile”的 ActiveX 解决了在 IE 中的加载显示问题，并将这种方法用到了 gmail+gtalk 产品中。Alex Russell 在 “What else is burried down in the depth's of Google's amazing JavaScript?”文章中介绍了这种方法。Zeitoun 网站提供的 comet-iframe.tar.gz，封装了一个基于 iframe 和 htmlfile 的 JavaScript comet 对象，支持 IE、Mozilla Firefox 浏览器，可以作为参考。（请参见参考资源）

使用 Comet 模型开发自己的应用

上面介绍了两种基于 HTTP 长连接的“服务器推”架构，更多描述了客户端处理长连接的技术。对于一个实际的应用而言，系统的稳定性和性能是非常重要的。将 HTTP 长连接用于实际应用，很多细节需要考虑。

不要在同一客户端同时使用超过两个的 HTTP 长连接

我们使用 IE 下载文件时会有这样的体验，从同一个 Web 服务器下载文件，最多只能有两个文件同时被下载。第三个文件的下载会被阻塞，直到前面下载的文件下载完毕。这是因为 HTTP 1.1 规范中规定，客户端不应该与服务器端建立超过两个的 HTTP 连接，新的连接会被阻塞。而 IE 在实现中严格遵守了这种规定。

HTTP 1.1 对两个长连接的限制，会对使用了长连接的 Web 应用带来如下现象：在客户端如果打开超过两个的 IE 窗口去访问同一个使用了长连接的 Web 服务器，第三个 IE 窗口的 HTTP 请求被前两个窗口的长连接阻塞。

所以在开发长连接的应用时，必须注意在使用了多个 frame 的页面中，不要为每个 frame 的页面都建立一个 HTTP 长连接，这样会阻塞其它的 HTTP 请求，在设计上考虑让多个 frame 的更新共用一个长连接。

服务器端的性能和可扩展性

一般 Web 服务器会为每个连接创建一个线程，如果在大型的商业应用中使用 Comet，服务器端需要维护大量并发的长连接。在这种应用背景下，服务器端需要考虑负载均衡和集群技术；或是在服务器端为长连接作一些改进。

应用和技术的发展总是带来新的需求，从而推动新技术的发展。HTTP 1.1 与 1.0 规范有一个很大的不同：1.0 规范下服务器在处理完每个 Get/Post 请求后会关闭套接口连接；而 1.1 规范下服务器会保持这个连接，在处理两个请求的间隔时间里，这个连接处于空闲状态。 Java 1.4 引入了支持异步 IO 的 java.nio 包。当连接处于空闲时，为这个连接分配的线程资源会返还到线程池，可以供新的连接使用；当原来处于空闲的连接的客户发出新的请求，会从线程池里分配一个线程资源处理这个请求。这种技术在连接处于空闲的机率较高、并发连接数目很多的场景下对于降低服务器的资源负载非常有效。

但是 AJAX 的应用使请求的出现变得频繁，而 Comet 则会长时间占用一个连接，上述的服务器模型在新的应用背景下会变得非常低效，线程池里有限的线程数甚至可能会阻塞新的连接。Jetty 6 Web 服务器针对 AJAX、Comet 应用的特点进行了很多创新的改进，请参考文章“AJAX，Comet and Jetty”（请参见参考资源）。

控制信息与数据信息使用不同的 HTTP 连接

使用长连接时，存在一个很常见的场景：客户端网页需要关闭，而服务器端还处在读取数据的堵塞状态，客户端需要及时通知服务器端关闭数据连接。服务器在收到关闭请求后首先要从读取数据的阻塞状态唤醒，然后释放为这个客户端分配的资源，再关闭连接。

所以在设计上，我们需要使客户端的控制请求和数据请求使用不同的 HTTP 连接，才能使控制请求不会被阻塞。

在实现上，如果是基于 iframe 流方式的长连接，客户端页面需要使用两个 iframe，一个是控制帧，用于往服务器端发送控制请求，控制请求能很快收到响应，不会被堵塞；一个是显示帧，用于往服务器端发送长连接请求。如果是基于 AJAX 的长轮询方式，客户端可以异步地发出一个 XMLHttpRequest 请求，通知服务器端关闭数据连接。

在客户和服务器之间保持“心跳”信息

在浏览器与服务器之间维持一个长连接会为通信带来一些不确定性：因为数据传输是随机的，客户端不知道何时服务器才有数据传送。服务器端需要确保当客户端不再工作时，释放为这个客户端分配的资源，防止内存泄漏。因此需要一种机制使双方知道大家都在正常运行。在实现上：

服务器端在阻塞读时会设置一个时限，超时后阻塞读调用会返回，同时发给客户端没有新数据到达的心跳信息。此时如果客户端已经关闭，服务器往通道写数据会出现异常，服务器端就会及时释放为这个客户端分配的资源。
如果客户端使用的是基于 AJAX 的长轮询方式；服务器端返回数据、关闭连接后，经过某个时限没有收到客户端的再次请求，会认为客户端不能正常工作，会释放为这个客户端分配、维护的资源。
当服务器处理信息出现异常情况，需要发送错误信息通知客户端，同时释放资源、关闭连接。

Pushlet - 开源 Comet 框架

Pushlet 是一个开源的 Comet 框架，在设计上有很多值得借鉴的地方，对于开发轻量级的 Comet 应用很有参考价值。

观察者模型

Pushlet 使用了观察者模型：客户端发送请求，订阅感兴趣的事件；服务器端为每个客户端分配一个会话 ID 作为标记，事件源会把新产生的事件以多播的方式发送到订阅者的事件队列里。

客户端 JavaScript 库

pushlet 提供了基于 AJAX 的 JavaScript 库文件用于实现长轮询方式的“服务器推”；还提供了基于 iframe 的 JavaScript 库文件用于实现流方式的“服务器推”。

JavaScript 库做了很多封装工作：

定义客户端的通信状态：STATE_ERROR、STATE_ABORT、STATE_NULL、STATE_READY、STATE_JOINED、STATE_LISTENING；
保存服务器分配的会话 ID，在建立连接之后的每次请求中会附上会话 ID 表明身份；
提供了 join()、leave()、subscribe()、 unsubsribe()、listen() 等 API 供页面调用；
提供了处理响应的 JavaScript 函数接口 onData()、onEvent()…

网页可以很方便地使用这两个 JavaScript 库文件封装的 API 与服务器进行通信。

客户端与服务器端通信信息格式

pushlet 定义了一套客户与服务器通信的信息格式，使用 XML 格式。定义了客户端发送请求的类型：join、leave、subscribe、unsubscribe、listen、refresh；以及响应的事件类型：data、join_ack、listen_ack、refresh、heartbeat、error、abort、subscribe_ack、unsubscribe_ack。

服务器端事件队列管理

pushlet 在服务器端使用 Java Servlet 实现，其数据结构的设计框架仍可适用于 PHP、C 编写的后台客户端。

Pushlet 支持客户端自己选择使用流、拉（长轮询）、轮询方式。服务器端根据客户选择的方式在读取事件队列（fetchEvents）时进行不同的处理。“轮询”模式下 fetchEvents() 会马上返回。”流“和”拉“模式使用阻塞的方式读事件，如果超时，会发给客户端发送一个没有新信息收到的“heartbeat“事件，如果是“拉”模式，会把“heartbeat”与“refresh”事件一起传给客户端，通知客户端重新发出请求、建立连接。

客户服务器之间的会话管理

服务端在客户端发送 join 请求时，会为客户端分配一个会话 ID，并传给客户端，然后客户端就通过此会话 ID 标明身份发出 subscribe 和listen 请求。服务器端会为每个会话维护一个订阅的主题集合、事件队列。

服务器端的事件源会把新产生的事件以多播的方式发送到每个会话（即订阅者）的事件队列里。

小结

本文介绍了如何在现有的技术基础上选择合适的方案开发一个“服务器推”的应用，最优的方案还是取决于应用需求的本身。相对于传统的 Web 应用，目前开发 Comet 应用还是具有一定的挑战性。

“服务器推”存在广泛的应用需求，为了使 Comet 模型适用于大规模的商业应用，以及方便用户构建 Comet 应用，最近几年，无论是服务器还是浏览器都出现了很多新技术，同时也出现了很多开源的 Comet 框架、协议。需求推动技术的发展，相信 Comet 的应用会变得和 AJAX 一样普及。

转自：http://www.ibm.com/developerworks/cn/web/wa-lo-comet/

一篇文章：

消息推送系统

当一个初学Web开发的童鞋，产生让服务器“主动”给浏览器客户端发送数据的想法的时候，比他入门稍早的同学会说：

“这是Web！只能由浏览器发起请求，然后得到服务器返回的数据。”

可能接触得更多的童鞋会说：

“除非你用Javascript轮询/心跳，不断请求服务器看有没有新的数据。但是用户多了服务器会受不了。”

都没错。

但主动推送数据非是不可实现的。聪明的先驱们已经找到了更优的解决方案，那就是利用http长连接来实现消息推送系统。

消息推送系统又叫服务器推、Comet技术、Push Server、Server Push等等。它们的含义大同小异，只是从不同场景中得来的不同的称呼而已，具体可以google。我个人比较喜欢Push Server这个名称，很形象——用来向客户端push消息的这么一个server，就叫Push Server。

消息推送系统是一个很有魔力的技术，它实现了攻受的颠倒和权力的反转。服务器不用再傻乎乎地等待着客户端的请求才能发送最新的数据，而是占据了主动，当有新数据的时候，服务器可以立即主动地将数据push给相关的客户端。

想一想，这个时候，你就可以push消息指挥客户端的Javascript做任何事，所有用户的页面都是你的线控木偶了。话说萝莉有三宝，轻音柔体易推倒。Web相比传统软件来说，也算是轻音柔体的萝莉了，而这里的Push Server，也就是推倒萝莉之术了:P 。

推倒萝莉之后，可以做什么呢？当然是很fancy的事情了：

在线好友列表
在线聊天（聊天室、点对点，多人聊天）
即时通知
统计、监控在线用户
实时内容更新

这里要讲的Push Server，是由Javascript + Python(Tornado) + Memcache实现的。但文章中会着重介绍实现原理，而非具体的代码。

Push Server主要包含以下几个方面：

http长连接
Javascript 的 CORS (The Cross-Origin Resource Sharing)与跨浏览器实现
服务器异步响应
客户端的链接与断开
性能何如

后面的文章会慢慢解来。

这里我们从系统结构的层面来看消息推送系统（Push Server）的基本原理。

首先需要了解几个基本的概念：

HTTP长连接

翻译自http keep-alive connection和http persistent connection，又叫http connection reuse，网上也有反过来翻译成http long connection。

下面这个图来自wikipedia，讲解了http长连接是在一个TCP连接的基础之上，发送多个HTTP请求以及接收多个HTTP响应，这是为了避免每一次请求都去打开一个新的连接。在HTTP 1.1标准中，所有的请求都认为是长连接。

在这里的消息推送系统中，HTTP长连接的作用就是向服务器发送请求，然后一直等待服务器的返回数据。这就相当于客户端在“监听”服务器了，可以随时接收来自服务器的消息。OK，lolita is ready to be pushed!

同步与异步

同步：IO操作将导致请求进程阻塞，直到IO操作完成。也就是说客户端在发送请求后，必须得在服务端有回应后才发送下一个请求。

异步：IO操作不导致请求进程阻塞。也就是说客户端在发送请求后，不必等待服务端的回应就可以发送下一个请求。

同步与异步说的是客户端与服务器端之间的一种通信方式。

阻塞与非阻塞

阻塞：服务器端的线程或者进程没有处理完数据的时候，不会返回，线程或者进程回被挂起，不再响应其他请求。

非阻塞：服务器端在没有处理完的时候，会立即返回，不会挂起线程或者进程，可以继续响应其他请求。

阻塞与非阻塞说的是服务器端对请求的处理方式。

在消息推送系统中，客户端+服务器端一起，使用的是异步非阻塞。

消息推送系统（Push Server）的结构和原理

好了，接下来是就是消息推送系统（Push Server）的结构和原理了：

客户端发出一个http长连接请求，然后等待服务器的响应。这个请求是异步的，所以客户端可以继续工作，比如发起其他ajax请求等等。这个时候客户端就是一个待推倒的小萝莉了。
服务器接到请求之后，并不立即发送出数据，而是hold住这个connecton。这个处理是非阻塞的，所以服务器可以继续处理其他请求。
在某个时刻，比如服务器有新数据了，服务器再主动把这个消息推送出去，即通过之前建立好的连接将数据推送给客户端。
客户端收到返回。这个时候就可以处理数据，然后再次发起新的长连接。

基本原理就是这么简单。

但是在具体实现的时候，还有很多细节要处理，需要一些其他的技术。

下一篇会讲解客户端Javascript的实现，主要内容是HTTP长连接的建立和CORS在不同浏览器下的实现。

参考资料