Quick start to web side IM communication technology: short polling, long polling, SSE, websocket

Time:2021-8-17

This article comes from the “fuzzy” sharing, the original title “real-time message push sorting”, with optimization and changes.

1. Write in front

For developers familiar with web instant messaging technology, we review the underlying communication technology of Web im. From short polling and long polling to SSE and websocket later, the use threshold is getting lower and lower (early technologies such as long polling comet actually belong to hack means, and the use threshold is not low). The technical means are becoming more and more advanced, The experience of Web instant messaging technology is getting better and better.

But last week, when editing the third article in the series of articles on IM code scanning login technology, it suddenly occurred to me that these so-called web instant messaging “old technologies” are not useless compared with the popular websocket. Take the code scanning login function in IM. Short polling technology is very suitable. There is no need to shoot mosquitoes on websocket.

Therefore, it is not necessary to blindly pursue new technologies in many cases. What is suitable for the application scenario is the best. For developers of instant messaging technologies such as Im and message push of instant messaging network, it is important to master websocket, but it is still helpful to understand the so-called “old technologies” of Web instant messaging such as short polling and long polling, which is the important reason for sorting and sharing this article.

Quick start to web side IM communication technology: short polling, long polling, SSE, websocket

exchange of learning:

Instant messaging / push technology development exchange group 5: 215477170 [recommended]
Introduction to mobile terminal im development article: a beginner’s introduction is enough: developing mobile terminal im from scratch
Open source im framework source code:https://github.com/JackJiang2…

(this article is published on:http://www.52im.net/thread-35…

2. Recommended reading

[1] Novice entry post: detailed explanation of the most complete principle of Web instant messaging technology in history
[2] Explain the evolution of Web Communication: from Ajax and jsonp to SSE and websocket
[3] Web instant messaging technology inventory: short polling, comet, websocket, SSE

3. Body introduction

For instant messaging systems such as im / message push, the key of the system is the ability of “real-time communication”.

On the face of it, “real-time communication” means:

1) The client can actively send data to the server at any time;
2) When the content concerned by the client changes, the server can notify the client in real time.
Compared with the traditional C / s request model, in “real-time communication”, the client does not need to send a request subjectively to obtain the content they care about, but is “pushed” by the server.

Note: the word “push” above is quoted. In fact, among the existing technical implementation methods, the server side does not really push actively, but creates an illusion of “real-time communication” through certain means.

In terms of several existing technologies, there are mainly the following categories:

1) Client polling: short polling in the traditional sense;
2) Server side polling: long polling;
3) One way server push: server sent events (SSE);
4) Full duplex communication: websocket.
The following text will solve your doubts one by one for these technical solutions.

4. This article is supported by demo and code

In order to help readers better understand the content of this article, the author specially wrote a more complete demo. The demo will be implemented through the above four technical methods with an example of a simple chat room (there are some bugs in the code, mainly for demonstration, don’t mind).

Package and download the complete demo source code:

(please download from the sync link attachment:http://www.52im.net/thread-35…

Running effect of demo (moving picture):

If you are interested, you can download and study by yourself.

5. Understand short polling

Implementation principle of short polling:

1) The client sends a request to the server, the server returns data, and then the client processes it according to the data returned by the server;
2) The client continues to send requests to the server and repeat the above steps. If you don’t want to put too much pressure on the server, you will generally set a request interval.
The logic is shown in the figure below:

Advantages of using short polling: the foundation does not require additional development costs, requests data, parses data, responds, that’s all, and then repeats.

The disadvantages are also obvious:

1) Constantly sending and closing requests will put a lot of pressure on the server, because opening an HTTP connection is a resource consuming thing;
2) The polling interval is not easy to control. If the real-time requirement is high, it is obvious that using short polling will have obvious short boards. If the interval set is too long, it will lead to message delay. If it is too short, it will put pressure on the server.
Code implementation of short polling client (excerpt):

var ShortPollingNotification = {

datasInterval: null,

subscribe: function() {

this.datasInterval = setInterval(function() {

  Request.getDatas().then(function(res) {

    window.ChatroomDOM.renderData(res);

  });

}, TIMEOUT);

return this.unsubscribe;

},

unsubscribe: function() {

this.datasInterval && clearInterval(this.datasInterval);

}

}

PS: for the complete code, please refer to the section “4. Supporting demo and code”.

