MEMEPh. ideas that are worth sharing...

Summary of Web Real-Time Push Technology

Foreword


With the development of the Web, users have higher and higher requirements for the real-time push of the Web. For example, industrial operation monitoring, Web online communication, real-time quotation systems, online games, etc., all need to actively and real-time transmit the changes that occur in the background. to the browser side without requiring the user to manually refresh the page. This paper compares and summarizes the past and present popular Web real-time push technologies.

 

1. Two-way communication


The HTTP protocol has a flaw: communication can only be initiated by the client. For example, if we want to know today's weather, we can only make a request from the client to the server, and the server returns the query result. The HTTP protocol cannot allow the server to actively push information to the client. The characteristics of this one-way request are destined to be very troublesome for the client to know if the server has continuous state changes. Before the WebSocket protocol, there were three ways to implement bidirectional communication: polling, long-polling, and iframe streaming .

 

1. Polling

Polling is a constant connection between the client and the server, and it is asked every once in a while. The disadvantage is also obvious: the number of connections will be large, one to receive and one to send. And every time a request is sent, there will be Http Header, which will consume a lot of traffic and CPU utilization .

// 1.html
<div id="clock"></div>
<script>
    let clockDiv = document.getElementById('clock');
    setInterval(function(){
        let xhr = new XMLHttpRequest;
        xhr.open('GET','/clock',true);
        xhr.onreadystatechange = function(){
            if(xhr.readyState == 4 && xhr.status == 200){
                console.log(xhr.responseText);
                clockDiv.innerHTML = xhr.responseText;
            }
        }
        xhr.send();
    },1000);
</script>
// poll the server
let express = require('express');
let app = express();
app.use(express.static(__dirname));
app.get('/clock',function(req,res){
  res.end(new Date().toLocaleString());
});
app.listen(8080);

Start the local service, open http://localhost:8080/1.htmlit, and get the following results:

2. Long polling (long-polling)

Long polling is an improved version of polling. After the client sends HTTP to the server, it checks to see if there is any new message. If there is no new message, it keeps waiting. When there is a new message, it will be returned to the client. To some extent, problems such as network bandwidth and CPU utilization are reduced. Since the amount of header data of http packets is often large (usually more than 400 bytes), but the data really needed by the server is very small (sometimes only about 10 bytes), such packets are cycled on the network. Sexual transmission is inevitably a waste of network bandwidth .

// 2.html The server code is the same as above
<div id="clock"></div>

<script>
let clockDiv = document.getElementById('clock')
function send() {
let xhr = new XMLHttpRequest()
xhr.open('GET', '/clock', true)
xhr.timeout = 2000 // timeout in milliseconds
xhr.onreadystatechange = function() {
if (xhr.readyState == 4) {
if (xhr.status == 200) {
//If the return is successful, display the result
clockDiv.innerHTML = xhr.responseText
} 
send() //The next request will be sent regardless of success or failure
} 
} 

xhr.ontimeout = function() {
send()
} 

xhr.send()
}
send()
</script>

 

3. iframe style (streaming)

The iframe streaming method is to insert a hidden iframe in the page, and use its src attribute to create a long connection between the server and the client. Update page.

// 3.html
<body>
    <div id="clock"></div>
    <iframe src="/clock" style="display:none"></iframe>
</body>
//iframe stream
let express = require('express')
let app = express()
app.use(express.static(__dirname))
app.get('/clock', function(req, res) {
setInterval(function() {
let date = new Date().toLocaleString()
res.write(`
<script type="text/javascript">
parent.document.getElementById('clock').innerHTML = "${date}";//Change the parent window dom element
</script>
`)
}, 1000)
})
app.listen(8080)

Start the local service, open http://localhost:8080/3.htmlit, and get the following results:

In the above code, the client only requests once, but the server continuously sends data to the client, so the server maintains a long connection will increase the overhead.

We have introduced three real-time push technologies above, but their shortcomings are obvious, and they are not ideal to use. Next, we will focus on another technology--websocket, which is an ideal two-way communication technology.

 

