Deep WebSocket Communication Protocol details

The traditional "long polling" to realize the Web-side instant communication problem
Before the advent of WebSocket, the web side was using AJAX polling (polling) in order to enable Instant messaging. Polling is at a specific time interval (such as every 1 seconds), the browser sends an HTTP request to the server, and the server returns the latest data to the client's browser. This traditional HTTP request pattern has obvious drawbacks – the browser needs to constantly make requests to the server, but the header of the HTTP request is very long, and the data contained in it may be a small value, which consumes a lot of bandwidth.

Compared to the new technology to do polling is comet, but although this technology can reach full-duplex communication, still need to make a request.
WebSocket Technology Overview
In the WebSocket API, browsers and servers only need to do a handshake, and then a fast channel is formed between the browser and the server. Between the two directly can transfer data to each other, changed the original B/S mode.

Typical architectures for WebSocket technology applications:


The technical principle of websocket:

The requests initiated by WebSocket on the browser side are generally:

Javacsript
  var ws = new WebSocket ("ws://127.0.0.1:4000");
  Ws.onopen = function () {
    Console.log ("succeed");
  };
  Ws.onerror = function () {
    console.log ("error");
  };
  Ws.onmessage = function (e) {
  console.log (e); 
  }

When a WebSocket object is new, a GET request is sent to the server:  

This request is sent to the port of the touch server, in general, the server will pre-bind a socket to a port, the client kimono The server side communicates on this predetermined port (I'm bound to port 4000, by default, Websocke uses 80 ports).

Then, after the server-side socket is heard this packet, a new socket is generated, parsing the Sec-websocket-key in the sent data, and then following the "Sec-websocket-ke" Add a magic string "258eafa5-e914-47da-95ca-c5ab0dc85b11". Use SHA-1 encryption, then BASE-64 encode the result as the "sec-websocket-accept" header value, returned to the client. After the

client receives this, the communication protocol is upgrade to the WebSocket protocol:
 

Then it will communicate under this persistent channel, including browser queries, server push, and both sides in a full-duplex form Communication with each other in the state.
WebSocket Communication Protocol
As in the example above: The format of the data transfer frame in the Switched WebSocket protocol (no longer using the HTML protocol at this time) description of the Official document:
 
directly see this, who will have a nod big: I spent a picture to simply explain the structure of this frame:
 

Explanation of the fields:

1 2 3 4 5 6 7

FIN 1bit represents the last frame of information, flag, which is the marker RSV 1-3 1bit each after the default is 0 Opcode 4bit frame type, Mask 1bit mask, whether the data is encrypted, the default must be set to 1 Payload len 7bit data length, when this 7 bit of data = = 126, the subsequent 2 bytes is also the data length, when it = = 127, the following 8 bytes represents the length of the data Masking-key 1 or 4 bit mask Payload data playload len bytes

So our code here, by judging the value of Playload Len, uses substr to intercept Masking-key and Playloaddata.

The methods for parsing data based on masks are: