Small knowledge, big challenge! This paper is participating in theEssentials for programmers”Creative activities

Introduction to the

We know that WebSocket is a network protocol based on TCP, which is used for real-time communication between the client and the server. Very easy to use. The easiest way to use WebSocket is to communicate directly with the server using the browser API.

This article will take a closer look at the WebSocket message interaction format to help you understand how WebSocket works.

WebSocket handshake flow

We know that WebSocket is upgraded on the basis of HTTP protocol in order to be compatible with HTTP protocol. After the HTTP connection is established between the client and server, the client sends the server a protocol to upgrade to webSocket, as shown below:

GET /chat HTTP/1.1
Host: example.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Copy the code

Note that the HTTP version must be 1.1 or higher. The HTTP request method must be GET

By setting the Upgrade and Connection headers, we are ready to Upgrade to webSocket.

Except for the attributes listed here, all HTTP header attributes are acceptable.

There are two more special headers, which are sec-websocket-version and sec-websocket-key.

Take a look at sec-websocket-version, which represents the Version of the WebSocket requested by the client. If the server does not understand the Request sent by the client, it will return a 400 (“Bad Request”) in which the server will return a failure message.

If you do not understand the sec-websocket-version sent by the client, the server also returns sec-websocket-version to inform the client.

One header field of particular interest here is sec-websocket-key. Let’s take a look at what this field does.

When the server receives the request from the client, it returns a response telling the client that the protocol has been upgraded from HTTP to WebSocket.

The returned response might look something like this:

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

The sec-websocket-Accept is generated from the sec-websocket-key in the client request. Specifically, connect the sec-websocket-key sent by the client with the string “258eafa5-e914-47DA-95CA-C5AB0DC85B11”. Then use SHA1 algorithm to get its hash value.

Finally, base64 encodes the hash value.

After the server returns sec-websocket-Accept, the client can verify it to complete the handshake process.

WebSocket message format

WebSocket is used because clients and servers can send messages anytime and anywhere. This is the magic of Websocket. So what format is the message sent? Let’s take a closer look.

The communication between the client and server is transmitted in frame format. The frame format is as follows:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-------+-+-------------+-------------------------------+ |F|R|R|R| opcode|M| Payload len | Extended payload length | |I|S|S|S| (4) |A| (7) | (16/64) | |N|V|V|V| |S| | (if payload len==126/127) | | |1|2|3| |K| | | +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + | Extended payload length continued, if payload len == 127 | + - - - - - - - - - - - - - - - +-------------------------------+ | |Masking-key, if MASK set to 1 | +-------------------------------+-------------------------------+ | Masking-key (continued) | Payload  Data | +-------------------------------- - - - - - - - - - - - - - - - + : Payload Data continued ... : + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Payload Data continued ... | +---------------------------------------------------------------+Copy the code

MASK indicates whether the message is encoded. For messages coming from the client, MASK must be 1. If the MASK of the message sent from the client to the server is not 1, the server needs to disconnect the message from the client. However, for messages sent from the server to the client, the MASK field does not need to be set.

Rsv1-3 is an extended field and can be ignored.

Opcode is how to interpret the payload field. Payload is the actual message that gets sent. 0x0 represents continue, 0x1 represents text, 0x2 represents binary, and the rest represents control fields.

FIN indicates whether it is the last frame of the message. If it is 0, the message has more frames. A value of 1 indicates that the frame is the last part of the message and is ready to process the message.

Why do I need the Payload len field? Because we need to know when to stop receiving messages. So you need a field that represents payload to process the message specifically.

What’s the Payload? This one is more complicated.

  1. First read the 9-15 bits and parse them into unsigned integers. If it’s less than 125, then this is the length of the payload. End. If it’s 126, go to step 2. If it’s 127, go to step 3.
  2. Read the next 16 bits and parse it to an unsigned integer, ending.
  3. Read the next 64 bits. Parse it as a signed integer. The end.

If Mask is set, the next four bytes, or 32bits, are read. This is the masking key. When the data is read, we get the payload:ENCODED, and the MASK key. To decode, the logic is as follows:

var DECODED = "";
for (var i = 0; i < ENCODED.length; i++) {
    DECODED[i] = ENCODED[i] ^ MASK[i % 4];

Copy the code

FIN can be used in conjunction with OpCode to send long messages.

FIN=1 means, is the last message. 0x1 indicates a text message, 0x2 0 indicates a binary message, and 0x0 indicates that the message has not ended, so 0x0 is usually used with FIN=0.

Extensions and Subprotocols

During the client-server handshake, the client can also send Extensions or Subprotocols on top of the standard WebSocket protocol. What’s the difference between these two?

First, both are set via HTTP headers. But there’s a big difference. Extensions can control the WebSocket and modify the payload, whereas subProtocols defines the structure of the payload and does not modify it.

Extensions are optional, while Subprotocols are required.

You can think of Extensions as data compression, which compresses or optimizes data on top of webSocket to make messages shorter.

Subprotocols represent the format of the message, such as using SOAP or WAMP.

Subprotocol is developed on the basis of WebSocket protocol, mainly used for the processing of specific scenarios, it is based on the WebSocket protocol, the establishment of a more strict specification.

For example, when a client requests a server, it places the corresponding Protocol in the sec-websocket-protocol header:

GET /socket HTTP/1.1
...
Sec-WebSocket-Protocol: soap, wamp
Copy the code

The server will return corresponding returns based on the supported types, for example:

Sec-WebSocket-Protocol: soap
Copy the code

conclusion

This article explains the specific format of webSocket message interaction, and you can see that many powerful protocols are composed of the most basic structures.

This article is available at www.flydean.com/07-websocke…

The most popular interpretation, the most profound dry goods, the most concise tutorial, many tips you didn’t know waiting for you to discover!

Welcome to pay attention to my public number: “procedures those things”, understand technology, more understand you!