1. The history of WebSocket

Before the emergence of Websocket, the interaction process of Web applications is usually that the client sends a request, and the server receives the request and responds to the client. However, such a processing mode will have great problems for applications with high real-time requirements and massive concurrency.

The traditional solution is polling: the client periodically sends a request to the server. If the server has data, it responds to the request. Otherwise, no processing is performed. The problem is obvious. Every connection requires a TCP connection, and most TCP connections are unnecessary. When there is no data, sending a request makes no sense.


The mechanism of the WebSocket

WebSocket is a new H5 protocol, which realizes full-duplex communication between browser and server, saving server resources and bandwidth and achieving real-time communication.

2. The difference between WebSocket and HTTP

Similarities:

  • It’s all built on top of TCP to transfer data

Difference:

  • Ws is full-duplex communication, in which both the server and the client can actively send data, whereas HTTP can only respond to requests from the client.
  • Ws is not affected by homology, whereas HTTP is affected by homology.
  • The request sent by WS will have an Upgrade: webSocket field and connection: Upgrade
  • Ws transmits binary or text data in frames, whereas HTTP transmits text data.
  • Ws still needs to use HTTP to establish TCP connection, and once the connection is successful, it will be upgraded from HTTP protocol to WS protocol, and the future processing is carried out on WS
  • The traditional HTTP protocol is stateless, each connection needs to know which client sent the request, but ws once the connection is successful, the server retains the information of all connected clients.

3. How to realize the function of Websocket in the early stage

  • Polling, explain what polling is: the client sends a request to the server at regular intervals, returns if there is a request result, and responds with empty data if there is no result. This problem is obvious, there will be too much request waste, and each HTTP request needs to establish a connection, waste bandwidth, inefficient;
  • Long polling: What is long polling (Comet)? Comet technology: The client sends a request, the server returns a response if there is a response, and then resends the request. But if there is no response, the server blocks the current request, that is, leaving the current request unfinished until there is response data, or until the connection times out.
  • Long link: In the HTTP protocol, the server should not be able to send messages to the client, but there is a workaround, can let the server actively send messages to the client, but the direction can only be server to client, the client does not have the ability to send data. This workaround is for the server to declare to the client that the next message to be sent is a stream, that is, instead of a packet, it is a stream of data. Instead of closing the connection, the client waits for data to flow through the server and receives it in the browser as an event.

The difference between websocket and websocket:

  • The long connection is unidirectional and supports only data flows from the server to the client. Websocket is full duplex communication.
  • Long links are text data sent. If you want to send binary data, it needs to be encoded. Websocket supports binary data by default.
  • Long connections can customize events, but webSockets cannot.
  • Long connections use HTTP, while Websockets use WS.

Front-end implementation:

Back-end implementation: