长轮询解决方案

长轮询适合浏览器的Chat聊天、股票行情显示、股票状态更新、体育直播的结果显示等。当然，不是所有的例子都是对延迟很敏感的，但它们的需求都比较相似。

在标准的HTTP请求响应语义中，浏览器发起请求，服务器发送一个响应，这意味着在浏览器发起新请求前，服务器不能发送新信息给客户端浏览器。有几种解决方法，包括：传统的轮询、长轮询、HTTP流、WebSocket协议等。

1、传统的轮询

浏览器保持发送请求，检查服务器是否有新信息返回，服务器对于每次请求均应立即响应。这适合的场景下，轮询可以设定为合理的时间间隔。例如，邮件客户端可以每隔10分钟检查服务器是否有新邮件。传统的轮询的优点是简单且工作可靠。然而，其缺点是效率不高。如果需要尽快获得新信息，那么轮询频率就必须非常高。

2、长轮询

浏览器不断发送请求，但是服务器不予以响应，一直到服务器有了新信息才响应客户端。从客户端的角度看它和传统的轮询相同。但从服务器端的角度来看它与传统的轮询相比，减少了服务器端的开销。

那么响应应该保持Open多久呢？浏览器通常对此时间的设置是5分钟，而网络中介（比如代理）对此时间设置的更短。因此，即使服务器端没有新消息，客户端也应该定期发起一个新长轮询请求。IEFT文件建议这个时间间隔在30秒～120秒之间，而实际使用取决于你的网络情况。

IEFT文件： http://tools.ietf.org/html/rfc6202

长轮询可以极大地减少需要低延迟的接收信息更新请求的数量，特别是新信息在无规律的时间间隔变得可用时。但是，如果信息更新的越频繁，那么整个方案就越像传统的轮询。

3、HTTP流

浏览器向服务器发出请求，服务器要发送信息时就会响应。但是它与长轮询不同，服务器需保持响应是Open的，有更新时就会响应客户端。该方法去除了轮询的需要，而且偏离了典型的HTTP请求/响应的语义。例如，客户端和服务器需要协商如何解释响应流，这样客户端会知道哪一个更新信息结束了，哪一个更新信息开始了。但是，网络中介可以缓存响应流，阻挠此方法的意图。这就是为什么长轮询更为常用。

4、WebSocket协议

浏览器发送一个HTTP请求到服务器，请求切换到WebSocket协议，服务器响应，确认升级协议到WebSocket。此后，浏览器和服务器可以在TCP套接字上双向发送数据帧。

WebSocket协议被设计用于取代需要轮询，特别是适用于需要在服务器和浏览器之间频繁交换数据的场景。在HTTP协议上完成初始握手，以确保WebSocket请求可以穿透防火墙。

WebSockets双向交换的数据有两种类型，文本信息或二进制信息。这使得它与RESTful HTTP方法有显著不同。事实上，还有一些其它协议，比如XMPP，AMQP，STOMP等，目前仍在广泛使用。

WebSocket协议已经被IETF组织进行了标准化，而WebSocket API规范也由W3C标准完成了制订。在Java领域也制订了JSR-356规范以支持WebSocket协议。像Jetty、Tomcat这样的Servlet容器也实现了对WebSocket协议的支持。

5、长连接（Persistent Connection）

HTTP Persistent Connection，即HTTP长连接，也叫HTTP Keep-alive或HTTP Connection Reuse。其思想是使用单个的TCP连接来发送和接收多个HTTP请求/响应，而不是为每个请求/响应都建立一个新连接。新发布的HTTP /2协议就使用了这种思想，并进一步允许在单个连接上多路复用多个并发的请求/响应。

而早期的长连接技术只是要求在客户端与服务器之间创建和保持稳定可靠的连接。早期由于浏览器技术发展较缓慢，没有为这种机制的实现提供很好的支持。早期通常的做法是在页面里嵌入一个隐蔵iframe，将这个隐蔵iframe的src属性设为对一个长连接的请求或是采用xhr请求，服务器端就能源源不断地往客户端输入数据。

6、Pushlet

在这种技术中，服务器端利用了HTTP长连接的优点，使得响应总是Open的，即服务器不会终止响应，有效地让浏览器可以在初始页面加载后继续加载其它内容。随后服务器端可以周期性的发送JavaScript代码片段来更新页面的内容，从而达到推动能力。通过使用这种技术，客户端不需要Java Applet或其它插件才能保持与服务器的连接Open；客户端会对服务器推送的新事件自动通知。其缺点是服务器端缺少对浏览器端的超时控制，如果浏览器发生超时，必须使用页面刷新。

Pushlets的官方站点： http://www.pushlets.com/

Pushlet从2000年发展到2010年，逐渐淡出市场。