On the mechanism of HTML5 WebSocket

Review the previous chapter

In the previous chapter, "Why do we need HTML5 WebSocket", I briefly introduced the next WebSocket of the past life. I believe that we have a preliminary understanding of the websocket. So today we continue to study the mechanism of websocket in depth.

WebSocket mechanism

We know that WebSocket is HTML5 a new kind of protocol. It realizes the browser and the server full-duplex communication (do not know can look at the full-duplex communication RS-422 standard), can better save the server resources and bandwidth and achieve real-time communication, it is based on TCP, the same as HTTP through TCP to transfer data, but it and the HTTP maximum difference is:

WebSocket is a two-way communication protocol, after establishing the connection, both the WebSocket server and the browser/client agent can send or receive data to each other proactively, just like a socket.

WebSocket requires a TCP-like client and server-side handshake connection to communicate with each other after a successful connection.

The non-websocket mode traditional HTTP client interacts with the server as follows:

Traditional HTTP Request Response Client Server interaction diagram
using WebSocket mode the client interacts with the server as follows:
WebSocket Request Response Client Server interaction diagram

According to the above two graphs, it can be seen that compared to the traditional HTTP each request-response requires the client and the server to establish a connection mode, WebSocket is similar to the socket TCP long connection communication mode, once the WebSocket connection is established, Subsequent data is transmitted in the form of a sequence of frames. The client and the server are not required to re-initiate the connection request before the client disconnects the WebSocket connection or the servers end the connection. In the case of large amount of concurrency and high client-server interaction load, the consumption of network bandwidth resources is greatly saved, and the performance advantage is obvious, and the client sends and receives messages on the same persistent connection, and the real-time advantage is obvious.

WebSocket and HTTP messages

Let's take a look at the different interactions between websocket communication and traditional http:

At the client (browser-side JS), create WebSocket to instantiate a new WebSocket client object, connecting a server like Ws://yourdomain:port/path WebSocket url,websocket Client objects are automatically parsed and identified as WebSocket requests, thereby connecting to the server port, performing both handshake processes, and the client sends a data format similar to:

WebSocket Client Connection Message

As you can see, the client-initiated WebSocket connection message is similar to the traditional HTTP message, and the "upgrade:websocket" parameter value indicates that this is a WebSocket type request, "Sec-websocket-key" is a base64 encoded ciphertext sent by the WebSocket client that requires the server to return a corresponding encrypted "sec-websocket-accept" answer, otherwise the client throws "Error during WebSocket handshake" Error, and close the connection.

The data format returned by the server after receiving the message is similar:

WebSocket Service-side response message

The value of "Sec-websocket-accept" is returned to the client after the server is computed with a client-consistent key, and "http/1.1 101 switching Protocols" indicates that the server accepts a client connection to the WebSocket protocol, After such a request-response processing, the client service side of the WebSocket connection handshake succeeds, the subsequent TCP communication can be made.

Welcome to pay attention to my blog, follow my micro-blog, if there is doubt, please add QQ Group: 454796847, 135430763 common progress!

On the mechanism of HTML5 WebSocket