The operation effect of the corresponding demo in this paper is as follows (dynamic diagram):

The following is the corresponding request. Note that the number of requests in the lower left corner is always changing:

In the figure above, a request is sent every 1s, which looks good, but if the timeout value is set to 5S, the effect will be greatly reduced. As shown in the figure below.

Demo running effect when timeout value is set to 5S (moving picture):

6. Understand long polling

6.1 basic principles
Basic principle of long polling:

1) The client sends a request, and the server will hold the request;
2) Data will not be returned and the connection will be disconnected until the monitored content is changed (or if the request is not returned within a certain period of time, the connection will be automatically disconnected due to timeout);
3) The client continues to send the request and repeats the above steps.
The logic is shown in the figure below:

Long polling is an improved version based on short polling: it mainly reduces the overhead of HTTP connection initiated by the client, and changes to actively judge whether the concerned content changes on the server.

Therefore, the essence of polling has not changed much. The change lies in:

1) The polling for content change is changed from the client to the server (the client will send the request again after the connection is interrupted, which greatly reduces the number of connection initiation compared with short polling);
2) The client will only make corresponding changes when the data changes. Compared with short polling, it does not receive the whole data.
6.2 code implementation
Code implementation of long polling customers (excerpt):

//Client

var LongPollingNotification = {

// ....

subscribe: function() {

  var that = this;



  //Set timeout

  Request.getV2Datas(this.getKey(),{ timeout: 10000 }).then(function(res) {

    var data = res.data;

    window.ChatroomDOM.renderData(res);

    //After the data is successfully obtained, the request will be sent again

    that.subscribe();

  }).catch(function(error) {

    //The request will also be sent again after the timeout

    that.subscribe();

  });

  return this.unsubscribe;

}

// ....

}

The author uses express, which does not support hold requests by default, so an express longpoll library is used to implement it.

The following is the implementation of a native no library (here is just the principle). The overall idea is: if the server supports the hold request, it will self poll within a certain period of time, and then judge whether to return new data by comparing the key value.

The following are specific ideas:

1) The client will bring an empty key value for the first time. This time, it will return immediately to obtain new content, and the server will return the calculated contentkey to the client;
2) Then, the client sends the second request, takes the contentkey returned for the first time as the key value, and then makes the next round of comparison;
3) If the two key values are the same, a hold request will be made for internal polling. If there is new content or client timeout during the period, the connection will be disconnected;
4) Repeat the above steps.
The code is as follows:

//Server side

router.get(‘/v2/datas’, function(req, res) {

const key = _.get(req.query, ‘key’, ”);

let contentKey = chatRoom.getContentKey();

while(key === contentKey) {

sleep.sleep(5);

contentKey = chatRoom.getContentKey();

}

const connectors = chatRoom.getConnectors();

const messages = chatRoom.getMessages();

res.json({

code: 200,

data: { connectors: connectors, messages: messages, key: contentKey },

});

});

The following is an implementation fragment using express longpoll:

// mini-chatroom/public/javascripts/server/longPolling.js

function pushDataToClient(key, longpoll) {

var contentKey = chatRoom.getContentKey();

if(key !== contentKey) {

var connectors = chatRoom.getConnectors();

var messages = chatRoom.getMessages();



long poll.publish(

  '/v2/datas',

  {

    code: 200,

    data: {connectors: connectors, messages: messages, key: contentKey},

  }

);

}

}

long poll.create(“/v2/datas”, function(req, res, next) {

key = _.get(req.query, ‘key’, ”);

pushDataToClient(key, longpoll);

next();

});

intervalId = setInterval(function() {

pushDataToClient(key, longpoll);

}, LONG_POLLING_TIMEOUT);

PS: for the complete code, please refer to the section “4. Supporting demo and code”.

To facilitate the demonstration, I changed the timeout of the request initiated by the client to 4S, and pay attention to the following screenshot:

You can see that there are two ways to disconnect, either timeout or request data return.

6.3 long polling mode based on iframe
This is another implementation scheme of long polling technology.

The specific principle of the scheme is as follows:

