Small knowledge, big challenge! This article is participating in the creation activity of “Essential Tips for Programmers”

This article has participated in the “Digitalstar Project” and won a creative gift package to challenge the creative incentive money.

WebSocket is a protocol for full-duplex communication over TCP connections. Compared with HTTP, which is not a persistent protocol, WebSocket is a persistent network communication protocol.

It can not only realize the client request server, but also allow the server to actively push data to the client. In the WebSocket API, the client and server only need to complete a handshake to directly create a persistent connection and two-way data transfer.

Why WebSocket

In the Web application architecture, connections are handled by HTTP/1.0 and HTTP/1.1. HTTP is the protocol used for request-response in client/server mode, in which a client (typically a browser) submits an HTTP request to a server, and the server responds to the requested resource (such as an HTML page).

HTTP is stateless, that is, it treats each request as unique and independent. Stateless protocols have some advantages, such as the fact that the server does not need to store information about the session and therefore does not need to store data. However, this also means that redundant information about the request is sent in every HTTP request and response, such as using cookies for user state validation.

With the increase of the interaction between the client and the server, the amount of information required by the HTTP protocol for the communication between the client and the server increases rapidly.

Basically, HTTP is a half-duplex protocol, which means that information flows in one direction at a time: the client sends a request to the server (one-way), and the server responds to the request (one-way). Half – duplex communication efficiency is very low.

The HTTP protocol also has a flaw: communication can only be initiated by the client.

The nature of this one-way request means that if the server has a state change, it cannot actively notify the client.

In order to keep track of server changes, we have tried various methods:

Polling: Periodically issuing a request to find out if the server has new information. Inaccurate, delayed, massive invalid data exchange.

Long polling: The client requests information from the server and keeps the connection open for a set period of time. Until the server responds with a new message, or the connection times out, this technique is often referred to as “suspend GET” or “suspend POST.” Occupying server resources, there is no advantage over polling, no standardization.

Streaming: In streaming, the client sends a request, and the server sends and maintains an open response that is constantly updated and kept open (either indefinitely or for a specified period of time). Whenever the server has information it needs to deliver to the client, it updates the response. The server never issues a complete HTTP response. Proxies and firewalls may cache responses, resulting in increased delays in information delivery.

The above methods provide near-real-time communication, but they also involve HTTP request and response headers, which involve a lot of additional and unnecessary header data and latency. In addition, in each case, the client must wait for the request to return before making subsequent requests, which significantly increases the delay. It also greatly increases the strain on the server.

What is the WebSocket

Websocket is a natural full-duplex, bidirectional, single-socket connection, which solves the problem that HTTP protocol is not suitable for real-time communication. It was proposed in 2008 and became an international standard in 2011.

The Websocket protocol enables full-duplex communication between the client and server through the Web, and supports transmission of binary data and text strings.

The protocol consists of an initial handshake and a basic messaging framework that is built on top of TCP. Compared with HTTP protocol, Websocket link can be two-way real-time communication once established.

Its features include:

(1) Based on THE TCP protocol, the implementation of the server side is relatively easy.

(2) It has good compatibility with HTTP protocol. The default ports are also 80 and 443, and the handshake phase uses HTTP protocol, so it is not easy to mask the handshake and can pass various HTTP proxy servers.

(3) The data format is relatively light, the performance overhead is small, and the communication is efficient.

(4) Can send text, can also send binary data.

(5) There is no source restriction, and the client can communicate with any server.

A similar technique

Server-sent Events (SSE) :

www.ruanyifeng.com/blog/2017/0…

www.cnblogs.com/goloving/p/…

SPDY (pronounced “SPeeDY”) : no longer maintained, replaced by HTTP/2

Baike.baidu.com/item/SPDY/3…

WebRTC

Baike.baidu.com/item/WebRTC…

Communication principle

How are WebSocket links established?

As mentioned earlier, WebSocket uses THE HTTP protocol in the handshake phase. WebSocket borrows part of the HTTP protocol to complete a handshake. (HTTP three handshakes, only one is done here)

HTTP request and response headers

WebSocket request and response headers

Link communication simulation

HTTP polling

The first is Ajax polling, which is simple enough that the browser sends a request every few seconds to ask if the server has new information.

Scene representation:

Client: la la la, any new information (Request) Server: No (Request) Client: la la la, any new information (Request) Server: no. (Response) Client: la la la, do you have any new information (Request) server: You are so annoying, no. (Response) Client: la la la, any new message (Request) server: ok la la, yes for you ‘Xiling is so handsome’. (Response) Client: la la la, is there any new message (Request) server:… No… No.. There is no

As can be seen from the above, polling is actually constantly establishing HTTP connections, and then waiting for the server to process, which can reflect another characteristic of HTTP protocol, passivity. At the same time, after the end of each HTTP request and response, the server will discard all client information, the next request, must carry identity information (cookie), stateless.

WebSocket

The client requests the server via HTTP (riding) with a message, but at the same time, carries Upgrade: webSocket and Connection:Upgrade (two tubes). If the server supports the WebSocket protocol (two tubes interface), The Websocket protocol is used to return the available information (discarding the horse), and thereafter the information is transmitted through both tubes, unless either party manually cuts the tubes off. If the server does not support the connection, the client fails to request the connection and an error message is displayed.

Websocket, a clean solution to these problems.

So the above scenario can be modified as follows:

Client: la la la, I want to establish the Websocket protocol, the required service: chat, Websocket protocol version: 13 (HTTP Request) server: Yes, it has been upgraded to Websocket (HTTP Protocols Switched client) : Please push the information to me when you have it. Server: OK, I’ll tell you sometime. Client: Balabala starts fighting balabala server: God * empty Bala client: Nosebleed, I wipe… Server: hahahahaha cow XX ahhahahahaha server: laughahaha

I laughed to death and wrote the next article “Websocket server and client implementation”.

See you guys!

I heard there are awards for comments. Why don’t you leave me a message?