“

Life is too short to have a dog

“

First, all for communication

In order to avoid confusion, it should be clarified here that the end and end mentioned in this article specifically refer to the client (Browser/Server) and the Server under THE B/S (Browser/Server) architecture.

With the rise of Web applications, B/S architecture (i.e. browser/server architecture) emerged. B/S architecture adopts the working mode of browser request and server response, which causes the single data communication between end and end — that is, the server cannot actively transmit data to the browser end. In cases where real-time data is needed, such as leave approval, the common way is that the browser continuously initiates polling to the server to query the corresponding data.

Browser-initiated polling is generally divided into short polling and long polling. Both are implemented based on THE HTTP protocol and are non-persistent connections.

  • Short polling: Generally adoptedAjaxThe implementation. That is, the browser sends HTTP requests to the server at regular intervals to obtain the latest data.
  • Long polling: Long polling is similar to short polling in that the browser sends an HTTP request to the server to obtain the latest data. However, unlike short polling, long polling blocks on the server side until the latest data is retrieved or until a timeout occurs.

Both of the above polling methods have their drawbacks, more or less. Short polling sends data in real time and returns data in real time without blocking. However, polling frequency is very high in some scenarios to ensure real-time data acquisition. Although the long-poll blocking access mode avoids high-frequency access requests, the server needs to block each request, consuming more resources to maintain the corresponding long-poll. Both of these requests can be extremely taxing on the server side in extreme cases.

Is there a way to communicate quickly and cheaply between the browser and the server in real time? Based on this requirement, WebSocket protocol was born.

Two, “equal” communication

WebSocket is a protocol for full duplex communication over a single TCP connection. This means that the status of both parties using WebSocket for communication is “equal”, and data push can be initiated from the browser side or the server side.

Let’s go back to the above problem. The above problem is essentially because the HTTP protocol used in B/S architecture is a standard request-response mode. In this mode, only the browser can initiate the data query request, and the server cannot actively push the data. As a result, the data transmission is not real-time. Even if polling is used, it can only achieve quasi-real-time.

Using WebSocket protocol can solve the problem that the above server cannot initiate data push actively. Compared with HTTP requests that need to wait for the browser to initiate a request before responding, the real-time performance is stronger. Even when compared to long-polling like Comet, WebSockets are superior in concurrency and data processing. Let’s look at the process of WebSocket connection and communication.

3. WebSocket communication process

Both WebSocket and HTTP are based on TCP. However, HTTP is limited by its special working mode and can only be used as a half-duplex communication protocol, while WebSocket inherits the corresponding features of TCP. The WebSocket protocol has little to do with HTTP, but in order to ensure compatibility with existing browser handshake specifications, WebSocket uses HTTP to establish a connection.

Communication using WebSocket protocol is divided into two phases, namely handshake phase and communication phase.

  • handshake: In the handshake phase, the browser sends a request to the server to establish a connection using HTTP. This phase is similar to the TCP handshake logic. A communication connection can be established only after the handshake succeeds. In this process, WebSocket relies on THE HTTP protocol to initiate a handshake request, but unlike normal HTTP requests, contains some additional header information, including additional header information“Upgrade: WebSocket”This indicates that this is an HTTP request for protocol upgrade, which means that after the handshake is successful, the communication protocol will be switched from HTTP to WebSocket.
  • Communication stage: After a successful connection is established, a persistent connection is established between the browser and the server. Both sides of the communication can actively push or receive data to the other side, that is, data transmission is supported. In this process, the data are based onThe form of a frame sequenceFor transmission, data frames can be either text or binary streams.

In addition to the changes in communication mode, WebSocket has also made corresponding optimization in data transmission. For HTTP protocol, due to its stateless nature, each request sent must contain a complete protocol header. WebSocket, on the other hand, is a stateful protocol. After a handshake is completed and a connection is successfully established, the browser-server connection remains active until either side of the communication closes the connection. In the connection maintenance phase, because the corresponding status information or authentication information has been obtained in the handshake phase, only the actual data needs to be transmitted between the browser and server, and the remaining protocol packets are greatly reduced, which means that the cost of transmission is greatly reduced.

Four,

Does WebSocket have so many advantages that it’s time to replace HTTP? The answer, of course, is no. As we indicated at the beginning of this article, the WebSocket protocol is best used for real-time data exchange, such as in online chat rooms. In most of the current Web application scenarios, the browser (i.e. the user side) triggers the request for resource acquisition or change, and then the server responds, namely the request-response mode. Not to mention, WebSocket handshake is based on HTTP protocol to complete, so HTTP protocol’s dominant position is still unshakable.

There are many WebSocket API related documents and tutorials, so I will not introduce them here. If you are interested, you can search for them on your own.

This article is formatted using MDNICE