Why do we need HTML5 WebSocke

Why do we need HTML5 WebSocke

Introduction to HTML5 WebSocket

As the next-generation Web standard, HTML5 has many notable new features, such as Canvas, local storage, multimedia programming interfaces, and WebSocket. Specifically, WebSocket, called "Web TCP", attracts the attention of developers. The emergence of WebSocket makes it possible for the browser to provide Socket support, thus providing a two-way channel based on TCP connection between the browser and the server. Web developers can easily use WebSocket to build real-time web applications. In this way, developers have become more powerful.

Real-time Web application dilemma

The information interaction process of a Web application is usually when a client sends a request through a browser. After receiving and reviewing the request, the server processes the request and returns the result to the client. Then, the client browser displays the information, this mechanism is still safe for applications with less frequent information changes. However, for applications with high real-time requirements, such as online games and stock queries, online Securities, device monitoring, online news broadcast, RSS subscription push, etc. When the client browser is ready to present the information, the information may be outdated on the server. Therefore, keeping the client and server information synchronized is a key element of real-time Web applications, which is also a challenge for Web developers. Before the WebSocket specification came out, developers had to adopt some compromise solutions to implement these real-time Web applications. The most common among them was Polling and Comet technologies. The Comet technology is actually an improvement of the polling technology. It can be subdivided into two implementation methods: Long polling mechanism and stream technology. Below we will briefly introduce these technologies:

Round robin:

This is the earliest solution to implement real-time Web applications. The client sends a request to the server at a certain interval, and maintains the synchronization between the client and the server in the form of frequent requests. The biggest problem with this synchronization solution is that when the client initiates a request to the server at a fixed frequency, the data on the server may not be updated, which will lead to a lot of unnecessary network transmission, therefore, this is a very inefficient real-time solution.

Long polling:

Long round robin improves and improves regular round robin to reduce invalid network transmission. When no data is updated on the server, the connection will be retained for a period of time until the data or status changes or the time expires. This mechanism can be used to reduce the interaction between invalid clients and servers. Of course, if the data on the server is frequently changed, this mechanism does not substantially improve performance compared with regular polling.

Stream:

The stream technology solution usually sends a persistent connection request to the server using a hidden window on the client page. The server responds to this request and constantly updates the connection status to ensure that the connection between the client and the server does not expire. This mechanism can continuously push server information to the client. This mechanism has a problem in user experience. You need to design different solutions for different browsers to improve the user experience. At the same time, when the concurrency is large, it is a great test for server resources.
Based on these solutions, you will find that the so-called real-time technologies we are currently using are not real-time technologies. They are just simulating real-time effects using Ajax, each interaction between the client and the server is an HTTP request and response process, and each HTTP request and response carries the complete HTTP header information, this increases the amount of data transmitted each time, and the client and server programming implementations in these solutions are complicated. In actual applications, in order to simulate real-time results, developers often need to construct two HTTP connections to simulate two-way communication between the client and the server. One connection is used to process data transmission from the client to the server, A connection is used to process data transmission from the server to the client, which increases programming complexity and server load, and restricts the scalability of the application system.

WebSocket rescue

HTML5 WebSocket is designed to replace the polling and Comet technologies so that the client browser can communicate with the desktop system in real time in a C/S architecture. The browser sends a WebSocket connection request to the server through JavaScript. After the connection is established, the client and the server can directly exchange data through the TCP connection. WebSocket connection is essentially a TCP connection. Therefore, compared with polling and Comet technologies, it has great performance advantages in terms of data transmission stability and data transmission volume. The Websocket.org website provides a detailed test and comparison of the traditional polling and WebSocket call methods, and implements a simple Web application using the polling and WebSocket methods respectively, here we reference their test result diagram:

 

Network load comparison between polling and WebSocket implementation

 

This figure clearly shows that the WebSocket solution has a great performance advantage over the traditional Ajax polling solution when the traffic and load increase. This is why we think WebSocket is the preferred solution for real-time Web applications in the future.