转自：http://www.cnblogs.com/wodemeng/archive/2012/04/06/2435302.html
今天晚上朋友遇到web服务端推技术的问题，自己就查了下资料，学习了下
源代码：http://files.cnblogs.com/wodemeng/AspNetComet.zip
Comet 有时也称反向 Ajax 或服务器端推技术（server-side push）。其思想很简单：将数据直接从服务器推到浏览器，而不必等到浏览器请求数据。
=============大体说明=======================
Ajax 的出现使 Comet 成为可能。HTTP 的单向性质可以有效地加以规避。实际上有一些不同的方法可以绕过这一点。您可能已经猜到，支持 Comet 的最容易的方式是轮询（poll）。使用 XMLHttpRequest 向服务器发出调用，返回后，等待一段固定的时间（通常使用 JavaScript 的 setTimeout 函数），然后再次调用。这是一项非常常见的技术。例如，大多数 webmail 应用程序就是通过这种技术在电子邮件到达时显示电子邮件的。
这项技术有优点也有缺点。在这种情况下，您期望快速返回响应，就像任何其他 Ajax 请求一样。在请求之间必须有一段暂停。否则，连续不断的请求会冲垮服务器，并且这种情况下显然不具有可伸缩性。这段暂停使应用程序产生一个延时。暂停的时间越长，服务器上的新数据就需要越多的时间才能到达客户机。如果缩短暂停时间，又将重新面临冲垮服务器的风险。但是另一方面，这显然是最简单的实现 Comet 的方式。
现在应该指出，很多人认为轮询并不属于 Comet。相反，他们认为 Comet 是对轮询的局限性的一个解决方案。最常见的 “真正的” Comet 技术是轮询的一种变体，即长轮询（long polling）。轮询与长轮询之间的主要区别在于服务器花多长的时间作出响应。长轮询通常将连接保持一段较长的时间 — 通常是数秒钟，但是也可能是一分钟甚至更长。当服务器上发生某个事件时，响应被发送并随即关闭，轮询立即重新开始。
长轮询相对于一般轮询的优点在于，数据一旦可用，便立即从服务器发送到客户机。请求可能等待较长的时间，期间没有任何数据返回，但是一旦有了新的数据，它将立即被发送到客户机。因此没有延时。如果您使用过基于 Web 的聊天程序，或者声称 “实时” 的任何程序，那么它很可能就是使用了这种技术。
长轮询有一种变体，这是第三种风格的 Comet。这通常被称为流（streaming）。按照这种风格，服务器将数据推回客户机，但是不关闭连接。连接将一直保持开启，直到过期，并导致重新发出请求。XMLHttpRequest 规范表明，可以检查 readyState 的值是否为 3 或 Receiving（而不是 4 或 Loaded），并获取正从服务器 “流出” 的数据。和长轮询一样，这种方式也没有延时。当服务器上的数据就绪时，该数据被发送到客户机。这种方式的另一个优点是可以大大减少发送到服务器的请求，从而避免了与设置服务器连接相关的开销和延时。不幸的是，XMLHttpRequest 在不同的浏览器中有很多不同的实现。这项技术只能在较新版本的 Mozilla Firefox 中可靠地使用。对于 Internet Explorer 或 Safari，仍需使用长轮询。
至此，您可能会想，长轮询和流都有一个很大的问题。请求需要在服务器上存在一段较长的时间。这打破了每个请求使用一个线程的模型，因为用于一个请求的线程一直没有被释放。更糟糕的是，除非要发回数据，否则该线程一直处于空闲状态。这显然不具有可伸缩性。幸运的是，现代 Web 服务器有很多方式可以解决这个问题。
=============各个知识点的介绍=======================
我们要了解反向Ajax、轮询（polling）、流（streaming）、Comet和长轮询（long polling），学习如何实现不同的反向Ajax通信技术，并探讨每种方法的优点和缺点。
Ajax、反向Ajax和WebSocket
异步的JavaScript和XML（Asynchronous JavaScript and XML，Ajax），一种可通过JavaScript来访问的浏览器功能特性，其允许脚本向幕后的网站发送一个HTTP请求而又无需重新加载页面。Ajax的出现已经超过了十年，尽管其名字中包含了XML，但你几乎可以在Ajax请求中传送任何的东西，最常用的数据是JSON，其与JavaScript语法很接近，且消耗更少带宽。清单1给出了这样的一个例子，Ajax请求通过某个地方的邮政编码来检索该地的名称。
清单1. Ajax请求举例
+ $('#postalCode').val() +'&country='
+ $('#country').val() +'&callback=?';
$.getJSON(url, function(data) {
$('#placeName').val(data.postalcodes[0].placeName);
});
在本文可下载的源代码中，你可在listing1.html中看到这一例子的作用。
反向Ajax（Reverse Ajax）本质上则是这样的一种概念：能够从服务器端向客户端发送数据。在一个标准的HTTP Ajax请求中，数据是发送给服务器端的，反向Ajax可以某些特定的方式来模拟发出一个Ajax请求，这些方式本文都会论及，这样的话，服务器就可以尽可能快地向客户端发送事件（低延迟通信）。
WebSocket技术来自HTML5，是一种最近才出现的技术，许多浏览器已经支持它（Firefox、Google Chrome、Safari等等）。WebSocket启用双向的、全双工的通信信道，其通过某种被称为WebSocket握手的HTTP请求来打开连接，并用到了一些特殊的报头。连接保持在活动状态，你可以用JavaScript来写和接收数据，就像是正在用一个原始的TCP套接口一样。WebSocket会在这一文章系列的第二部分中谈及。
反向Ajax技术
反向Ajax的目的是允许服务器端向客户端推送信息。Ajax请求在缺省情况下是无状态的，且只能从客户端向服务器端发出请求。你可以通过使用技术模拟服务器端和客户端之间的响应式通信来绕过这一限制。
HTTP轮询和JSONP轮询
轮询（polling）涉及了从客户端向服务器端发出请求以获取一些数据，这显然就是一个纯粹的Ajax HTTP请求。为了尽快地获得服务器端事件，轮询的间隔（两次请求相隔的时间）必须尽可能地小。但有这样的一个缺点存在：如果间隔减小的话，客户端浏览器就会发出更多的请求，这些请求中的许多都不会返回任何有用的数据，而这将会白白地浪费掉带宽和处理资源。
图1中的时间线说明了客户端发出了某些轮询请求，但没有信息返回这种情况，客户端必须要等到下一个轮询来获取两个服务器端接收到的事件。
图1. 使用HTTP轮询的反向Ajax
JSONP轮询基本上与HTTP轮询一样，不同之处则是JSONP可以发出跨域请求（不是在你的域内的请求）。清单1使用JSONP来通过邮政编码获取地名，JSONP请求通常可通过它的回调参数和返回内容识别出来，这些内容是可执行的JavaScript代码。
要在JavaScript中实现轮询的话，你可以使用setInterval来定期地发出Ajax请求，如清单2所示：
清单2. JavaScript轮询
$.getJSON('events', function(events) {
console.log(events);
});
}, 2000);
文章源代码中的轮询演示给出了轮询方法所消耗的带宽，间隔很小，但可以看到有些请求并未返回事件，清单3给出了这一轮询示例的输出。
清单3. 轮询演示例子的输出
[client] no event
[client] checking for events...
[client]2 events
[event] At Sun Jun 0515:17:14 EDT 2011
[event] At Sun Jun 0515:17:14 EDT 2011
[client] checking for events...
[client]1 events
[event] At Sun Jun 0515:17:16 EDT 2011
用JavaScript实现的轮询的优点和缺点：
1. 优点：很容易实现，不需要任何服务器端的特定功能，且在所有的浏览器上都能工作。
2. 缺点：这种方法很少被用到，因为它是完全不具伸缩性的。试想一下，在100个客户端每个都发出2秒钟的轮询请求的情况下，所损失的带宽和资源数量，在这种情况下30%的请求没有返回数据。
Piggyback
捎带轮询（piggyback polling）是一种比轮询更加聪明的做法，因为它会删除掉所有非必需的请求（没有返回数据的那些）。不存在时间间隔，客户端在需要的时候向服务器端发送请求。不同之处在于响应的那部分上，响应被分成两个部分：对请求数据的响应和对服务器事件的响应，如果任何一部分有发生的话。图2给出了一个例子。
图2. 使用了piggyback轮询的反向Ajax
在实现piggyback技术时，通常针对服务器端的所有Ajax请求可能会返回一个混合的响应，文章的下载中有一个实现示例，如下面的清单4所示。
清单4. piggyback代码示例
$.post('ajax', function(data) {
var valid = data.formValid;
// 处理验证结果
// 然后处理响应的其他部分（事件）
processEvents(data.events);
});
});
清单5给出了一些piggyback输出。
清单5. piggyback输出示例
[server] form valid ? true
[client]4 events
[event] At Sun Jun 0516:08:32 EDT 2011
[event] At Sun Jun 0516:08:34 EDT 2011
[event] At Sun Jun 0516:08:34 EDT 2011
[event] At Sun Jun 0516:08:37 EDT 2011
你可以看到表单验证的结果和附加到响应上的事件，同样，这种方法也有着一些优点和缺点：
1. 优点：没有不返回数据的请求，因为客户端对何时发送请求做了控制，对资源的消耗较少。该方法也是可用在所有的浏览器上，不需要服务器端的特殊功能。
2. 缺点：当累积在服务器端的事件需要传送给客户端时，你却一点都不知道，因为这需要一个客户端行为来请求它们。
Comet
使用了轮询或是捎带的反向Ajax非常受限：其不具伸缩性，不提供低延迟通信（只要事件一到达服务器端，它们就以尽可能快的速度到达浏览器端）。Comet是一个web应用模型，在该模型中，请求被发送到服务器端并保持一个很长的存活期，直到超时或是有服务器端事件发生。在该请求完成后，另一个长生存期的Ajax请求就被送去等待另一个服务器端事件。使用Comet的话，web服务器就可以在无需显式请求的情况下向客户端发送数据。
Comet的一大优点是，每个客户端始终都有一个向服务器端打开的通信链路。服务器端可以通过在事件到来时立即提交（完成）响应来把事件推给客户端，或者它甚至可以累积再连续发送。因为请求长时间保持打开的状态，故服务器端需要特别的功能来处理所有的这些长生存期请求。图3给出了一个例子。（这一文章系列的第2部分会更加详细地解释服务器端的约束条件）。
图3. 使用Comet的反向Ajax
Comet的实现可以分成两类：使用流（streaming）的那些和使用长轮询（long polling）的那些。
使用HTTP流的Comet
在流（streaming）模式中，有一个持久连接会被打开。只会存在一个长生存期请求（图3中的#1），因为每个到达服务器端的事件都会通过这同一连接来发送。因此，客户端需要有一种方法来把通过这同一连接发送过来的不同响应分隔开来。从技术上来讲，两种常见的流技术包括Forever Iframe（隐藏的IFrame），或是被用来在JavaScript中创建Ajax请求的XMLHttpRequest对象的多部分（multi-part）特性。
Forever Iframe
Forever Iframe（永存的Iframe）技术涉及了一个置于页面中的隐藏Iframe标签，该标签的src属性指向返回服务器端事件的servlet路径。每次在事件到达时，servlet写入并刷新一个新的script标签，该标签内部带有JavaScript代码，iframe的内容被附加上这一script标签，标签中的内容就会得到执行。
1. 优点：实现简单，在所有支持iframe的浏览器上都可用。
2. 缺点： 没有方法可用来实现可靠的错误处理或是跟踪连接的状态，因为所有的连接和数据都是由浏览器通过HTML标签来处理的，因此你没有办法知道连接何时在哪一端已被断开了。
第二种技术，更可靠一些，是XMLHttpRequest对象上使用某些浏览器（比如说Firefox）支持的multi-part标志。Ajax请求被发送给服务器端并保持打开状态，每次有事件到来时，一个多部分的响应就会通过这同一连接来写入，清单6给出了一个例子。
清单6. 设置Multi-part XMLHttpRequest的JavaScript代码示例
xhr.multipart =true;
xhr.open('GET', 'ajax', true);
xhr.onreadystatechange = function() {
if (xhr.readyState == 4) {
processEvents($.parseJSON(xhr.responseText));
}
};
xhr.send(null);
在服务器端，事情要稍加复杂一些。首先你必须要设置多部分请求，然后挂起连接。清单7展示了如何挂起一个HTTP流请求。（这一系列的第3部分会更加详细地谈及这些API。）
清单7. 使用Servlet 3 API来在servlet中挂起一个HTTP流请求
throws ServletException, IOException {
// 开始请求的挂起
AsyncContext asyncContext = req.startAsync();
asyncContext.setTimeout(0);
// 给客户端发回多部分的分隔符
resp.setContentType("multipart/x-mixed-replace;boundary=""
+ boundary +""");
resp.setHeader("Connection", "keep-alive");
resp.getOutputStream().print("--"+ boundary);
resp.flushBuffer();
// 把异步上下文放在列表中以被将来只用
asyncContexts.offer(asyncContext);
}
现在，每次有事件发生时你都可以遍历所有的挂起连接并向它们写入数据，如清单8所示：
清单8. 使用Servlet 3 API来向挂起的多部分请求发送事件
HttpServletResponse peer = (HttpServletResponse)
asyncContext.getResponse();
peer.getOutputStream().println("Content-Type: application/json");
peer.getOutputStream().println();
peer.getOutputStream().println(new JSONArray()
.put("At "+new Date()).toString());
peer.getOutputStream().println("--"+ boundary);
peer.flushBuffer();
}
本文可下载文件的Comet-straming文件夹中的部分说明了HTTP流，在运行例子并打开主页时，你会看到只要事件一到达服务器端，虽然不同步但它们几乎立刻会出现在页面上。而且，如果打开Firebug控制台的话，你就能看到只有一个Ajax请求是打开的。如果再往下看一些，你会看到JSON响应被附在Response选项卡中，如图4所示：
图4. HTTP流请求的FireBug视图
照例，做法存在着一些优点和缺点：
1. 优点：只打开了一个持久连接，这就是节省了大部分带宽使用率的Comet技术。
2. 缺点：并非所有的浏览器都支持multi-part标志。某些被广泛使用的库，比如说用Java实现的CometD，被报告在缓冲方面有问题。例如，一些数据块（多个部分）可能被缓冲，然后只有在连接完成或是缓冲区已满时才被发送，而这有可能会带来比预期要高的延迟。
使用HTTP长轮询的Comet
长轮询（long polling）模式涉及了打开连接的技术。连接由服务器端保持着打开的状态，只要一有事件发生，响应就会被提交，然后连接关闭。接下来。一个新的长轮询连接就会被正在等待新事件到达的客户端重新打开。
你可以使用script标签或是单纯的XMLHttpRequest对象来实现HTTP长轮询。
script标签
正如iframe一样，其目标是把script标签附加到页面上以让脚本执行。服务器端则会：挂起连接直到有事件发生，接着把脚本内容发送回浏览器，然后重新打开另一个script标签来获取下一个事件。
1. 优点：因为是基于HTML标签的，所有这一技术非常容易实现，且可跨域工作（缺省情况下，XMLHttpRequest不允许向其他域或是子域发送请求）。
2. 缺点：类似于iframe技术，错误处理缺失，你不能获得连接的状态或是有干涉连接的能力。
第二种，也是一种推荐的实现Comet的做法是打开一个到服务器端的Ajax请求然后等待响应。服务器端需要一些特定的功能来允许请求被挂起，只要一有事件发生，服务器端就会在挂起的请求中送回响应并关闭该请求，完全就像是你关闭了servlet响应的输出流。然后客户端就会使用这一响应并打开一个新的到服务器端的长生存期的Ajax请求，如清单9所示：
清单9. 设置长轮询请求的JavaScript代码示例
$.getJSON('ajax', function(events) {
processEvents(events);
long_polling();
});
}
long_polling();
在后端，代码也是使用Servlet 3 API来挂起请求，正如HTTP流的做法一样，但你不需要所有的多部分处理代码，清单10给出了一个例子。
清单10. 挂起一个长轮询Ajax请求
throws ServletException, IOException {
AsyncContext asyncContext = req.startAsync();
asyncContext.setTimeout(0);
asyncContexts.offer(asyncContext);
}
在接收到事件时，只是取出所有的挂起请求并完成它们，如清单11所示：
清单11. 在有事件发生时完成长轮询Ajax请求
AsyncContext asyncContext = asyncContexts.poll();
HttpServletResponse peer = (HttpServletResponse)
asyncContext.getResponse();
peer.getWriter().write(
new JSONArray().put("At " + new Date()).toString());
peer.setStatus(HttpServletResponse.SC_OK);
peer.setContentType("application/json");
asyncContext.complete();
}
在附带的下载源文件中，comet-long-polling文件夹包含了一个长轮询示例web应用，你可以使用 mvn jetty:run 命令来运行它。
1. 优点：客户端很容易实现良好的错误处理系统和超时管理。这一可靠的技术还允许在与服务器端的连接之间有一个往返，即使连接是非持久的（当你的应用有许多的客户端时，这是一件好事）。它可用在所有的浏览器上；你只需要确保所用的XMLHttpRequest对象发送到的简单的Ajax请求就可以了。
2. 缺点：相比于其他技术来说，不存在什么重要的缺点，像所有我们已经讨论过的技术一样，该方法依然依赖于无状态的HTTP连接，其要求服务器端有特殊的功能来临时挂起连接。
建议
因为所有现代的浏览器都支持跨域资源共享（Cross-Origin Resource Share，CORS）规范，该规范允许XHR执行跨域请求，因此基于脚本的和基于iframe的技术已成为了一种过时的需要。
把Comet做为反向Ajax的实现和使用的最好方式是通过XMLHttpRequest对象，该做法提供了一个真正的连接句柄和错误处理。考虑到不是所有的浏览器都支持multi-part标志，且多部分流可能会遇到缓冲问题，因此建议你选择经由HTTP长轮询使用XMLHttpRequest对象（在服务器端挂起的一个简单的Ajax请求）的Comet模式，所有支持Ajax的浏览器也都支持该种做法。
结论
本文提供的是反向Ajax技术的一个入门级介绍，文章探索了实现反向Ajax通信的不同方法，并说明了每种实现的优势和弊端。你的具体情况和应用需求将会影响到你对最合适方法的选择。不过一般来说，如果你想要在低延迟通信、超时和错误检测、简易性，以及所有浏览器和平台的良好支持这几方面有一个最好的折中的话，那就选择使用了Ajax长轮询请求的Comet。
请继续阅读这一系列的第2部分：该部分将会探讨第三种反向Ajax技术：WebSocket。尽管还不是所有的浏览器都支持该技术，但WebSocket肯定是一种非常好的反向Ajax通信媒介，WebSocket消除了所有与HTTP连接的无状态特性相关的限制。第2部分还会谈及由Comet和WebSocket技术带来的服务器端约束。
转自：