WebSocket principle, why can we achieve persistent connection?

WebSocket is a new protocol for HTML5. it realizes the browser and the server full-duplex communication , 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 HTTP the 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.

WebSocket is a protocol for full-duplex communication on a single TCP connection, in the WebSocket protocol, the client and the server only need to do a handshake action, you can form a channel, the two can be transmitted between the data.

So the WebSocket protocol is divided into two parts:

1. Shake hands
2. Data transmission

Shake hands

The client sends a request

get/http/1.1upgrade:websocketconnection:upgradehost:example.comorigin:nullsec-websocket-key:sn9crrp/ N9ndmgdcy2vjfq==sec-websocket-version:13

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, and "Sec-websocket-key" is WebSocket A base64 encoded ciphertext sent by the client 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.1 101 Switching protocolsupgrade:websocketconnection:upgradesec-websocket-accept: ffboob7fakllxgrsz0bt3v4hq5s=sec-websocket-origin:nullsec-websocket-location:ws://example.com/

After receiving this response, the client needs to compare the Sec-websocket-accept value, which indicates that the server agreed to the handshake to establish the connection, which is transmitted by the client Sec-websocket-key. 258eafa5-e914-47da-95ca-c5ab0dc85b11 "After stitching, with SHA-1 encryption, and BASE-64 encoded.

After the client receives the sec-websocket-accept, the local sec-websocket-key is encoded the same and then compared.

It takes only a single HTTP request to deliver a steady stream of information. (in programming, this design is called a callback, that is: you have the information to notify me again, and not my stupid every time to ask you)
Such a protocol solves the situation where there is a delay in synchronization and is very resource intensive.

In the traditional way, to constantly build, close the HTTP protocol, because HTTP is non-stateful, each time to re-transmitting identity info (authentication information)To tell the server who you are.
ButWebSocket only need an HTTP handshake, so that the entire communication process is established in a connection/state , also avoids the non-state of HTTP, the server will always know your information until you close the request,This solves the need for the operator to parse the HTTP protocol over and over again, and to see the identity info. Another feature of the HTTP protocol,The passive nature.
What is passive, in fact, the server can not actively contact the client, can only be initiated by the client.
At the same time by Customer Unsolicited Inquiry, converted to the server (push) when there is information to send (of course, the client is still waiting to send the message over. ), when no information is given to the operator (Nginx), do not need to occupy their own speed is slow Customer Service (Handler)The
--------------------
As for how to use WebSocket on clients that do not support websocket. The answer is: can't
But you can do this by saying long poll and Ajax polling. simulate a similar effect
-----

WebSocket principle, why can we achieve persistent connection?