Web-side instant messaging technology inventory: short polling, Comet, Websocket, SSE

Web-side instant messaging technology inventory: short polling, Comet, Websocket, SSE

Web-side instant messaging technology has not been easy to implement due to the design constraints of the browser. There are roughly four mainstream Web-side instant messaging solutions: traditional Ajax short polling, Comet technology, WebSocket technology, SSE (Server -sent Events). This article will briefly introduce the principles of these four technologies, and point out the similarities and differences, advantages and disadvantages of each.

 1   overview

1 996-year IETF HTTP Working Group has released version 1.0 of HTTP protocol, and now commonly used version 1.1, HTTP protocol has experienced 17 years of development. This distributed, stateless, TCP-based request/response protocol, which is widely used in the Internet today, seems to be progressing slowly relative to the rapid development of the Internet. From its rise to the present, the Internet has experienced the web1.0 era where portals are prevalent, and then with the emergence of ajax technology, it has developed into the web2.0 era where web applications are prevalent, and now it is moving in the direction of web3.0. On the other hand, the http protocol has developed from version 1.0 to 1.1. In addition to the default long connection, there are painless improvements in cache processing, bandwidth optimization, and security. It has always retained a stateless, request/response model, and it never seems to realize that this should change.

Fortunately, the era of HTML5 has arrived, bringing WebSocket and SSE (Server-sent Events) two technical solutions to the realization of Web-side instant messaging.

 2   Ajax short polling

Biography conventional web application in order to interact with the server, you must submit a form (form), the server receives and processes the transmitted form, and then return to the new page.

Because most of the data on the two pages before and after are the same, this process transmits a lot of redundant data and wastes bandwidth. So Ajax technology came into being.

Ajax is short for Asynchronous JavaScript and XML, first proposed by Jesse James Garrett.

This technology groundbreakingly allows browser scripts (JS) to send http requests. The Outlook Web Access group was used in 1998 and soon became a part of IE4.0, but this technology has been very small. Until early 2005, Google widely used this technology in its interactive applications such as goole groups and gmail. It made Ajax quickly accepted by everyone.

The emergence of Ajax makes the client and server transmit data much less and much faster. It also meets the needs of the early development of the web 2.0 era characterized by rich user experience, but it has slowly exposed its drawbacks.

For example, it cannot meet the real-time data update requirements of rich interactive applications such as instant messaging. This kind of browser-side small technology is still based on the http protocol after all, and the request/response mode required by the http protocol cannot be changed unless the http protocol itself is changed.

 3   Comet: a hack technique

The Low Latency requirements of web applications represented by instant messaging cannot be met by traditional polling-based methods, and it will also bring a bad user experience.

So a "server push" technology based on http long connections was hacked. This technology is named Comet, and this term was first proposed by Alex Russell, the project director of Dojo Toolkit, in the blog post Comet: Low Latency Data for the Browser, and it is still used.

In fact, server push has existed for a long time, and is widely used in the classic client/server model, but the browser is too lazy and does not provide good support for this technology.

But the emergence of Ajax makes it possible to implement this technology on the browser, and the integration of google's gmail and gtalk first used this technology. With the resolution of some key issues (such as IE loading and display issues), this technology was quickly recognized, and there are already many mature open source Comet frameworks.

The following is a comparison of typical Ajax and Comet data transmission methods, the difference is simple and clear.

The typical Ajax communication method is also the classic use of the http protocol. To obtain data, you must first send a request. In web applications with relatively high Low Latency requirements, the frequency of server requests can only be increased. Comet is different. The client maintains a long connection with the server, and only when the data required by the client is updated, the server actively pushes the data to the client.

view image

There are two main ways to implement Comet, long-polling based on Ajax and http streaming based on Iframe and htmlfile.

Ajax-based long-polling (long-polling) method

The browser sends an XMLHttpRequest request. After the server receives the request, it will block the request until there is data or timeout before returning. The browser JS sends the request again after processing the request return information (timeout or valid data) to re-establish the connection. During this period, new data may have arrived on the server side, and the server will choose to save the data until the connection is re-established, and the browser will retrieve all the data at once.

view image

Streaming (http streaming) based on Iframe and htmlfile

Iframe is an html tag. The src attribute of this tag will keep a long connection request to the specified server, and the server can return data continuously. Compared with the first method, this method is closer to the traditional server push.

In the first method, the browser will directly call the JS callback function after receiving the data, but how to respond to the data in this way? You can embed the JS script in the returned data, such as "", the server will use the returned data as the parameter of the callback function, and the browser will execute this JS script after receiving the data.

view image

But this method has an obvious shortcoming: the progress bar at the bottom of IE and Morzilla Firefox will show that the loading is not completed, and the icon at the top of IE will keep rotating, indicating that the loading is in progress. Google's geniuses used an ActiveX called "htmlfile" to solve the loading display problem in IE, and applied this method to the gmail+gtalk product.

 4   Websocket: Future Solution 1

As if to say the emergence of Ajax is the inevitable development of the Internet, the emergence of the Comet technology reveals a more helpless, just as a hack technique, because there is no better solution.

Who should solve the problem that Comet solves is reasonable? Browser, html standard, or http standard? Who should be the protagonist? Essentially, this involves data transmission methods. The http protocol should bear the brunt. It is time to change the request/response mode of this lazy protocol.