1) Embed an iframe in the page, the address points to the polling server address, and then place an execution function in the parent page, such as execute (data);
2) When the server changes content, it will send a script < script > parent. Execute (JSON. Stringify (data)) < / script > to iframe;
3) Through the sent script, actively execute the methods in the parent page to achieve the push effect.
Due to lack of space, there is no in-depth introduction here. Interested students can read the section “3.3.2 iframe based data flow” in the article “novice introduction post: detailed explanation of the most complete principles of Web instant messaging technology in history”.

7. What is server sent events (SSE)

7.1 basic introduction
From the perspective of pure technology: in the short polling and long polling technologies introduced in the previous two sections, the server cannot actively push messages to the client, and the client actively requests the server to obtain the latest data.

SSE introduced in this section is a technology that can actively push messages from the server.

The essence of SSE is actually a long HTTP connection, but it does not send a one-time packet to the client, but a stream stream in the format of text / event stream. Therefore, the client will not close the connection and will always wait for the new data stream sent by the server. Video playback is an example.

In short, SSE is:

1) SSE uses HTTP protocol, which is supported by existing server software. Websocket is a stand-alone protocol.
2) SSE is lightweight and easy to use; Websocket protocol is relatively complex.
3) SSE supports disconnection and reconnection by default, and websocket needs to be implemented by itself.
4) SSE is generally only used to transmit text. Binary data needs to be transmitted after encoding. Websocket supports binary data transmission by default.
5) SSE supports custom message types.
The technical principle of SSE is shown in the figure below:

For the basic use of SSE, please refer to the SSE API document at:https://developer.mozilla.org/en … _server-sent_events。

At present, except IE and lower version browsers, most modern browsers support SSE:

(the above figure is from:https://caniuse.com/?search=S…

7.2 code implementation
//Client

var SSENotification = {

source: null,

subscribe: function() {

if('EventSource'inwindow) {

  this.source = newEventSource('/sse');



  this.source.addEventListener('message', function(res) {

    const d = res.data;

    window.ChatroomDOM.renderData(JSON.parse(d));

  });

}

return this.unsubscribe;

},

unsubscribe: function() {

this.source && this.source.close();

}

}

//Server side

router.get(‘/sse’, function(req, res) {

const connectors = chatRoom.getConnectors();

const messages = chatRoom.getMessages();

const response = { code: 200, data: { connectors: connectors, messages: messages } };

res.writeHead(200, {

"Content-Type":"text/event-stream",

"Cache-Control":"no-cache",

"Connection":"keep-alive",

"Access-Control-Allow-Origin": '*',

});

res.write(“retry: 10000\n”);

res.write(“data: “+ JSON.stringify(response) + “\n\n”);

var unsubscribe = Event.subscribe(function() {

const connectors = chatRoom.getConnectors();

const messages = chatRoom.getMessages();

const response = { code: 200, data: { connectors: connectors, messages: messages } };

res.write("data: "+ JSON.stringify(response) + "\n\n");

});

req.connection.addListener(“close”, function() {

unsubscribe();

}, false);

});

The following is the situation of the console. Pay attention to the response type:

Please check the request type and eventstream message type in details:

PS: more detailed information about SSE is not here. Interested students can read SSE Technology Details: a new HTML5 server push event technology and web message push using websocket and SSE technology.

8. What is websocket

8.1 basic introduction
PS: the content of this section is quoted from the dry goods of Web instant messaging practice: how to make websocket disconnected and reconnected faster “3. Get to know websocket quickly”.

Websocket was born in 2008 and became an international standard in 2011. Now all browsers support it (see quick start for beginners: a concise tutorial on websocket). It is a new application layer protocol. It is a real full duplex communication protocol specially designed for web client and server. It can be compared with HTTP protocol to understand websocket protocol.

(the picture is quoted from detailed explanation of websocket (IV): getting to the bottom of the relationship between HTTP and websocket (Part I))

Their differences:

1) The protocol identifier of HTTP is HTTP, and the protocol identifier of websocket is WS;
2) HTTP requests can only be initiated by the client. The server cannot actively push messages to the client, but websocket can;
3) HTTP requests have homology restrictions. Communication between different homologies requires cross domain, while websocket has no homology restrictions.
Their similarities:

1) Are communication protocols of application layer;
2) The default port is the same, 80 or 443;
3) Can be used for communication between browser and server;
4) Are based on TCP protocol.
Relationship between the two and TCP:

(the picture is quoted from quick start for beginners: a concise tutorial on websocket)

For details on the relationship between HTTP and websocket, please read:

