介绍一个服务器端自动向客户端推送信息的框架。在这之前先要了解几个东西，首先是comet

comet介绍

基于 HTTP 长连接的“服务器推”技术，是一种新的 Web 应用架构。基于这种架构开发的应用中，服务器端会主动以异步的方式向客户端程序推送数据，而不需要客户端显式的发出请求。Comet 架构非常适合事件驱动的 Web 应用，以及对交互性和实时性要求很强的应用，如股票交易行情分析、聊天室和 Web 版在线游戏等。

　　服务器推送技术(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)技术不断刷新页面来获得最新的数据(见图18-5)。这种方式不但浪费服务器的资源，最重要的是每次建立(或关闭)新的HTTP连接都 有一定的延迟，这种延迟使得频繁信息传递的应用无法忍受。于是就产生了“服务器推送技术”。

技术对比

浏览器作为 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 浏览器，可以作为参考。

然后要了解的是servlet3.0

Servlet 3.0 新特性概述

Servlet 3.0 作为 Java EE 6 规范体系中一员，随着 Java EE 6 规范一起发布。该版本在前一版本（Servlet 2.5）的基础上提供了若干新特性用于简化 Web 应用的开发和部署。其中有几项特性的引入让开发者感到非常兴奋，同时也获得了 Java 社区的一片赞誉之声：

1. 异步处理支持：有了该特性，Servlet 线程不再需要一直阻塞，直到业务处理完毕才能再输出响应，最后才结束该 Servlet 线程。在接收到请求之后，Servlet 线程可以将耗时的操作委派给另一个线程来完成，自己在不生成响应的情况下返回至容器。针对业务处理较耗时的情况，这将大大减少服务器资源的占用，并且提高 并发处理速度。
2. 新增的注解支持：该版本新增了若干注解，用于简化 Servlet、过滤器（Filter）和监听器（Listener）的声明，这使得 web.xml 部署描述文件从该版本开始不再是必选的了。
3. 可插性支持：熟悉 Struts2 的开发者一定会对其通过插件的方式与包括 Spring 在内的各种常用框架的整合特性记忆犹新。将相应的插件封装成 JAR 包并放在类路径下，Struts2 运行时便能自动加载这些插件。现在 Servlet 3.0 提供了类似的特性，开发者可以通过插件的方式很方便的扩充已有 Web 应用的功能，而不需要修改原有的应用。

接下来是长连接

长连接

所谓长连接，指在一个连接上可以连续发送多个数据包，然后断开连接，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。短连接是指通讯双方有数据交互时，就建立一个连接，数据发送完成后，则断开此连接，即每次连接只完成一项业务的发送。

以前对于客户端向服务端发送信息需要的是使用轮循的解决方案，或者使用ocx做socket连接来实现通信的效果，这对软件本身带来的就是性能问题。

auto-comet的方案及设计思想

设计目标

auto-comet是基于javaEE servlet3.0的comet框架。auto-comet亦在帮助你简单、快速的构建高效、安全的comet服务。

基于异步servlet的auto-comet具有占用服务器资源少且跨平台的优点。

特性

• 支持单向推送
• 可以推送文本格式数据
• 可以用XML配置comet服务
• 可以与Spring整合

通讯协议

1.0特性

• 单向推送

仅支持web服务器向客户端（浏览器Ajax）单向推送数据.客户端不能通过comet通道发送数据给服务器。

• 支持文本格式数据

基于http协议的AutoComet还不支持二进制格式数据.

• 基于服务

与http类似，你可以从url映射到comet服务。一个servelt容器可以提供多个comet服务。服务不与session绑定，同一个浏览器可以同时访问多个相同或不同的服务。

• 通信异常

除去底层的servlet,IO异常，主要有2类超时异常:

1. 客户端超时。比如用户直接关闭浏览器，则大约在1分钟后，服务端会发生一个异常。
2. 服务器端超时，服务器端如果较长时间没有使用一个socket也会发生一个异常，这个时间相对客户端超时较长，大约为1个小时。

auto-comit解决的性能问题

•服务器端保持socket连接需要占用一个线程

•Jetty6.0开始提供了Continuation机制，支持异步Servlet。

•Servlet3.0将异步Servlet API规范化。

•Auto-comet基于Servlet3.0规范。

API设计

与servlet类似，从uri映射到服务

一个socket代表一个连接，可以发送消息

使用者使用handler管理socket

后续考虑加入多框架集成和缓存方案

主要接口

SocketDispatcherServlet控制器，负责将请求转发自对应的handler

UrlHandlerMapping存储uri到handler的映射

SocketManager管理所有的socket

SocketStore用于存储socket

推送示例

通过聊天程序演示的服务端推技术

点击chatRoom

分别用三个用户张三，李四，王五登录然后进行聊天

上面是操作的截图并带有文字说明

功能非常简单就是一个非常常见的聊天程序，目的就是为了说明服务端推技术的处理方案。

如果有对这个项目感兴趣朋友可以加入到群179199183一起进行探讨。