2. WebSocket


1. What is websocket

WebSocket is a brand-new protocol. With the continuous improvement of the HTML5 draft, more and more modern browsers have begun to fully support WebSocket technology. It applies the TCP Socket (socket) to the webpage, thereby enabling communication The two parties establish a connection channel that remains active.

Once the WebSocket protocol communication connection is established between the Web server and the client, all subsequent communications rely on this dedicated protocol. During the communication process, data in any format such as JSON, XML, HTML or pictures can be sent to each other. Since it is a protocol based on HTTP, the initiator of the connection is still the client, and once the WebSocket communication connection is established, either the server or the client can directly send messages to the other .

Anyone who is new to WebSockets asks the same question: we already have the HTTP protocol, why do we need another protocol?

 

2. Limitations of HTTP

3. Features of WebSocket

Compared with the traditional HTTP mode in which each request-response requires the client to establish a connection with the server, WebSocket is a communication mode similar to Socket's TCP long connection. Once the WebSocket connection is established, subsequent data is transmitted in the form of a frame sequence. Before the client disconnects the WebSocket connection or the server disconnects the connection, the client and server do not need to re-initiate the connection request. In the case of massive concurrency and heavy client-server interaction load and traffic, the consumption of network bandwidth resources is greatly saved, and there are obvious performance advantages, and the client sends and receives messages on the same persistent connection. Sexual advantage is obvious .

Next, let me see how websocket implements two-way communication between the client and the server:

// websocket.html
<div id="clock"></div>

<script>
let clockDiv = document.getElementById('clock')
let socket = new WebSocket('ws://localhost:9999')
//When the connection is successful, the callback function will be executed
socket.onopen = function() {
console.log('client connection is successful')
//Send another message to the server
socket.send('hello') //The content of the message sent by the client is hello
}
//Binding events is by adding attributes
socket.onmessage = function(event) {
clockDiv.innerHTML = event.data
console.log('Received a response from the server', event.data)
}
</script>
// websocket.js
let express = require('express')
let app = express()
app.use(express.static(__dirname))
//http server
app.listen(3000)
let WebSocketServer = require('ws').Server
//Start a websocket server with the ws module, listening on port 9999
let wsServer = new WebSocketServer({ port: 9999 })
//Listen to the client's connection request When the client connects to the server, the connection event will be triggered
//socket represents a client, not shared by all clients, but each client has a socket
wsServer.on('connection', function(socket) {
//Each socket has a unique ID attribute
console.log(socket)
console.log('client connection is successful')
//Listen to the message sent by the other party
socket.on('message', function(message) {
console.log('Received a message from the client', message)
socket.send('Server response:' + message)
})
})

 

3. Comparison of Web Real-time Push Technology

Way type Technical realization advantage shortcoming Applicable scene
Polling client→server Client loop request 1. Simple to implement 2. Support cross-domain 1. Waste bandwidth and server resources 2. Most of the request information is useless (complete HTTP header information) 3. There is a delay 4. Most of the invalid requests Suitable for small applications
Long-Polling client→server The server holds the connection and returns until there is data or timeout, reducing the number of repeated requests 1. Simple implementation 2. Not sending frequent requests 3. Saving traffic 4. Low latency 1. The server holds the connection, which will consume resources. 2. Most of the information requested at one time is useless. WebQQ, Hi web version, Facebook IM
long connection iframe client→server Embed a hidden iframe in the page, set the src attribute of the iframe as a request for a long connection, and the server can continuously input data to the client. 1. Real-time data delivery 2. No useless requests, one link, multiple "push" 1. The server increases the overhead 2. It is impossible to accurately know the connection status 3. IE, chrome, etc. will always be in the loading state Gmail chat
WebSocket server⇌client new WebSocket() 1. Support two-way communication, stronger real-time performance 2. Can send binary files 3. Reduce communication volume 1. The degree of browser support is inconsistent 2. Disconnection and reconnection are not supported Online games, banking interactions and payments