With HTTP protocol, why do we need Websocket?

[[428410]]

WebSocket is a full-duplex communication protocol based on TCP connection. Compared with HTTP, a non-persistent protocol, WebSocket is a persistent network communication protocol.

It not only enables the client to request the server, but also allows the server to actively push data to the client. In the WebSocket API, the client and the server only need to complete a handshake, and a persistent connection can be directly established between the two, and two-way data transmission can be carried out.

Why do we need WebSocket?

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

HTTP is stateless, that is, it treats each request as unique and independent. A stateless protocol has some advantages, for example, the server does not need to keep information about the session and thus does not need to store data. However, this also means that redundant information about the request is sent in each HTTP request and response, such as using cookies to verify the user status.

As the interactions between clients and servers increase, the amount of information required by the HTTP protocol to communicate between clients and servers increases rapidly.

Fundamentally speaking, HTTP is still a half-duplex protocol, that is, at the same time, the flow of information can only be one-way: the client sends a request to the server (one-way), and then the server responds to the request (one-way). The communication efficiency of half-duplex mode is very low.

At the same time, the HTTP protocol has a flaw: communication can only be initiated by the client.

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

In order to obtain server changes in a timely manner, we have tried various methods:

• Polling: Send a request every once in a while to find out if the server has any new information. It is not accurate, has delays, and exchanges a lot of invalid data.
• Long polling: The client requests information from the server and maintains the connection for a set period of time. Until the server responds with a new message or the connection times out, this technique is often called "hanging GET" or "pending POST". It takes up server resources, has no advantage over polling, and is not standardized.
• Streaming: In streaming, the client sends a request and the server sends and maintains an open response that is continuously updated and kept open (either indefinitely or for a specified period of time). The server updates the response whenever it has information to deliver to the client. The server never sends a complete HTTP response. Proxies and firewalls may cache responses, causing increased latency in the delivery of information.

The above methods provide near real-time communication, but they also involve HTTP request and response headers, which contain a lot of additional and unnecessary header data and delays. 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 pressure on the server.

What is WebSocket

Websocket is a natural full-duplex, bidirectional, single-socket connection that solves the problem that the 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 clients and servers over the Web and supports the transmission of binary data and text strings.

This protocol consists of an initial handshake and a basic message framework, and is based on the TCP protocol. Compared to the HTTP protocol, once a Websocket link is established, two-way real-time communication can be performed.

Features include:

(1) Built on the TCP protocol, the server-side implementation is relatively easy.

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

(3) The data format is relatively lightweight, with low performance overhead and efficient communication.

(4) You can send text or binary data.

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

Similar technologies

Server-sent Events (SSE):

https://www.ruanyifeng.com/blog/2017/05/server-sent_events.html

https://www.cnblogs.com/goloving/p/9196066.html

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

https://baike.baidu.com/item/SPDY/3399551#7

WebRTC

https://baike.baidu.com/item/WebRTC/5522744

Communication Principles

How is a WebSocket connection established?

As mentioned above, WebSocket uses the HTTP protocol in the handshake phase. WebSocket borrows part of the HTTP protocol to complete a handshake. (The HTTP three-way handshake is only completed once here)

HTTP request and response headers

WebSocket request and response headers

Link communication simulation

HTTP Polling

The first is ajax polling, which is very simple. It lets the browser send a request every few seconds to ask the server if there is any new information.

Scene Reproduction:

• Client: La la la, is there any new information? (Request)
• Server: No (Request)
• Client: La la la, is there any new information? (Request)
• Server: No. (Response)
• Client: La la la, is there any new information? (Request)
• Server: You are so annoying, no. (Response)
• Client: La la la, is there any new message? (Request)
• Server: OK, OK, I have it for you. 'Xi Ling is really handsome'. (Response)
• Client: La la la, is there any new message? (Request)
• Server: ... No ... No ... 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 feature of the HTTP protocol, passivity. At the same time, after each request and response of http, the server discards all client information, and the next request must carry identity information (cookie), which is stateless.

WebSocket

The client sends a request to the server with a letter via http (riding a horse), but at the same time, it carries Upgrade:websocket and Connection:Upgrade (two pipes). If the server supports the WebSocket protocol (interface with two pipes), it returns available information using the Websocket protocol (discarding the horse). After that, the transmission of information will use these two pipes, unless one party manually cuts off the pipe. If the server does not support it, the client's request for connection fails and an error message is returned.

The emergence of Websocket solves these problems neatly.

So the above scenario can be modified as follows.

• Client: La la la, I want to establish a Websocket protocol, required service: chat, Websocket protocol version: 13 (HTTP Request)
• Server: OK, confirmed, upgraded to Websocket protocol (HTTP Protocols Switched)
• Client: Please send me the information when you have it.
• Server: OK, I’ll tell you sometimes.
• Client: balabala start fighting pictures balabala
• Server: Cang*kongbala
• Client: My nose is bleeding. I’ll wipe it off…
• Server: Hahaha that’s awesome hahahaha
• Server: I am dying of laughter. Haha.

This article is reproduced from the WeChat public account "GoGo's Front-end World"