long polling solution
Author: chszs, reprint should be noted. Blog homepage: http://blog.csdn.net/chszs
Long polling for browser-friendly chat, stock ticker display, stock status update, result display of live sports, etc. Of course, not all examples are latency-sensitive, but their needs are relatively similar.
In standard HTTP request-response semantics, the browser initiates the request and the server sends a response, which means that the server cannot send new information to the client browser until the browser initiates a new request. There are several workarounds, including: traditional polling, long polling, HTTP streaming, WebSocket protocol, etc.
1. Traditional polling
The browser keeps sending requests, checking the server for new information to return, and the server should respond immediately to each request. In this suitable scenario, the polling can be set to a reasonable time interval. For example, a mail client could check the server for new mail every 10 minutes. The advantage of traditional polling is simplicity and reliability. However, its disadvantage is that it is not very efficient. If new information needs to be obtained as soon as possible, the polling frequency must be very high.
2. Long polling
The browser keeps sending requests, but the server doesn't respond until the server has new information. From the client's point of view it is the same as traditional polling. But from a server-side perspective it reduces server-side overhead compared to traditional polling.
So how long should the response remain Open? Browsers usually set this time to 5 minutes, and network intermediaries (such as proxies) set this time to be shorter. Therefore, even if there are no new messages on the server side, the client should periodically initiate a new long polling request. The IEFT document recommends this interval to be between 30 seconds and 120 seconds, and actual usage depends on your network conditions.
IEFT document: http://tools.ietf.org/html/rfc6202
Long polling can greatly reduce the number of incoming information update requests that require low latency, especially when new information becomes available at irregular intervals. However, if the information is updated more frequently, the whole scheme becomes more like traditional polling.
3、HTTP流
The browser makes a request to the server, and the server responds when it wants to send information. But it is different from long polling, the server needs to keep the response open, and it will respond to the client when there is an update. This approach removes the need for polling and deviates from typical HTTP request/response semantics. For example, the client and server need to negotiate how to interpret the response stream, so that the client will know which update information ends and which update information begins. However, network intermediaries can cache the response stream, thwarting the intent of this method. This is why long polling is more commonly used.
4. WebSocket protocol
The browser sends an HTTP request to the server, requesting to switch to the WebSocket protocol, and the server responds, confirming the upgrade protocol to WebSocket. After this, the browser and server can send data frames in both directions on the TCP socket.
The WebSocket protocol is designed to replace the need for polling, especially for scenarios where data is frequently exchanged between the server and the browser. The initial handshake is done on the HTTP protocol to ensure that WebSocket requests can penetrate firewalls.
There are two types of data that WebSockets exchange bidirectionally, textual information or binary information. This makes it significantly different from the RESTful HTTP approach. In fact, there are some other protocols, such as XMPP, AMQP, STOMP, etc., which are still widely used.
The WebSocket protocol has been standardized by the IETF organization, and the WebSocket API specification has also been formulated by the W3C standard. In the Java field, the JSR-356 specification has also been developed to support the WebSocket protocol. Servlet containers like Jetty and Tomcat also implement support for the WebSocket protocol.
5. Persistent Connection
HTTP Persistent Connection, that is, HTTP long connection, also called HTTP Keep-alive or HTTP Connection Reuse. The idea is to use a single TCP connection to send and receive multiple HTTP requests/responses, rather than establishing a new connection for each request/response. The newly released HTTP/2 protocol uses this idea and further allows multiplexing of multiple concurrent requests/responses over a single connection.
The early long-connection technology only requires creating and maintaining a stable and reliable connection between the client and the server. In the early days, due to the slow development of browser technology, there was no good support for the implementation of this mechanism. The common practice in the early days is to embed a hidden iframe in the page, set the src attribute of the hidden iframe to a request for a long connection or use an xhr request, and the server can continuously input data to the client.
6、Pushlet
In this technique, the server side takes advantage of HTTP persistent connections so that the response is always Open, that is, the server does not terminate the response, effectively allowing the browser to continue loading other content after the initial page load. Then the server side can periodically send JavaScript code snippets to update the content of the page, so as to achieve the push capability. By using this technique, the client does not need a Java Applet or other plug-ins to keep the connection open to the server; the client is automatically notified of new events pushed by the server. The disadvantage is that the server side lacks the timeout control on the browser side. If the browser times out, the page must be refreshed.
The official site of Pushlets: http://www.pushlets.com/
Pushlets developed from 2000 to 2010 and gradually faded out of the market.
7、Comet
Comet is a web application model that uses an HTTP persistent connection, allowing the server to push data to the browser without the browser making an explicit request. Comet technology is a general term for this technology. In fact, there are many specific implementation technologies. The following is a specific timeline to introduce what Comet technologies are.
1) Early Java Applet
2) Pushlets framework emerging in 2000
3) Hidden iframe
4) XMLHttpRequest
5) XMLHttpRequest long polling
6) Script tag long polling
http://blog.csdn.net/chszs/article/details/46581179