WebSocket principle Analysis

The communication process of a Web application is usually a request made by the client through the browser, the server side receives the request to process and returns the result to the client, and the client browser renders the information. This mechanism can be well supported for applications where information change is not particularly frequent, but it is very tight for applications with high real-time demand and massive concurrency, especially in the current trend of booming mobile internet, high concurrency and users ' real-time response are the problems that Web applications often face, such as real-time information of financial securities, Geographic access in Web navigation apps, real-time message push for social networks, and more.

The traditional request-response pattern of web development typically employs a real-time communication scheme when dealing with such business scenarios. For example, the common polling scheme, the principle of simple and understandable, is the client at a certain time interval of frequent requests to the server to send requests to maintain client and server side of the data synchronization. The problem is also obvious: when a client sends a request to the server at a fixed frequency, the server-side data may not be updated, causing a lot of unnecessary requests, wasting bandwidth, and inefficient.

Based on the flash,adobeflash through its own socket implementation of the data exchange, and then use Flash to expose the corresponding interface to JavaScript calls, so as to achieve real-time transmission purposes. This approach is more efficient than polling and is widely used because of the high flash installation rate. However, the support of Flash on the mobile Internet terminal is not good: The iOS system does not support flash,android although it supports flash but the actual effect is not satisfactory, and the hardware configuration of mobile devices requires a high. In 2012, Adobe officially announced that it would no longer support the android4.1+ system, announcing the death of flash on mobile devices.

Traditional Web mode, when dealing with high concurrency and real-time demand, will encounter insurmountable bottleneck, and need an efficient and energy-saving bidirectional communication mechanism to ensure the real-time transmission of data. In this context, the WebSocket, which is based on the HTML5 specification, is called the Web TCP . Early HTML5 did not form an industry-uniform specification, and each browser and application server vendor had a similar implementation, such as the Mqtt of IBM, the Comet Open source framework, and so on. Until 2014, HTML5 finally dust landed, formally implemented as the actual standard specification, the application server and browser vendors gradually began to unify, in JavaEE7 also realized the WebSocket agreement. At this point, both the client and the server WebSocket are complete.

Users can consult the HTML5 specification and familiarize themselves with the new HTML protocol specification and WebSocket support.

I. Mechanism of WebSocket

The following is a brief introduction to the principle and operating mechanism of websocket.

WebSocket is a new kind of protocol for HTML5. It realizes the browser and the server full-duplex communication , can better save the server resources and bandwidth and achieve the purpose of real-time communication. It transmits data in the same way as HTTP through an established TCP connection, but the maximum difference between it and HTTP is:

• WebSocket is a two-way communication protocol. After establishing the connection, the WebSocket server side and the client can send or receive data to each other , just like a socket.
• WebSocket need to establish a connection, like TCP, to communicate with each other before the connection is successful

The traditional HTTP client and server request response modes are as follows:

WebSocket mode client and server request response modes such as:

Compared with the traditional HTTP each request-response requires the client to establish a connection with the server 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 frame sequence. The client and the server are not required to re-initiate the connection request until the client disconnects the WebSocket connection or the servers side interrupts 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.

Compared to HTTP long connections, WebSocket has the following features:

• Is the true full duplex approach, after establishing the connection client and server side is completely equal, can be unsolicited requests from each other . HTTP long connections are based on HTTP, which is the traditional mode of client-to-server requests.
• HTTP long connection, each data exchange in addition to the real data part, the server and the client also have to exchange a large number of HTTP headers, information exchange efficiency is very low. after the WebSocket protocol establishes a TCP connection through the first request, the data exchanged does not need to send an HTTP header to Exchange data . This obviously differs from the original HTTP protocol, so it needs to be upgraded to both the server and the client (HTML5 is supported by mainstream browsers). In addition, there are multiplexing, different URLs can be reused the same WebSocket connection and other functions. These are the HTTP long connections that cannot be done.

The following is a comparison between the websocket communication and the traditional HTTP by the client-server interaction message:

At the client, new WebSocket instantiates a WebSocket client object, requests a similar ws://yourdomain:port/path server-side WebSocket URL, the client WebSocket object is automatically parsed and recognized as a websocket request, and connects to the server port, The client sends a data format similar to the two sides handshake process:

get/webfin/websocket/http/1.1Host:localhostUpgrade:websocketConnection:UpgradeSec- websocket-key:xqbt3imnzjbyqrinxeflkg==origin:http://localhost:8080

As you can see, the client-initiated WebSocket connection message is similar to the traditional HTTP message,

　　 Upgrade：websocket The parameter value indicates that this is a WebSocket type request ,

　　Sec-WebSocket-Keyis a coded cipher sent by the WebSocket client that base64 requires the server to return a corresponding 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:

http/1.1101  switching ProtocolsUpgrade:websocketConnection:UpgradeSec- websocket-accept:k7djldlooiwig/mopvwfb3y3fe8=

　　Sec-WebSocket-AcceptValue is returned to the client after the server is computed with a client-consistent key.

　　HTTP/1.1 101 Switching ProtocolsIndicates that the server accepts a client connection to the WebSocket protocol,

After such request-response processing, the WebSocket connection handshake on both ends succeeds, and subsequent TCP communication can be made.

Users can consult the WebSocket protocol stack for a more detailed interactive data format between the WebSocket client and the server.

On the development side, the WebSocket API is simple: simply instantiate the WebSocket, create the connection, and the server and the client can send and respond to each other. Detailed WebSocket API and code implementations can be found in the WebSocket implementation and Case Analysis section.

I know there is an explanation, it's good to say: https://www.zhihu.com/question/20215561

WebSocket principle Analysis