下面介绍一个基于Comet技术实现：基于 HTTP 长连接的“服务器推”技术
服务器推送技术(Server Push)是最近Web技术中最热门的一个流行术语，它的别名叫Comet(彗星)。它是继AJAX之后又一个倍受追捧的Web技术。服务器推送技术最近的流行与AJAX有着密切的关系。
随着Web技术的流行，越来越多的应用从原有的C/S模式转变为B/S模式，享受着Web技术所带来的各种优势(例如跨平台、免客户端维护、跨越防火墙、扩展性好等)。但是基于浏览器的应用，也有它不足的地方。主要在于界面的友好性和交互性。由于浏览器中的页面每次需要全部刷新才能从服务器端获得最新的数据或向服务器传送数据，这样产生的延迟所带来的视觉感受非常糟糕。因此很多的桌面应用为了获得更友好的界面放弃了Web技术，或者采用浏览器的插件技术(ActiveX、Applet、Flash等)。但是浏览器插件技术本身又有许多问题，例如跨平台问题和插件版本兼容性问题。
随着AJAX技术的兴起，让广大开发人员又一次看到了使用浏览器来替代桌面应用的机会，并且这次机会非常大。AJAX将整个页面的刷新变成页面局部的刷新，并且数据的传送是以异步方式进行，这使得网络延迟带来的视觉差异将会消失。AJAX还利用DHTML和丰富的JavasSript语言来模拟桌面系统的各种事件和响应过程，以及平滑滚动和拖拽的效果。还不止这些，更有一些IT巨头(Google、Sun、Oracle等)提供了非常丰富的AJAX开发工具，使得开发和调试AJAX应用变得简单高效，并且开发的AJAX应用还可以跨越各种浏览器和操作系统。在这种情况下基于AJAX的Web应用迅速涌起，吞噬着原有桌面系统的份额。聊天工具、邮件阅读器、博客编辑器，甚至是Office办公软件和文字处理软件在浏览器中都有着美丽的外观和几乎可以与桌面系统媲美的交互界面。Google更是提出“有了浏览器和Google，就不需要微软”的口号和策略。在AJAX的世界中，除了传统的CAD设计软件和大型游戏软件等因为对系统硬件的苛刻需求，还离不开桌面系统以外，似乎其他所有的应用都可以变成Web应用了。
但是，在浏览器中的AJAX应用中存在一个致命的缺陷无法满足传统桌面系统的需求。那就是“服务器发起的消息传递(Server-Initiated Message Delivery)”。在很多的应用当中，服务器软件需要向客户端主动发送消息或信息。因为服务器掌握着系统的主要资源，能够最先获得系统的状态变化和事件的发生。当这些变化发生的时候，服务器需要主动地向客户端实时地发送消息。例如股票的变化。在传统的桌面系统中，这种需求没有任何问题，因为客户端和服务器之间通常存在着持久的连接，这个连接可以双向传递各种数据。而基于HTTP协议的Web应用却不行。上节中也提到过，在Web世界中，服务器永远是被动地发送数据，前提是客户端必须先发送请求。浏览器其实并不知道服务器的信息什么时候会有改变，为了模拟实时的交流，或者不想错过某些信息，只能通过轮询(Polling)技术不断刷新页面来获得最新的数据。这种方式不但浪费服务器的资源，最重要的是每次建立(或关闭)新的HTTP连接都有一定的延迟，这种延迟使得频繁信息传递的应用无法忍受。于是就产生了“服务器推送技术”。
“服务器推送技术”在很久以前就出现过。例如Netscape曾经推出适用于Push技术的专用浏览器和经过修改的HTML语言。但是这仅仅在特定的浏览器中才能使用，其他流行的浏览器(IE等)就不兼容这种技术。
现在的“服务器推送技术”是保持原有的HTTP协议不变，在服务器端改变处理方式，使得服务器能够使用浏览器已经打开的HTTP连接，主动向浏览器发送消息。这里关键的技术是要保持原有的HTTP连接不断。一旦拥有持久的连接，服务器就可以根据自己的数据更新，随时地向客户端发送最新的信息。
在GlassFish中，Grizzly通过NIO的技术实现了异步请求服务(ARP)，并在ARP之上扩展了服务器推送技术的实现，将其也命名为“Comet”。因为使用了NIO，Grizzly才可以在保持HTTP连接的同时，并不会绑定固定的线程，使得GlassFish具有很好的扩展性，可以很好地同时支持大量的Comet请求。下面我们来分析Grizzly中对Comet的实现。
Comet“聊天室”应用
“聊天室”是一个非常典型的Comet应用。通常的“聊天室”至少需要包含两个基本的功能：发送本人的消息和接受显示别人的消息。这里的Comet应用主要是指接受别人的消息。因为别人什么时候发送了消息浏览器是不会知道的，只有聊天服务器本身知道，如果想要将各种消息实时地通知各个客户端，就需要服务器推送技术。
现有的很多“聊天室”大多使用轮询(Polling)技术，来使得浏览器不断自动刷新以获得最新的消息。这种实现方法在并发用户不太多的情况下还能接受。如果并发用户非常多，服务器的负担就会大大地增加。另外每次重新建立连接所带来的延迟也使得用户不能非常及时地获得最新的消息。综合这些因此，对“聊天室”的最佳实现应该使用Comet技术，也就是“服务器推送技术”。
Comet(服务器推送技术)除了用在“聊天室”的应用中之外，目前有很多严肃的商业应用也使用Comet作为“服务器初始消息传递”的解决方案(例如股票系统、拍卖系统等)，来向用户提供纯Web的实时交互系统。通过Comet，基于浏览器的应用进一步吞噬着传统桌面系统的最后一片阵营。
但是服务器推送技术也有一些技术问题，例如长时间的HTTP连接通常会被防火墙关闭；更加严峻的问题是，HTTP 1.1协议出于性能上的考虑，规定浏览器在同一时刻不能与同一个主机保持两个以上的连接。现在主流的浏览器(IE、Mozilla、FireFox等)都遵循这个标准。这意味着如果Comet连接长时间占用了一个HTTP连接的话，那么其他的页面和图像都要通过另外一个唯一的HTTP连接，串行地访问服务器的页面资源。这样带来的延迟会给用户带来很大影响。
不要在同一客户端同时使用超过两个的 HTTP 长连接
我们使用 IE 下载文件时会有这样的体验，从同一个 Web 服务器下载文件，最多只能有两个文件同时被下载。第三个文件的下载会被阻塞，直到前面下载的文件下载完毕。这是因为 HTTP 1.1 规范中规定，客户端不应该与服务器端建立超过两个的 HTTP 连接，新的连接会被阻塞。而 IE 在实现中严格遵守了这种规定。
HTTP 1.1 对两个长连接的限制，会对使用了长连接的Web 应用带来如下现象：在客户端如果打开超过两个的 IE 窗口去访问同一个使用了长连接的 Web 服务器，第三个 IE 窗口的 HTTP 请求被前两个窗口的长连接阻塞。
从目前发展的趋势来看，Comet有着广阔的发展前景。而GlassFish也会成为部署Comet应用最优秀的平台之一。
Gerry