Web-side Instant Messaging technology inventory: Short Polling, Comet, Websocket, SSE

1. Preface

Web-side IM technology is not easy to implement due to limitations in browser design, and there are roughly 4 main web-end instant Messaging solutions: Traditional Ajax short polling, Comet technology, WebSocket Technology, SSE (Server-sent Events). This article will briefly introduce the principles of these 4 technologies, and point out their similarities and differences, advantages and disadvantages, and so on.

2. Overview

The 1996 IETF HTTP workgroup released the 1.0 version of the HTTP protocol, and the now widely used version of the 1.1,HTTP protocol has undergone more than 17 years of development. This distributed, stateless, TCP-based request/response, which is widely used today in the Internet's popularity, seems to be progressing slowly relative to the rapid development of the Internet. From the rise of the Internet to the present, experienced the web1.0 era of portal site prevalence, and then with the advent of Ajax technology, the development of Web applications prevailing in the web2.0 era, and now moving towards web3.0 direction. The inverse HTTP protocol, developed from version 1.0 to 1.1, is a perfunctory improvement in cache handling, bandwidth optimization, and security, in addition to the default long connection. It retains a stateless, request/response pattern and never seems to realize that this should change.

Fortunately, the era of HTML5 has arrived, for the implementation of Web-side instant Messaging brings WebSocket and SSE (Server-sent Events) two technical solutions.

3. Ajax Short Polling: The HTTP request sent by the script

In order for a traditional Web application to interact with a server, a form must be submitted, the server receives and processes the form, and then returns a new page, since the data for the front and back two pages is mostly the same, and the process transmits a lot of redundant data and wastes bandwidth. So Ajax technology was born.

Ajax is the abbreviation for asynchronous JavaScript and XML, first presented by Jesse James Garrett. This technology pioneered the browser script (JS) to send HTTP requests. The Outlook Web Access group was used in 98 and soon became part of the IE4.0, but this technology has been very small, until early 2005, Google in his goole groups, Gmail and other interactive applications such as the widespread use of this technology, So that Ajax is quickly accepted by everyone.

The advent of Ajax makes the client and server data transfer less and much faster, but also to meet the rich user experience as the characteristics of the web2.0 era of the early development of the need, but slowly also exposed his shortcomings. For example, the need for real-time update data for rich interactive applications such as instant Messaging cannot be met. This small browser-side technology is still based on the HTTP protocol, the HTTP protocol requires the request/Response mode is also immutable, unless the HTTP protocol itself has changed.

4. Comet: A hack technology

The low latency requirements of data for Web applications represented by instant messaging, the traditional polling-based approach is not enough, and it also brings a bad user experience. So a "server push" technology based on a long HTTP connection is hack out. This technique was named Comet, which was first proposed by the project manager of Dojo Toolkit, Alex Russell, in the blog post Comet:low Latency Data for the browser, and continues.

In fact, the server push very early existence, in the classic Client/server model is widely used, but the browser is too lazy, and does not provide a good support for this technology. But the advent of Ajax made it possible to make this technology available on the browser, and the integration of Google's Gmail and Gtalk first used this technology. With some key issues (such as IE loading display problems), soon this technology has been recognized, there are many mature open-source comet framework.

The following is a typical comparison between Ajax and comet data transmission, the difference is straightforward. The typical Ajax communication method is also the classic use of the HTTP protocol, in order to obtain data, you must first send a request. In a Web application where low latency requires more high, only the frequency of server requests can be increased. Unlike comet, the client maintains a long connection to the server, and the server proactively pushes the data to the client only when the data that the client needs is updated.



There are two main approaches to the implementation of comet, the long polling based on Ajax (long-polling) and the Htmlfile-based streaming (HTTP streaming) approach.

For a detailed introduction to Comet technology, see: "Comet technical details: Web-based real-time communication technology on HTTP long Connections", "web-side Instant Messaging: http long connection, long polling", " Web-side Instant Messaging: No websocket can handle the immediacy of the message, "Open source Comet server Icomet: Support for millions of concurrent web-enabled instant Messaging solutions."

4.1 Ajax-based long polling (long-polling) mode

