HTTP and WebSocket

The most important feature of using WebSocket to connect to a server is the feature of persistent links.

Common points are: all are based on the TCP protocol Client-server link, WebSocket is HTML5 proposed a set of gaps in the HTTP link is not persistent link features (except long connection, long polling)

Polling (AJAX): Refers to the browser-side timed to send the request to the server side, the server received a request to respond and close the link to connect.
(Disadvantage: Need to think more about timing, how often to poll, etc.)

Long polling: Similar to polling principle, but there is an important feature is that after the browser sends the request, the server is to keep the link (the main method is the dead loop execution, timed sleep timeout after disconnecting), before the scheduled break link, get the latest data and return to the browser, A new request is re-initiated by the browser.
(The disadvantage is that many HTTP requests are initiated concurrently.) ）

The common disadvantage of polling and long polling is that you need to waste a lot of HTTP resources and a large number of requests.

Long connection: Similar to the cross-domain request in the front-end, using the cross-domain feature of the src of the IFrame, hiding an iframe in the page to obtain the background data, feedback to the IFRAME, to achieve the background data acquisition.
The disadvantage of long links is also that the request server must be timed to update the data resource.

The previous question was:
In the process of connection, the server will not stop the link and disconnect, the data header information repeatedly sent, waste of broadband, information exchange inefficient.

The "long connection" between them is a "pseudo-long connection", and it is only by the server that it is constantly looping to achieve the so-called long connection effect.

WebSocket solved the problem:
The real push is to push the server actively, as long as there is data to push to the requester. (Become passive to be active)

WebSocket accepts messages in the form of asynchronous callbacks, and when a communication connection is established, a persistent connection can be made and communication is done.

(rather than having to make a timed request to the server to get the latest update information, as in the above several ways, it seems quite passive)

After the WebSocket has created an HTTP request request and created a TCP link through its own WS-protocol (which differs from the HTTP protocol here), the subsequent data exchange does not need to create a link again to achieve a true long connection.

The WebSocket protocol is essentially a TCP-based protocol. A handshake is required to establish a connection, and the client (browser) initiates a special HTTP request to the server (Web server), which generates an answer to the browser after parsing the Web server, so that a websocket connection is established until a party closes the connection.

Of course a socket.io based on node. JS is an open source implementation WebSocket Library, which through node. JS implements the server side, but also provides the client JS Library, Socket.io support event triggering as the basis for bidirectional data communication.

See more information about Socket.io go to: http://socket.io/

HTTP and WebSocket