W3C gave the answer. In the new generation html standard html5, it provides Websocket, a network technology for full-duplex communication between a browser and a server. According to the Websocket draft, Websocket is a brand new and independent protocol, based on TCP protocol, compatible with http protocol, but will not be integrated into http protocol, only as part of html5. So the script was given another ability: to initiate a websocket request. We should be familiar with this method, because Ajax does this, the difference is that Ajax initiates an http request.

Unlike the request/response mode of the http protocol, Websocket has a Handshake (Opening Handshake) process before establishing a connection, and a Handshake (Closing Handshake) process before closing the connection. After the connection is established, the two parties can communicate in two directions.

From the perspective of browser support, WebSocket is already in sight, but there is still a long way to go, especially in China, a country where IE6, 7, and 8 are still popular, the demise of old browsers will take a long time In time, Comet technology may still be the best solution before full browser compatibility is achieved. However, there are currently some more mature packaging solutions to solve this compatibility limitation, such as the open source Socket.io.

 5   SSE: Solutions for the Future 2

S SE (Server-Sent Event) is an HTML5 technology that allows the server to push new data to the client. Compared with the client polling and pulling new data from the server every few seconds, this is a better solution.

Compared with WebSocket, it can also push data from the server to the client. So how do you decide whether you use SSE or WebSocket? In a nutshell, what WebSocket can do, SSE can do, and vice versa, but they have their own advantages in accomplishing certain tasks.

WebSocket is a more complex server-side implementation technology, but it is a true two-way transmission technology, which can push data from the server to the client and from the client to the server.

The browser support rates of WebSocket and SSE are similar, and most mainstream desktop browsers support both. In Android 4.3 and earlier versions, the system default browser does not support both, Firefox and Chrome fully support; in Android 4.4, the system default browser supports both; Safari from 5.0 to support SSE (iOS system from Since 4.0), WebSocket was not correctly supported until 6.0 (the WebSocket protocol implemented by Safari before 6.0 has security problems, so some mainstream browsers have disabled the implementation based on this protocol).

Compared with WebSocket, SSE has some significant advantages. Personally, I think its biggest advantage is convenience: you don't need to add any new components, you can continue to use it with any back-end language and framework you are used to. You don't have to worry about creating a new virtual machine, getting a new IP or a new port number, it's as simple as adding a page to an existing website. I like to call this an existing infrastructure advantage.

The second advantage of SSE is the simplicity of the server. Relatively speaking, WebSocket is very complicated, and it is basically impossible to get it without the help of auxiliary libraries (I tried it, which is painful).

Because SSE can run on existing HTTP/HTTPS protocols, it can run directly on existing proxy servers and authentication technologies. For WebSocket, the proxy server needs to do some development (or other work) to support it. At the time of writing this book, many servers are not available (although this situation will improve). SSE has another advantage: it is a text protocol, script debugging is very easy. In fact, in this book, we will use curl during development and testing, and even run back-end scripts directly on the command line.

However, this leads to a potential advantage of WebSocket over SSE: WebSocket is a binary protocol, while SSE is a text protocol (usually UTF-8 encoding). Of course, we can transmit binary data through the SSE connection: in SSE, there are only two characters with special meaning, they are CR and LF, and it is not difficult to transcode them. However, when using SSE to transmit binary data, the data will become larger. If you need to transmit a large amount of binary data from the server to the client, it is better to use WebSocket.

The biggest advantage of WebSocket over SSE is that it is two-way communication, which means that sending data to the server is as simple as receiving data from the server. When using SSE, data is generally transmitted from the client to the server through an independent Ajax request. Compared with WebSocket, the use of Ajax in this way will increase the overhead, but only a little bit more. In this way, the question becomes "When do you need to care about this difference?" If you need to transmit data to the server at a frequency of 1 time per second or faster, you should use WebSocket. The frequency of 0.2 times/second to 1 times/second is a gray area, and there is not much difference between using WebSocket and using SSE; but if you expect heavy loads, it is necessary to determine the benchmark. When the frequency is lower than about 0.2 times/sec, there is little difference between the two.

What is the performance of data transmission from the server to the client? If it is text data rather than binary data (as mentioned above), SSE is no different from WebSocket. They all use TCP/IP sockets, which are lightweight protocols. There is no difference in latency, bandwidth, server load, etc. unless... eh? Unless what?

When you are taking advantage of the existing infrastructure of SSE and setting up a web server between the client and server scripts, the difference becomes apparent. An SSE connection not only uses a socket, but also occupies an Apache thread or process. If PHP is used, it will create a new instance of PHP specifically for this connection. Apache and PHP use a lot of memory, which limits the number of parallel connections that the server can support. Therefore, in order to use SSE to have exactly the same data transmission performance as WebSocket, you need to write your own back-end server. Of course, those who use their own server and use Node.js under any circumstances will find this What's so strange.

Talk about the compatibility of WebSocket on older browsers. Currently, more than two-thirds of browsers support these new technologies, and the support rate of mobile browsers will be lower. By convention, Flash is used whenever a two-way socket is required, and the backward compatibility of WebSocket is usually done with Flash. This is quite complicated. If Flash is not available in the browser, the situation is even worse. In a nutshell, WebSocket is difficult to be compatible, and SSE is easy to be compatible.

Original: http://www.jianshu.com/p/4aa085b9984b

view image