Web应用使用了HTTP协议，我们知道在HTTP协议中，基本的动作get/post/put/options/delete等，这些动作里基本的模式都是客户端请求，服务端响应。这样的交互模式中，服务端是无法推送信息到客户端的？那应该采取什么样的交互措施呢？
简单轮询
基本的实现方式polling，简单的讲就是，客户端定时刷新请求的页面。比如邮件客户端，每隔10分钟左右刷新一次页面。
处理方式：
长轮询
客户端向服务器发送Ajax请求，服务器接到请求后hold住连接，直到有新消息才返回响应信息并关闭连接，客户端处理完响应信息后再向服务器发送新的请求。这样在无消息的情况西，避免了频繁的发送请求。但是服务端保持连接会消耗资源。基本的应用场景中，WebQQ、Hi网页版、Facebook IM等。
长连接
长连接：在页面里嵌入一个隐蔵iframe，将这个隐蔵iframe的src属性设为对一个长连接的请求，服务器端就能源源不断地往客户端输入数据。：消息即时到达，不发无用请求。服务器维护一个长连接会增加开销。
长连接的技术主要是用Comet，采用的技术分浏览器来实现，ie上用iframe，别的浏览器用xhr来实现。长连接主要是由于对服务器的资源会有一个占用，所以相对开销会比较大，好处是即时性非常好，管理起来也相对方便。
长轮询的话一般就是间隔一定的时间向服务器请求事件。技术上就是用ajax来实现了。长轮询会造出非常多的请求，不断的请求可能会造成的影响是数据顺序无法得到保证。管理难度较大，好处是对系统的资源占用相对较少。
How long can the response remain open? Browsers are set to time out after 5 minutes and network intermediaries such as proxies can time out even sooner. So even if no new information arrives, a long polling request should complete regularly to allow the browser to send a new request. This IETF document recommends using a timeout value between 30 and 120 seconds but the actual value to use will likely depend on how much control you have over network intermediaries that separate the browser from server.
Long polling can dramatically reduce the number of requests required to receive information updates with low latency, especially where new information becomes available at irregular intervals. However, the more frequent the updates are the closer it gets to traditional polling.
HTTP Streaming
The browser sends a request to the server and the server responds when it has information to send. However, unlike long polling, the server keeps the response open and continues to send more updates as they arrive. The approach removes the need for polling but is also a more significant departure from typical HTTP request-response semantics. For example the client and server need to agree how to interpret the response stream so that the client will know where one update ends and another begins. Furthermore, network intermediaries can cache the response stream which thwarts the intent of the approach. This is why long polling is more commonly used today.
WebSocket
The browser sends an HTTP request to the server to switch to the WebSocket protocol and the server responds by confirming the upgrade. Thereafter browser and server can send data frames in both directions over a TCP socket.
The WebSocket protocol was designed to replace the need for polling and is specifically suited for scenarios where messages need to be exchanged between browser and server at a high frequency. The initial handshake over HTTP ensures WebSocket requests can go through firewalls. However, there are also significant challenges since a majority of deployed browsers do not support WebSockets and there are further issues with getting through network intermediaries.
WebSockets revolves around the two way exchange of text or binary messages. It leads to a significantly different approach from a RESTful, HTTP-based architecture. In fact there is a need for some another protocol on top of WebSockets, e.g. XMPP, AMQP, STOMP, or other and which one(s) will become predominant remains to be seen.
The WebSocket protocol is already standardized by the IETF while the WebSocket API is in the final stages of being standardized by W3C. A number of Java implementations have become available including servlet containers like Jetty and Tomcat. The Servlet 3.1 spec will likely support the initial WebSocket upgrade request while a separate JSR-356 will define a Java-based WebSocket API.
Coming back to Spring MVC 3.2, the Servlet 3 async feature can be used for long-running requests and also for HTTP streaming, techniques Filip Hanik referred to as “the server version of client AJAX calls”. As for WebSockets, there is no support yet in Spring 3.2 but it will most likely be included in Spring 3.3. You can watch SPR-9356 for progress updates.
The next post turns to sample code and explains in more detail the new Spring MVC 3.2 feature.
HTML5 服务器推送事件（Server-sent Events):
服务器推送事件（Server-sent Events）是 HTML 5 规范中的一个组成部分，可以用来从服务端实时推送数据到浏览器端。相对于与之类似的 COMET 和 WebSocket 技术来说，服务器推送事件的使用更简单，对服务器端的改动也比较小。