The browser makes a XMLHttpRequest request, and after the server receives the request, it blocks the request until the data or timeout is returned, and the browser JS makes the request again after processing the request return information (timeout or valid data) and re-establishes the connection. During this time, the server may have new data arrived, the server will choose to save the data until the connection is re-established, the browser will retrieve all the data once.

4.2 Stream (HTTP streaming) mode based on Iframe and Htmlfile

The IFRAME is an HTML tag, and the src attribute of this tag keeps a long connection request to the specified server, and the server side can keep returning the data, which is closer to the traditional server push than the first way.

In the first way, the browser calls the JS callback function directly after receiving the data, but how does it respond to the data? You can embed a JS script in the return data, such as "<script type=" Text/javascript ">js_func (" Data from server ") </script>", The server side will return the data as the parameters of the callback function, the browser after receiving the data will execute the JS script.



However, there is a clear deficiency in this way: ie, Morzilla Firefox at the bottom of the progress bar will show that the load is not completed, and the icon above IE will not stop rotating, indicating that the load is in progress. Google's geniuses use an ActiveX called "htmlfile" to solve the load display problem in IE and apply this method to the Gmail+gtalk product.

5. Websocket: Solutions for the future 1

If the advent of Ajax is the inevitable development of the Internet, then the advent of comet technology is more revealing a helpless, just as a hack technology, because there is no better solution. Who should solve the problem of comet resolution is reasonable? Browser, HTML standard, or HTTP standard? Who should be the protagonist? Essentially, this involves data transfer, the HTTP protocol should be the first, it is time to change the lazy protocol of the request/Response mode.

The answer is given in the new generation of HTML standard HTML5, which provides a network technology WebSocket for full-duplex communication between browsers and servers. From the WebSocket draft, WebSocket is a completely new, independent protocol, based on the TCP protocol, which is compatible with the HTTP protocol and does not fit into the HTTP protocol, just as part of the HTML5. The script is then given another ability: to initiate a websocket request. We should be familiar with this approach, because Ajax is doing it, and the difference is that Ajax initiates HTTP requests.

Unlike the HTTP protocol's different request/response modes, WebSocket has a handshake (Opening handshake) process before the connection is established, and there is a handshake (Closing handshake) process before closing the connection. Once the connection is established, both sides can communicate in two directions.

For a detailed description of the WebSocket, please refer to the Instant Communication Communication series on WebSocket: "WebSocket detailed (i): Preliminary understanding WebSocket Technology", "WebSocket detailed (ii): Technical Principles, code demonstrations and application Cases", " WebSocket Detailed (iii): in-depth websocket communication protocol details.

From the browser support point of view, WebSocket is already in sight, but there is still a long way to go, especially in China, the IE6, 7, 8 is still prevalent in the country, the demise of the old version of the browser takes a long time, before fully realizing the full compatibility of the browser, Comet technology may still be the best solution. However, there are now some more mature packaging solutions to address this compatibility limit, such as: Open source Socket.io, see the Socket.io Introduction: Support WebSocket, web-side instant Messaging framework.

6. SSE: Solutions for the Future 2

SSE (server-sent event, server-side push events) is a HTML5 technology that allows the server to push new data to the client. This is a better solution than the client polling every few seconds to pull new data from the server.

It can also push data from the server to the client, compared to WebSocket. So how do you decide whether you use SSE or WebSocket? In summary, WebSocket can do, SSE can do, and vice versa, but in accomplishing certain tasks, they have their own merits.

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

WebSocket and SSE have similar browser support rates, and most mainstream desktop browsers support both. In Android 4.3 and earlier, the system default browser is not supported either, Firefox and Chrome are fully supported, Android 4.4, the system default browser both support Safari supported SSE starting from 5.0 (iOS system starting from 4.0), but until 6.0 correctly supported WebSocket (the WebSocket protocol implemented by Safari before 6.0 has security issues, so some mainstream browsers have disabled the implementation based on this protocol).

Compared with WebSocket, SSE has some significant advantages. Personally, the biggest advantage is convenience: You don't need to add any new components, and you can continue to use any backend language and framework that you're accustomed to. You don't have to worry about creating new virtual machines, getting a new IP, or a new port number, as simple as adding a page to an existing site. I like to call this a survival infrastructure advantage.

SSE's second advantage is the simplicity of the service side. Relatively speaking, WebSocket is very complex, not with the aid of the library basic (I tried, painful).

