Summary of Web Real-time Push Technology

Preface

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, instant quotation system, online games, etc., all need to actively and real-time transmit the changes occurring in the background to the browser side, without requiring users to manually refresh the page. This paper compares and summarizes the popular Web real-time push technologies in the past and present.

This article complete source code please fierce stampGithub blog, the paper finally feel shallow, suggest you begin to knock on the code.

I. Two-way Communication

The HTTP protocol has a defect: communication can only be initiated by the client. For example, if we want to know the weather today, only the client sends a request to the server and the server returns the query results. The HTTP protocol can’t make the server actively push information to the client. This one-way request is doomed 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 realize two-way communication: polling, long-polling, and iframe streaming..

1. polling


Polling is a continuous connection between the client and the server, which is queried at intervals. The disadvantages are also obvious: there will be many connections, one accepting and one sending. AndEvery time a request is sent, there will be an Http Header, which will consume a lot of traffic and CPU utilization..

  • Advantages: simple implementation, no need to make too many changes
  • Disadvantages: The polling interval is too long, which will cause users not 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 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 local service, openhttp://localhost:8080/1.htmlThe results are as follows:

2. long-polling


Long polling is an improved version of polling. After the client sends HTTP to the server, it will see if there is any new message. If there is no new message, it will wait all the time. When there is a new message, it will be returned to the client. To some extent, the network bandwidth and CPU utilization are reduced. Due to the large amount of header data of http packets (usually more than 400 bytes), but the data really needed by the server is very small (sometimes only about 10 bytes), it is inevitable that such packets are transmitted periodically on the network.It is a waste of network bandwidth..

  • Advantages: Compared with Polling, it is optimized and has better timeliness.
  • Disadvantages: Maintaining connectivity consumes resources; The server did not return valid data and the program timed out.
//2.html 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, the result will be displayed
 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 streaming


The iframe streaming method is to insert a hidden iframe into the page, and use its src attribute to create a long connection between the server and the client. The server transmits data (usually HTML with javascript responsible for inserting information) to the iframe to update the page in real time.

  • Advantages: the message can arrive in real time; Browser compatibility is good
  • Disadvantages: server maintenance of a long connection increases overhead; IE, chrome and Firefox will show that the loading is not complete 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 dom Element of Parent Window
 </script>
 `)
 }, 1000)
 })
 app.listen(8080)

Start local service, openhttp://localhost:8080/3.htmlThe results are as follows:

In the above code, the client requests only once, but the server sends data to the client continuously, which increases the cost of maintaining a long connection.

Above, we have introduced three kinds of real-time push technologies, 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.

Second, WebSocket

1. what is websocket

WebSocket is a brand-new protocol. With the continuous improvement of draft HTML5, more and more modern browsers begin to fully support WebSocket technology. It applies TCP Socket to webpage, thus enabling both communication parties to establish a connection channel that remains active.

Once the communication connection of the WebSocket protocol is established between the Web server and the client, then all communication will depend on this special 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. Once a WebSocket communication connection is established, either party can directly send a message to the other party, regardless of the server or the client..

People who first come into contact with WebSocket will ask the same question: we already have HTTP protocol, why do we need another protocol?

2. Limitations of 2.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 then the server responds to the request (one-way).
  • The server cannot actively push data to the browser. This will make it difficult to realize some advanced functions, such as chat room scenes.

3. characteristics of 3.WebSocket

  • Support two-way communication, real-time stronger
  • You can send text or binary data
  • Reduce traffic: As long as a WebSocket connection is established, you want to keep the connection status. Compared with HTTP, not only the total overhead per connection is reduced, but also the traffic is reduced due to the small header information of WebSocket.

Compared with the traditional HTTP request-response mode, which requires the client to establish a connection with the server, WebSocket is a TCP long connection communication mode similar to Socket. Once a WebSocket connection is established, subsequent data are transmitted in the form of a frame sequence. Before the client disconnects the WebSocket connection or the Server disconnects, there is no need for the client and the server to re-initiate the connection request.Under the condition of massive concurrency and large load flow of client-server interaction, the consumption of network bandwidth resources is greatly saved, and obvious performance advantages are achieved; moreover, the client sends and receives messages on the same persistent connection, and real-time advantages are obvious.

Next, I’ll look at how websocket can realize two-way communication between client and 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() {
 Log ('client connection succeeded')
 //Send another message to the server
 Socket.send('hello') // the content of the message sent by the client is hello
 }
 //Bind events by adding attributes
 socket.onmessage = function(event) {
 clockDiv.innerHTML = event.data
 Log ('server-side response received', 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 ws module and monitor port 9999
 let wsServer = new WebSocketServer({ port: 9999 })
 //Monitor the connection request of the client 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)
 Log ('client connection succeeded')
 //Monitor messages sent by the other party
 socket.on('message', function(message) {
 Log ('messages Received from Clients', Message)
 Socket.send ('server response:'+message)
 })
 })

Start local service, openhttp://localhost:3000/websocket.htmlThe results are as follows:

Three, the comparison of Web real-time push technology

Mode Type Technical realization Advantages Disadvantages Applicable scenario
Polling polling client→server Client circular request 1, simple implementation 2, support cross-domain 1. Waste of bandwidth and server resources 2. Most of the one-time request information is useless (complete http header information) 3. There is delay 4. Most of the requests are invalid. Suitable for small applications
Long-Polling client→server The server hold the connection and does not return until there is data or timeout, thus reducing the number of repeated requests. 1, simple implementation 2, no frequent requests 3, traffic saving 4, low delay 1, the server hold connection, will consume resources 2, a request information is useless WebQQ, Hi web page, Facebook IM
Long connection iframe client→server Embed a hidden iframe in the page, and set the src attribute of the iframe as a request for a long connection, so that the server can continuously input data to the client. 1, real-time delivery of data 2, no useless requests, one link, multiple “push” 1. The server increases overhead 2. It is impossible to know the connection state 3 accurately. IE, chrome, etc. will always be in the loading state. Gmail chat
WebSocket server⇌client new WebSocket() 1, support two-way communication, better real-time 2, can send binary files 3, reduce traffic 1. browser support is inconsistent 2. disconnection and reconnection are not supported Online games, bank interactions and payments

To sum up, the Websocket protocol not only solves the passivity of the server in HTTP protocol, that is, the communication can only be initiated by the client, but also solves the problem of delay in data synchronization. At the same time, it also brings obvious performance advantages. Therefore, the websocket
It is an ideal scheme for Web real-time push technology, but if it is compatible with lower version browsers, polling can be considered.

To recommend a useful BUG monitoring toolFundebug, welcome to try free!

Welcome to pay attention to the public number:Front end craftsmanWe witness your growth together! If you feel fruitful, please give me a reward to encourage me to output more high-quality open source content.

Reference article