What WebSocket can do

This article introduces is WebSocket, but does not introduce its protocol format, generally can see the HTTP header can also understand WebSocket before the protocol switch negotiation, can see the IP header also on the WebSocket after the protocol switch communication format is not unfamiliar.
WebSocket provides a transport service for the message packet over the reliable transmission of TCP, that is, the application layer call WebSocket at one end of the websocket sends a message of the specified size, and the websocket at the other end submits the same size message to the protocol process. As for the format of the message customer customization.
This article will be concatenated through the HTTP protocol documentation to understand what WebSocket is trying to solve.
If you need to reference Libwebsocket in the win platform example, you can refer to the previous "win platform compiled with Libev and Libuv Libwebsocket".
The protocol documentation for this reference is
RFC 1945 "Hypertext Transfer Protocol-http/1.0" May 1996
1.3 Overall operation
7.2.2 Length
8. Method Definitions
RFC 2068 "Hypertext Transfer Protocol-http/1.1" January 1997
RFC 2616 "Hypertext Transfer Protocol-http/1.1" June 1999
8.1 Persistent Connections
10.1.2 101 Switching protocols
14.10 Connection
19.7.1 compatibility with http/1.0 persistent Connections
RFC 2817 "Upgrading to TLS within http/1.1" May 2000
3. Client requested Upgrade to HTTP over TLS

It can be seen that the http/1.0 protocol has been developed for more than 30 years.

First, let's look at the http/1.0 protocol document

1.3 Overall operation [Page 5-6] The HTTP protocol is based on a request/response paradigm. A client establishes a connection with a server and sends a request to the server in the form of a request method, U RI, and protocol version, followed by a mime-like message containing request modifiers, client information, and poss Ible body content. The server responds with a status line, including the message ' s protocol version and a success or error code, follow Ed by a mime-like message containing server information, entity metainformation, and possible body content.    [Page 7] On the Internet, HTTP communication generally takes place over TCP/IP connections. The default port is TCP [all], but other ports can be used. This does is preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; Any protocol this provides such guarantees can be used, and the mapping of the http/1.0 request and response structures onto the transport data units of the protocol in question was outside the S Cope of this specification.

From the operational overview, the HTTP protocol is based on the request/response (Request/response) paradigm. The client establishes a connection to the server, sends a fixed-format request, and responds to the request by the server. That is, the service side does not actively send data to the client.
The document then states that the HTTP protocol only believes in reliable transmissions, with the Internet-wide preference for TCP, the default port of 80, which is well known. So we are locked in the underlying transport protocol at TCP, and the socket we mentioned in this article is equivalent to the socket using the TCP protocol in the INET protocol cluster.
WebSocket is the web and socket, how to use the HTTP protocol communication to establish a socket connection, play a new world.

[Page 7]    Except for experimental applications, current practice requires the    connection is established by the client prior To all request and    closed by the server after sending the response. Both clients    and servers should be aware this either party could close the connection    prematurely, due to user actio N, automated time-out, or program    failure, and should handle such closing in a predictable fashion.    the closing of the connection by either or both parties always    terminates the current request, regard Less of its status.    

　　

In addition to some experimental applications, the HTTP 1.0 protocol requires the client to establish a connection for each request, and the server closes the connection after the response message has been sent. In this process, the customer service can be closed at both ends of the connection, the consequence is to abort the request (response).
Although there is already a definition and use of length in HTTP 1.0, to describe the size of the body (body), but also can not reuse (reuse) a connection, and in the absence of content-length, the service side to close the connection to flag the end of the response sent, Client to judge.
The following documents are relevant

7.2.2 length [Page] When an    Entity-body was included with a message, the Length of this Body may be    determined I n one of the ways. If a content-length header    field is present, it value in bytes represents the Length of the    entity-body. Otherwise, the body length is determined by the closing of the connection by the    server.    Closing The connection cannot is used to indicate the end of a    request body, since it leaves no possibility for the SE RVer to send back    a response. Therefore, http/1.0 requests containing an entity    body must include a valid Content-length header field. If A request    contains an entity body and content-length are not specified, and the    server does not recognize or CA Nnot calculate the length from other fields    and then the server should send a (bad request) response.

　　

What can the HTTP protocol do? HTTP defines several methods that we use most often in the Get method.

8.1 Get [Page] The    get method means retrieve whatever information (in the form of a    entity) is identified by T He request-uri. If The Request-uri refers    to a data-producing process, it's the produced data which shall be    returned as the Enti Ty    in the response and isn't the source text of the process, unless that text happens to be the output of the process.

　　

We get resources from the Internet via the HTTP protocol, specifying the destination address of the resource by URI. The target resource may not be an entity but a process (process) that gets the results it processes.

To the HTTP 1.1 protocol, add the connection field, which is used as a document

14.10 Connection the    Connection general-header field allows the sender to specify    options that is desired for tha T particular connection and must not being    communicated by proxies over further connections.    The Connection header has the following grammar:    Connection = "Connection" ":" # (Connection-token)    Connection-token = Token

