微博的自动提醒【comet基于http协议的长连接、服务器推】

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

监控系统：后台硬件热插拔、LED、温度、电压发生变化；

即时通信系统：其它用户登录、发送信息；

即时报价系统：后台数据库内容发生变化；

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

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

客户端如何接收、处理信息，是否需要使用套接口或是使用远程调用。客户端呈现给用户的是HTML页面还是Javaapplet或Flash窗口。如果使用套接口和远程调用，怎么和JavaScript结合修改HTML的显示。

客户与服务器端通信的信息格式，采取怎样的出错处理机制。

客户端是否需要支持不同类型的浏览器如IE、Firefox，是否需要同时支持Windows和Linux平台。

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

FlashXMLSocket

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

这种方案实现的基础是：

Flash提供了XMLSocket类。

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

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

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

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

客户端必须安装Flash播放器；

因为XMLSocket没有HTTP隧道功能，XMLSocket类不能自动穿过防火墙；

因为是使用套接口，需要设置一个通信端口，防火墙、代理服务器也可能对非HTTP通道端口进行限制；

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

JavaApplet套接口

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

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

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

Comet简介

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

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

“服务器推”是一种很早就存在的技术，以前在实现上主要是通过客户端的套接口，或是服务器端的远程调用。因为浏览器技术的发展比较缓慢，没有为“服务器推”的实现提供很好的支持，在纯浏览器的应用中很难有一个完善的方案去实现“服务器推”并用于商业程序。最近几年，因为AJAX技术的普及，以及把IFrame嵌在“htmlfile“的ActiveX组件中可以解决IE的加载显示问题，一些受欢迎的应用如meebo，gmail+gtalk在实现中使用了这些新技术；同时“服务器推”在现实应用中确实存在很多需求。因为这些原因，基于纯浏览器的“服务器推”技术开始受到较多关注，AlexRussell（DojoToolkit的项目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”,“PushletChat”都采用了这种长轮询的方式。相对于“轮询”（poll），这种长轮询方式也可以称为“拉”（pull）。因为这种方案基于AJAX，具有以下一些优点：请求异步发出；无须安装插件；IE、MozillaFireFox都支持AJAX。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

控制信息与数据信息使用不同的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在服务器端使用JavaServlet实现，其数据结构的设计框架仍可适用于PHP、C编写的后台客户端。

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

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

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

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

小结

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

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