http://www.ibm.com/developerworks/cn/web/wa-lo-comet/
http://www.ibm.com/developerworks/cn/java/j-lo-comet/
在网上查了一下资料，发现轮询和长轮询还有不同的定义：
-
轮询：客户端定时向服务器发送Ajax请求，服务器接到请求后马上返回响应信息并关闭连接。
优点：后端程序编写比较容易。
缺点：请求中有大半是无用，浪费带宽和服务器资源。
实例：适于小型应用。 -
长轮询：客户端向服务器发送Ajax请求，服务器接到请求后hold住连接，直到有新消息才返回响应信息并关闭连接，客户端处理完响应信息后再向服务器发送新的请求。
优点：在无消息的情况下不会频繁的请求。
缺点：服务器hold连接会消耗资源。
实例：WebQQ、Hi网页版、Facebook IM。
另外，对于长连接和socket连接也有区分：
-
长连接：在页面里嵌入一个隐蔵iframe，将这个隐蔵iframe的src属性设为对一个长连接的请求，服务器端就能源源不断地往客户端输入数据。
优点：消息即时到达，不发无用请求。
缺点：服务器维护一个长连接会增加开销。
实例：Gmail聊天 -
Flash Socket：在页面中内嵌入一个使用了Socket类的 Flash 程序JavaScript通过调用此Flash程序提供的Socket接口与服务器端的Socket接口进行通信，JavaScript在收到服务器端传送的信息后控制页面的显示。
优点：实现真正的即时通信，而不是伪即时。
缺点：客户端必须安装Flash插件；非HTTP协议，无法自动穿越防火墙。
实例：网络互动游戏。
以上是四种请求方式的介绍和优缺点比较。
长连接工作原理：
从上图可以看出每次数据传送不会关闭连接，连接只会在通信出现错误时，或是连接重建时关闭（一些防火墙常被设置为丢弃过长的连接， 服务器端可以设置一个超时时间， 超时后通知客户端重新建立连接，并关闭原来的连接）。
长轮询工作原理：
长轮询是现在最为常用的方式，和长连接方式的区别就是服务器端在接到请求后挂起，有更新时返回连接即断掉，然后客户端再发起新的连接。
当然现在也有正在弥补以上两种不足的第三种方式WebSocket
不管是长连接还是长轮询，其实都只是单向通信，直到WebSocket的出现，才是B/S之间真正的全双工通信。不过目前WebSocket协议仍在开发中，目前Chrome和Safri浏览器默认支持WebSocket，而FF4和Opera出于安全考虑，默认关闭了WebSocket，IE则不支持（包括9），目前WebSocket协议最新的为“76号草案”。有兴趣可以看以下资料
http://dev.w3.org/html5/websockets/
长轮询的话一般就是间隔一定的时间向服务器请求事件。技术上就是用ajax来实现了。长轮询会造出非常多的请求，不断的请求可能会造成的影响是数据顺序无法得到保证。管理难度较大，好处是对系统的资源占用相对较少。
Comet 实现的方法
- 简单轮询
最早期的 Web 应用中，主要通过 JavaScript 或者 Meta HTML 标签等手段，定时刷新页面来检测服务端的变化。显然定时刷新页面服务端仍然在被动响应客户端的请求，只不过客户端的请求是连续、频繁的，让用户看起来产生 有服务端自动将信息发过来的错觉。这种方式简单易行，但缺陷也非常明显：可能大部分请求都是无意义的，因为服务端期待的事件没有发生，实际上并没有需要发 送的信息，而不得不重复的回应着页面上所有内容给浏览器；另外就是当服务端发生变化时，并不能“实时”的返回，刷新的间隔太短，产生很大的性能浪费，间隔 太长，事件通知又可能晚于用户期望的时间到达。
当绝大部分浏览器提供了 XHR（XmlHttpRequest）对象支持后，Ajax 技术出现并迅速流行，这一阶段做的轮询就不必每次都返回都返回整个页面中所有的内容，如果服务端没有事件产生，只需要返回极少量内容的 http 报文体。Ajax 可以节省轮询传输中大量的带宽浪费，但它无法减少请求的次数，因此 Ajax 实现的简单轮询仍然有轮询的局限性，对其缺陷只能一定程度缓解，而无法达到质变。
- 长轮询（混合轮询）
长轮询与简单轮询的最大区别就是连接时间的长短：简单轮询时当页面输出完连接就关闭了，而长轮询一般会保持 30 秒乃至更长时间，当服务器上期待的事件发生，将会立刻输出事件通知到客户端，接着关闭连接，同时建立下一个连接开始一次新的长轮询。
长轮询的实现方式优势在于当服务端期待事件发生，数据便立即返回到客户端，期间没有数据返回，再较长的等待时间内也没有新的请求发生，这样可以让发送的请求减少很多，而事件通知的灵敏度却大幅提高到几乎是“实时”的程度。
- Comet 流（Forever Frame）
Comet 流是按照长轮询的实现思路进一步发展的产物。令长轮询将事件通知发送回客户端后不再关闭连接，而是一直保持直到超时事件发生才重新建立新的连接，这种变体 我们就称为 Comet 流。客户端可以使用 XmlHttpRequest 对象中的 readyState 属性来判断是 Receiving 还是 Loaded。Comet 流理论上可以使用一个链接来处理若干次服务端事件通知，更进一步节省了发送到服务端的请求次数。
无论是长轮询还是 Comet 流，在服务端和客户端都需要维持一个比较长时间的连接状态，这一点在客户端不算什么太大的负担，但是服务端是要同时对多个客户端服务的，按照经典 Request-Response 交互模型，每一个请求都占用一个 Web 线程不释放的话，Web 容器的线程则会很快消耗殆尽，而这些线程大部分时间处于空闲等待的状态。这也就是为什么 Comet 风格服务非常期待异步处理的原因，希望 Web 线程不需要同步的、一对一的处理客户端请求，能做到一个 Web 线程处理多个客户端请求。