The server that supports the HTTP 1.1 protocol begins to support persistent connections, which means that when a request/response is finished, the server does not close the connection. Implementations that do not support persistent connections need to be explicitly marked with "Connection:close".

8.1 Persistent Connections8.1.1 Purpose persistent HTTP connections have a number of advantages:-HTTP Requests and res　　Ponses can pipelined on a connection. Pipelining allows a client to make multiple requests without waiting for each response, allowing a single TCP connection To is used much more efficiently, with much lower elapsed time.8.1.2.1 negotiation an http/1.1 server could assume that a http/1.1 client intends to maintain a persistent connection unless a connection header including the Connection-token "C Lose "was sent in the request.  If the server chooses to close the connection immediately after sending the response, it should send a connection header Including the Connection-token close.

The purpose of the persistent connection is indicated in the document, the most prominent being that the connection can be reused for more than one request/response, and both ends can be controlled by the connection field to control the end of the persistent connection.

Imagine a page under a reference to a number of images, scripts, text and other resources, if the HTTP 1.0 protocol, it is necessary for each resource request to establish a connection, but the HTTP 1.1 protocol can be pipeline to a connection to complete the request.
Let's take a look at the Libwebsocket test Example-the simple HTTP service packet capture:

(The red box is the request, the green box is the response, the blue line is the browser Port association)
7681 is the HTTP service port, test.html refers to two images, respectively, logo.png and Favicon.ico, the entire test.html page of document reference to the resource only through a TCP connection to complete multiple HTTP requests.

Let's go ahead and look at the documentation to see what new elements are in HTTP 1.1.

10.1.2 101 Switching protocols The server understands and is willing to comply with the client's request, via the Upgrad E Message header field (section 14.42), for a change in the application protocol being used on this connection. The server would switch protocols to those defined by the response's Upgrade header field immediately after the empty Lin　　E which terminates the 101 response. The protocol should was switched only when it was advantageous to doing so. For example, switching to a newer version of HTTP was advantageous over older versions, and switching to a real-time, sync Hronous protocol might is advantageous when delivering resources is use such features.

HTTP 1.1 began to support the protocol switch, WebSocket naturally have all the supporting elements, want to also is not anything new, websocket inevitably came into being.

Let's take a look at some other protocols that have long been applied to this feature, TLS (RFC 2817 upgrading to TLS within http/1.1)

3. Client requested Upgrade to HTTP-over-TLS when the Client sends a http/1.1 request with an Upgrade header field cont Aining the token "tls/1.0", it is requesting the server to complete the current http/1.1 request after switching to TLS/1 .0.3.1 Optional Upgrade A client may offer to switch to secured operation during any clear HTTP request when an unsecure 　　D response would be acceptable:get http://example.bank.com/acct_stat.html?749394889300 http/1.1 Host:example.bank.com upgrade:tls/1.0 Connection:upgrade

Now let's go back to the document we've browsed above.
1. The HTTP protocol relies on reliable transmission, and the preferred use in an Internet environment is the TCP transport protocol.
2. The HTTP protocol is based on the Request/response paradigm, and the server does not actively send data to the client.
3. HTTP 1.0 does not support persistent connections, and a TCP connection is established every time request/response.
4. HTTP 1.1 requires support for persistent connections, the connection can be reused to complete multiple request/response, but still can not leave the request/response paradigm, but also rely on polling.
5. HTTP 1.1 starts to support protocol switching.
A variety of terminal hardware performance of the vast development of a variety of software technology, strong support for Web application development needs.

The WebSocket appeared.
The principle is to use the HTTP protocol to switch protocol, the TCP connection (everyone said it socket) from the HTTP protocol freed up for more efficient application of data communication.
The WebSocket protocol provides a message packet (frame or message) transport service that allows the consumer to define any form of application protocol. WebSocket before using the HTTP protocol switch, the client and the server must negotiate a variety of parameters, the most important is to bind to which user-defined application protocol, the HTTP server can not switch the WebSocket protocol, As well as expect the HTTP server to return 101 answer I switch good websocket protocol and say to you that XXX protocol and extension support. They use the HTTP protocol header field for interactive negotiation of parameters through a single request/response, and then switch to websocket communication.
The test examples of the Libwebsocket library demonstrate WebSocket's commitment and ability to solve problems. The server example implements the most basic simple HTTP service and some other WS-based testing services to see how an HTTP Server supports both the HTTP and WS protocols. The test examples used by test.html are all serviced by the server tester, which has basic Web services, post data, a WS-based self-increment push service, and a mirror (mirror) service similar to a chat room's message forwarding broadcast (but not a text record, But the drawing path). There are also several client-side test applications, how to use the services of the WS consuming server program, and the real-time data passing through the mirror service with the browser.

This is the end of this article, thank you for watching.

What WebSocket can do