On the mechanism of HTML5 WebSocket

Recall 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 server full-duplex communication (do not know to see the full-duplex communication RS-422 standard), can better save server resources and bandwidth and achieve real-time communication, it is based on TCP. As with HTTP through TCP for data transmission, but it is the most different from http:

WebSocket is a two-way communication protocol, after establishing the connection, both Websocketserver and browser/client agents can send or receive data to each other actively, like a socket;

WebSocket needs similar TCP client and server side through handshake connection, the ability to communicate with each other after successful connection.

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

Traditional HTTP Request Response Clientserver interaction diagram

Watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqv/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/dissolve/70/gravity /center "/>
Using the WebSocket mode client interacts with the server such as the following:
WebSocket Request Response Clientserver interaction diagram

It can be seen according to the above two graphs. In contrast to the traditional HTTP each request-response requires the client to establish a connection mode with the server. WebSocket is a TCP long-connected communication mode with similar sockets, and once the WebSocket connection is established, it is likely that the data will be transmitted in the form of a frame sequence.

Before the client disconnects the WebSocket connection or the server side breaks the connection. There is no need for the client and the server to initiate a connection request again.

In the case of massive concurrency and high interaction load traffic between client and server. Greatly saves the network bandwidth resource consumption, has the obvious performance superiority, and the client sends and accepts the message is initiates on the same persistent connection. Real-time advantage is obvious.

WebSocket and HTTP messages

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

In client (browser-side JS), create WebSocket to instantiate a new WebSocket client object, connecting a server-side WebSocket URL of similar ws://yourdomain:port/path. The WebSocket client object will actively parse and identify itself as a WebSocket request to connect to the server port, run the two-party handshake process, and the client sends a data format similar to:

WebSocket Client Connection Message

You can see that the client-initiated WebSocket connection message is similar to the traditional HTTP message, and the "Upgrade:websocket" reference indicates that this is a WebSocket type request. "Sec-websocket-key" is a base64 encoded ciphertext sent by Websocketclient. Requires the server to return an appropriately encrypted "sec-websocket-accept" answer, otherwise the client throws an "error during WebSocket handshake" fault and closes 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 the client-consistent key, "http/1.1 101 Switching Protocols" Indicates that the server accepts a client connection to the WebSocket protocol after this request-response processing. The WebSocket connection handshake on the client server is successful and may be able to communicate with TCP.

You are welcome to follow my blog. Follow me on Weibo, if in doubt. Please add QQ group: 454796847, 135430763 common progress!

On the mechanism of HTML5 WebSocket