Detailed explanation of websocket (IV): getting to the bottom of the relationship between HTTP and websocket (Part I)

Detailed explanation of websocket (V): thoroughly understand the relationship between HTTP and websocket (Part 2)

For the relationship between websocket and socket, you can read in detail: detailed explanation of websocket (VI): getting to the bottom of the relationship between websocket and socket

8.2 technical features
The technical features of websocket are summarized as follows:

1) It can communicate in both directions. The main purpose of the design is to reduce the overhead of the number of HTTP connections during traditional polling;
2) It is based on TCP protocol, and the handshake phase adopts HTTP protocol, so it is not easy to shield the handshake and can pass through various HTTP proxy servers;
3) It has good compatibility with HTTP and can also use ports 80 and 443;
4) The client can communicate with any server without homology restriction;
5) You can send text or binary data;
6) The protocol identifier is WS (WSS if encrypted), and the server URL is the URL
The technical principle of websocket is shown in the following figure:

The knowledge about websocket API will not be explained here, but can be consulted by yourself:https://developer.mozilla.org…

8.3 browser compatibility
Websocket has good compatibility and basically supports all modern browsers.

(the above figure is from:https://caniuse.com/mdn-api_w…

8.4 code implementation
The author uses socket.io, which is based on websocket encapsulation and provides client-side and server-side support.

//Client

var WebsocketNotification = {

// …

subscribe: function(args) {

var connector = args[1];

this.socket = io();

this.socket.emit('register', connector);

this.socket.on('register done', function() {

  window.ChatroomDOM.renderAfterRegister();

});

this.socket.on('data', function(res) {

  window.ChatroomDOM.renderData(res);

});

this.socket.on('disconnect', function() {

  window.ChatroomDOM.renderAfterLogout();

});

}

// …

}

//Server side

var io = socketIo(httpServer);

io.on(‘connection’, (socket) => {

socket.on(‘register’, function(connector) {

chatRoom.onConnect(connector);

io.emit('register done');

var data = chatRoom.getDatas();

io.emit('data', { data });

});

socket.on(‘chat’, function(message) {

chatRoom.receive(message);

var data = chatRoom.getDatas();

io.emit('data', { data });

});

});

PS: for the complete code, please refer to the section “4. Supporting demo and code”.

The response format is as follows:

8.5 in depth learning
With the increasing popularity of HTML5, the application of websocket is becoming more and more popular. The learning materials about websocket are easy to find on the Internet. Due to space limitation, this paper will not expand this topic in depth.

If you want to further study all aspects of websocket, the following articles are worth reading:

Getting started for beginners: a concise tutorial on websocket
Detailed explanation of websocket (I): a preliminary understanding of websocket Technology
Detailed explanation of websocket (II): technical principles, code demonstration and application cases
Detailed explanation of websocket (III): go deep into the details of websocket communication protocol
Detailed explanation of websocket (IV): getting to the bottom of the relationship between HTTP and websocket (Part I)
Detailed explanation of websocket (V): thoroughly understand the relationship between HTTP and websocket (Part 2)
Detailed explanation of websocket (VI): thoroughly understand the relationship between websocket and socket
Integrating theory with practice: understanding the communication principle, protocol format and security of websocket from zero
How to use websocket to realize long connection in wechat applet (including complete source code)
Eight questions about websocket protocol: quick answers to popular websocket questions for you
Web instant messaging practice dry goods: how to make your websocket disconnected and reconnected faster
Websocket from entry to mastery, half an hour is enough
Introduction to websocket hard core: 200 lines of code to teach you to roll up a websocket server with your bare hands
Long connection Gateway Technology (IV): iqiyi websocket real-time push gateway technology practice

9. Summary of this paper

The implementation cost of short polling and long polling is relatively simple. It is suitable for message push with low real-time requirements. In scenarios with high real-time requirements, there will be delays and greater pressure on the server.

SSE can only be server-side push messages, so it is more suitable for projects that do not need two-way communication.

At present, websocket has relatively low implementation cost and is suitable for duplex communication. It is more practical for projects requiring high real-time performance for multi person online.

The official account of the “instant messaging technology circle” has been released.
Quick start to web side IM communication technology: short polling, long polling, SSE, websocket
The link on the official account is: click here to enter. The synchronous publishing link is:http://www.52im.net/thread-35…