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 .
- Advantages: Simple implementation, no need to make too many changes
- Disadvantages: If the polling interval is too long, users will not be able to receive updated data in time; if the polling interval is too short, it will lead to too many query requests and increase the burden on the server side
// 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 .
- Advantages: Compared with Polling, it is optimized and has better timeliness
- Disadvantages: Keeping a connection consumes resources; server returns no valid data, program times out.
// 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.
- Advantages: messages can arrive in real time; good browser compatibility
- Disadvantages: The server maintains a long connection will increase the overhead; IE, chrome, Firefox will show that the loading is not completed, and the icon will keep rotating.
// 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
- HTTP is a half-duplex protocol, that is, data can only flow in one direction at the same time, the client sends a request to the server (one-way), and the server responds to the request (one-way).
- The server cannot actively push data to the browser. This makes it difficult to implement some advanced functions, such as chat room scenarios.
3. Features of WebSocket
- Support two-way communication, more real-time
- Can send text or binary data
- Reduce traffic: As long as a WebSocket connection is established, you want to keep it connected. Compared with HTTP, not only the total overhead of each connection is reduced, but also because the header information of WebSocket is very small, the communication volume is also reduced accordingly.
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 |