WebSocket introduction and best practices

I. Background: From a need

Requirement: “Scan the QR code of the client and display the parameter information of the client on the Web”

Focus: Real-time Web applications, real-time bidirectional communication between Client and Server.

2. Traditional solutions?

Polling (Polling) : also called periodic Polling

The Client periodically sends requests to the Server to maintain data synchronization with the Server. Typical application scenarios:

• Ajax technology, partial refresh of Web pages

Disadvantages:

• Bandwidth and CPU resources: The Client periodically sends requests to the Server. However, the Client still sends requests even when there is no data update on the Server. This wastes bandwidth and consumes CPU resources on the Server

• Real-time: There will be data delay within the polling interval

Long Polling: improvements and enhancements to normal Polling

Goal: To save bandwidth and reduce invalid network traffic.

Basic Principles:

• Keepalive: HTTP layer, keepalive: After the Server receives the request from the Client, if there is no data update, the connection is kept for a period of time.

• This reduces invalid client-server interactions until data is updated or the connection times out.

• By maintaining connections, the number of requests and responses is reduced and bandwidth is saved.

Defect:

• Bandwidth saving and limited effect: The HEAD part of HTTP packets contains a large amount of data (400+ bytes), but only a small amount of valid data (10 bytes). Such packets are transmitted periodically on the network, wasting bandwidth.

• Real-time data in the case of frequent data updates: When the data on the Server is frequently updated, the Server must wait for the arrival of the next request before sending the updated data, with a maximum delay of 1.5x RTT (round trip time).

• In the case of network congestion, the wait time is longer because the connection needs to be re-established.

Essential reasons:

• Keepalive: The need to re-establish the HTTP connection (HTTP 1.1 can only be alleviated, but cannot be completely solved in principle)

• Data format: It is still the data format of the application layer. HTTP HEADER data occupies a large space

Event Flow Mode (SSE)

• With SSE, clients can automatically get data updates without having to repeatedly send HTTP requests. Once the connection is established, the “event” is automatically pushed to the client. Server-side SSE generates and pushes events in the format of Event Stream.

• It can realize one-way data communication from server to client.

• Compared with polling, SSE has better real-time performance and is very simple to use.

Disadvantages:

• In large concurrency cases, the server may go down.

• SSE only supports one-way server-to-client push of events, and all versions of IE (including Microsoft Edge so far) do not support SSE. If you need to force support for Internet Explorer and some mobile browsers, try EventSource Polyfill (still polling in essence)

What is WebSocket?

B/S request-response mode

• In traditional Web, Browser sends requests to the Server to obtain data on the Server.

• To achieve real-time communication, the Server obtains data in real time. Usually, the Client sends HTTP requests periodically, and the Server responds with data.

• HTTP protocol: a one-way, stateless, application-layer protocol based on the request/response pattern;

Introduction of WebSocket

The WebSocket protocol borrows the HTTP Switch Protocol 101(101) status code to convert the protocol to the WebSocket protocol, which is based on Tcp.

Features:

• Two-way communication between the Client and the Server, the Client and the Server, can initiate communication

• Is a network communication protocol

• Based on the transport layer TCP protocol

Advantages:

• Bandwidth saving; (HTTP has a larger HEAD)

• Save server CPU resources; (HTTP protocol Polling method, even if the Server does not have data to receive Request)

The following figure shows the efficiency of Web applications in Polling and WebSocket modes:

Four, protocols,

First, WebSocket is a persistent protocol, as opposed to HTTP, which is not persistent. The HTTP lifecycle is defined by a Request, i.e., a Request and a Response. In HTTP1.0, the HTTP Request ends. HTTP1.1 has been improved to use keep-alive to keep a connection, but it is still a Request = a Response.

Shake hands

Handshake information from the client:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13Copy the code

Key request header meaning:

• Connection: Upgrade: indicates that the protocol is to be upgraded

• Upgrade: websocket: indicates that the webSocket protocol is to be upgraded.

• Sec-websocket-version: 13: indicates the WebSocket Version. If the server does not support the version, you need to return an sec-websocket-versionheader containing the version number supported by the server.

• Sec-websocket-key: is a Base64 encode value randomly generated by the browser. It is compatible with the sec-websocket-Accept value at the end of the server response. It is used for server verification and provides basic protection, such as malicious connections.

• Sec_websocket-protocol: is a user-defined string used to distinguish protocols required by different services under the URL.

Handshake message from the server:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chatCopy the code

Key response header meaning:

• Sec-websocket-accept Is calculated based on the sec-websocket-key in the header of the client request.

• Connection and Upgrade are used to Upgrade the websocket protocol.

Shred data frames

The minimum unit of communication between WebSocket client and server is frame, which consists of one or more frames to form a complete message.

• Sender: the message is cut into multiple frames and sent to the server;

• Receiver: Receives message frames and reassembles the associated frames into complete messages;

The data transfer

Once the WebSocket client and server establish a connection, subsequent operations are based on the transmission of data frames.

Each WebSocket message may be split into multiple data frames. When a WebSocket receiver receives a data frame, it determines whether it has received the last data frame of the message based on the value of FIN (the identifier used to determine whether the current frame is the last frame of the current message).

When the last frame of the message is received, the message can be processed.

The heartbeat detection

Connection closure can be triggered for many reasons. In general, the onClose event will be triggered, but in the case of disconnection, the onClose event will not be triggered, and the connection is not known to be broken. In this case, heartbeat reconnection can be used. A PONG response will occur, at which point you can reconnect. Heartbeat reconnection is not polling, which keeps establishing connections (multiple connections) while the heartbeat is still the same connection, just sending probe messages.

Close the connection

Once a Close control frame is sent or received, the WebSocket Close phase handshake starts.

Close status code table (close reason)

Five, the advantage

• Compared with HTTP, WebSocket supports persistent connections.

• The header information exchanged between the server and client is small, about 2 bytes;

• Both client and server can actively send data to each other, true full-duplex;

• Create TCP requests and destroy requests without frequency, reduce the occupation of network bandwidth resources, and save server resources.

Six, summarized

WebSocket can be flexible, simple and efficient in bidirectional transmission and message push, but it is not very useful in ordinary request-response process. Compared with ordinary HTTP Request, it is much more troublesome and even less efficient. For example, some scenarios only require simple request-Response. If WebSocket is used, a Request identifier RequestId needs to be added, which increases the cost. Each technology has its own advantages and disadvantages, and can be best used where it is suitable. However, it may be counterproductive to see a few advantages of its comprehensive promotion regardless of the occasion.

Seven, practice

1. Flow chart

2, Attention Point

• Spring WebSocket requires tomcat 7.x or later.

• Websocket support requires nGINx and nGINx to add support for webSocket protocol configuration;

3, the Details

1. The web page initialization generates a unique identifier to identify the current Web page.

2. The unique identifier is placed in the URL address of the TWO-DIMENSIONAL code to generate two-dimensional code;

3. The APP side scans and requests the service corresponding to the TWO-DIMENSIONAL code. At the same time, this request carries the unique identifier of the Web side page and some parameter information of the APP.

4. The server receives the request, processes the parameters and returns them to the Web page with a unique identifier.

5. The Web-side component displays information about the server’s response.

4. Front-end plug-in recommendations

We use SpringMVC+React to separate the front and back ends. Here we recommend several React plugins:

Two-dimensional code generation plug-in: github.com/zpao/qrcode…

Cookie plug-in: www.npmjs.com/package/rea…

Eight, reference

Ningg. Top/websocket – I…

Segmentfault.com/a/119000001…

Segmentfault.com/a/119000001…

The attached:Polling, long polling, short connection, long connection difference comparison