Comet, next-generation reverse Ajax (server push technology-server-side push)

Understanding comet

You may have heard of comet because it has received some attention recently. Comet is also called reverse Ajax or Server Terminal push Technology (Server-side push ). The idea is simple: Data Push directly from the server to the browser without waiting for the browser to request data. It sounds simple, but if you are familiar Web Application Program , Especially the HTTP protocol. Implementing comet web applications and ensuring scalability on browsers and servers is only possible in recent years. At present, some mainstream websites have similar principles, such as webqq, kaixin.com, and the white society. The message dynamics in these websites all adopt similar technologies, and the specific implementation methods may be different;

Motivation for using comet

There is no doubt about the success of the HTTP protocol. It is the basis for most information exchange on the Internet. However, it also has some limitations. In particular, it is a stateless, one-way protocol. The request is sent to the Web server, and the server processes the request and returns a response concurrently-that's all. The request must be sent by the client, while the server can only send data in the response to the request. This will at least affect the practicability of many types of Web applications. A typical example is a chat program. There are also some examples, such as the score of the game, stock quotes or email programs.

these limitations of HTTP are also the reasons for its success. The request/response cycle makes it a classic model, that is, each connection uses a thread. This method has huge scalability as long as it can quickly provide services for requests. A large number of requests can be processed every second, and a large number of users can be processed with only a small number of servers. For many classic Web applications such as content management System , Search for Applications and E-Commerce sites. In any of the preceding web applications, the server provides the data requested by the user, closes the connection, and releases the thread so that it can serve other requests. If interaction still exists after the initial data is provided, the connection is kept in the open state, so the thread cannot be released and the server cannot serve many users.

However, what if I want to maintain interaction with users after responding to the request and sending the initial data? In the early days of the Web, Meta Refresh was often used. This automatically instructs the browser to reload after the specified number of secondsPagePolling is supported ). This is not only a bad user experience, but also usually very inefficient. What if no new data is displayed on the page? At this time, you have to re-render the same page. What if there are few changes to the page and most of the pages do not change? Similarly, whether necessary or not, you have to request and retrieve all the content on the page.

The invention and popularity of Ajax have changed the above situation. Now, the server can communicate asynchronously, so you do not have to request the whole page again. You can perform incremental updates. You only need to use XMLHttpRequest to poll the server. This technology is usually called comet. This technology has some variants, each of which has different performance and scalability. Let's take a look at these different types of comet.

Comet Style

The emergence of Ajax makes comet possible. The unidirectional nature of HTTP can be effectively avoided. There are actually some different ways to bypass this. As you may have guessed, the easiest way to support comet is poll ). Use XMLHttpRequest to send a call to the server. Wait for a fixed periodTime(The setTimeout of JavaScript is usually used.Function), And then call it again. This is a very common technology. For example, most webmail applications use this technology to display emails when an email arrives.

This technology has advantages and disadvantages. In this case, you expect a quick response, just like any other Ajax request. There must be a pause between requests. Otherwise, continuous requests will throw the server, and in this case it is obviously not scalable. This pause causes a latency for the application. The longer the pause time, the more time it takes for new data on the server to arrive at the client. If the pause time is shortened, the server may be overwhelmed again. On the other hand, this is obviously the simplest way to implement comet.

It should be pointed out that many people think that polling does not belong to comet. On the contrary, they think that comet is a limitation of round-robin.SolutionSolution. The most common "true" comet technology is a variant of polling, namely long polling ). The main difference between polling and long polling is how long the server takes to respond. Long polling usually keeps the connection for a long period of time-usually several seconds, but it may also be one minute or longer. When an event occurs on the server, the response is sent and immediately closed, and the polling starts again immediately.

The advantage of long polling over general polling is that once data is available, it is immediately sent from the server to the client. The request may wait for a long time, during which no data is returned, but once new data is generated, it will be immediately sent to the client. Therefore, there is no latency. If you have used a Web-based chat program or any program that claims to be "real-time", it is likely to use this technology.

long polling has a variation, which is the third type of comet. This is usually called streaming ). In this style, the server pushes data back to the client, but does not close the connection. The connection will remain open until it expires and the request is resent. The XMLHttpRequest specification indicates that you can check whether the value of readystate is 3 or loading ing (instead of 4 or loaded) and obtain the data that is "Flowing" from the server. Like long polling, this method has no latency. When the data on the server is ready, the data is sent to the client. Another advantage of this approach is that it can greatly reduce the number of requests sent to the server, thus avoiding problems with Settings overhead and latency related to server connection. Unfortunately, XMLHttpRequest has many different implementations in different browsers. This technology can only be used reliably in later versions of Mozilla Firefox. Long polling is still required for Internet Explorer or safari.

at this point, you may think that long polling and stream have a big problem. The request must exist on the server for a long time. This breaks the model of using one thread for each request, because the thread used for one request has never been released. Worse, the thread remains idle unless data is sent back. This is obviously not scalable. Fortunately, modern Java Web servers can solve this problem in many ways. DO JAVA developed the programmer , relatively lucky, php not many