Because SSE can operate 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, while writing this book, many servers have not yet (although this situation will improve). SSE also has an advantage: it is a text protocol, script debugging is very easy. In fact, in this book, we'll run back-end scripts in development and testing with curl and even directly from the command line.

However, this leads to a potential advantage of websocket compared to SSE: WebSocket is a binary protocol, and SSE is a text protocol (usually using UTF-8 encoding). Of course, we can transmit binary data via 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, data will become larger, if you need to transfer a large number of binary data from the server to the client, it is best to use WebSocket.

The biggest advantage of WebSocket compared to SSE is that it is two-way communication, which means sending data to the server is as simple as receiving data from the server. When using SSE, data is typically transferred from the client to the server through a separate AJAX request. Using AJAX is more expensive than websocket, but it's a little bit more. As a result, the question becomes, "When do you need to be concerned about this difference?" "If you need to transfer data to the server at 1 times per second or faster, you should use WebSocket." 0.2 times/second to 1 times/second frequency is a gray area, with WebSocket and with SSE difference is not big, but if you expect heavy load, it is necessary to determine the datum point. When the frequency is less than 0.2 times/second, the difference is small.

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

When you are enjoying SSE's existing infrastructure advantages and set up a Web server between the client and the service-side scripts, the difference is revealed. A SSE connection not only uses a socket, but also consumes an Apache thread or process, and if PHP is used, it will create a new PHP instance for the connection. Apache and PHP use a lot of memory, which limits the number of parallel connections that the server can support. So, to do with SSE in the data transmission performance and websocket exactly the same, need to write a own back-end server, of course, those who in any case will use their own server and the use of node. js people, will find it strange.

Talk about the compatibility of websocket on older versions of the browser. Currently, about 2/3 of browsers support these new technologies, and the support rate for mobile browsers will be lower. By convention, Flash is used whenever two-way sockets are needed, and websocket backwards compatibility is usually done with Flash, which is already quite complicated, and if there is no flash on the browser, the situation is worse. Generally speaking, websocket is difficult to be compatible, SSE is easy to be compatible. For a special introduction to SSE articles, see: SSE Technical Detail: A new HTML5 server push event technology.

(This article was released synchronously at: http://www.52im.net/thread-336-1-1.html)

Learning Communication

-More information on instant Messaging: Http://www.52im.net/forum.php?mod=collection&op=all

-Instant Messenger Development Exchange Group: 215891622 [Recommended]

Series Information

Web-side Instant Messaging Novice Primer sticker:
Introduction to Beginners: the principle of web-side instant Messaging technology

About Ajax Short Polling:
There is no point in finding this information, unless you are bluffing, consider 3 other options.

For a detailed introduction to Comet technology, see:
"Comet technical details: Web-based real-time communication technology with long-connected HTTP"
"Web-side Instant Messaging: http long connection, long polling"
"Web-side Instant Messaging: No websocket can handle the immediacy of the message."
Open Source Comet Server Icomet: Support for millions of concurrent web-enabled Instant Messaging solutions

For a detailed description of the WebSocket, see:
"WebSocket Detailed (a): Preliminary understanding of WebSocket technology"
WebSocket detailed (ii): Technical Principles, code demonstrations and application cases
WebSocket Detailed (iii): in-depth websocket communication protocol details
Socket.io: Supporting WebSocket, a framework for web-side instant Messaging
What is the relationship between Socket.io and WebSocket? What's the difference? 》

For a detailed introduction to SSE, see:
SSE Technical detail: A new HTML5 server push event Technology

For more web-based instant messaging articles, see:
Http://www.52im.net/forum.php?mod=collection&action=view&ctid=15

Jack Jiang (click on the author name to go to GitHub)

Source: http://www.52im.net/space-uid-1.html

Communication: Welcome to the Newsletter Development Exchange Group 215891622

Discussion: http://www.52im.net/

Jack Jiang is also the author of "Original Java Swing façade engineering Beautyeye" and "lightweight mobile instant Messaging framework Mobileimsdk", where you can go to download communication.

Welcome reprint, Reprint please indicate the source (also can go to my 52im.net find me).

Web-side Instant Messaging technology inventory: Short Polling, Comet, Websocket, SSE