Introduction to the

  • WebSocket is a network transport protocol that enables full-duplex communication over a single TCP connection and is located at the application layer of the OSI model. The WebSocket protocol supports the interaction between the Web browser (or other client applications) and the Web server. It has low overhead and facilitates real-time data transmission between the client and the server. The server can do this in a standardized way, without requiring the client to request the content in the first place, and allowing messages to be passed back and forth while keeping the connection open. In this way, you can have a two-way continuous conversation between the client and the server. By default, Websocket uses port 80. When running over TLS, port 443 is used by default.

  • WebSocket makes it easier to exchange data between the client and the server, allowing the server to actively push data to the client. In the WebSocket API, the browser and server only need to complete a handshake to create a persistent connection and two-way data transfer between the two. The Websocket must use HTTP to hold a handshake. After the handshake is successful, data is directly transferred through the TCP channel, regardless of HTTP.

  • Websocket transmits data in the form of frames. For example, a message is divided into several frames and transmitted in sequence. This has several benefits:

    • 1. The transmission of big data can be fragmented, without considering the insufficient length marker bits caused by the data size.
    • 2. Like HTTP chunk, data can be generated and messages can be transmitted at the same time, which improves transmission efficiency.

advantages

  • Less control overhead. When data is exchanged between the server and client after the connection is created, the packet headers used for protocol control are relatively small. Without extensions, this header size is only 2 to 10 bytes (depending on packet length) for server-to-client content; For client-to-server content, an additional 4-byte mask is required for this header. This overhead is significantly reduced compared to HTTP requests that carry the full header each time.
  • More real-time. Because the protocol is full-duplex, the server can proactively send data to the client at any time. Compared with HTTP requests that need to wait for the client to initiate the request before the server can respond, the latency is significantly less; Even compared to long polling like Comet, data can be delivered more times in a shorter time.
  • Keep the connection state. Unlike HTTP, Websocket needs to create a connection first, which makes it a stateful protocol that can then communicate without some state information. HTTP requests, on the other hand, may need to carry status information (such as authentication) with each request.
  • Better binary support. Websocket defines binary frames, making it easier to process binary content than HTTP.
  • Extensions can be supported. Websocket defines extensions that users can extend and implement partially customized sub-protocols. For example, some browsers support compression.
  • Better compression. Compared to HTTP compression, Websocket, with appropriate extension support, can use the context of the previous content, which can significantly improve compression when passing similar data

Usage scenarios

Social chat, live barrage, multi-player games, collaborative editing, real-time stock fund quotes, sports updates, video conferencing/chat, location-based applications, online education, smart home and other scenarios requiring high real-time

Shake hands

Websockets are standalone protocols created on top of TCP.

Websocket uses the 101 status code of the HTTP/1.1 protocol for handshake.

example

Client request

GET/HTTP/1.1 Upgrade: websocket Connection: Upgrade Host: example.com Origin: http://example.com sec-websocket-key: sN9cRrP/n9NdMgdcy2VJFQ== Sec-WebSocket-Version: 13Copy the code

Server response

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: fFBooB7FAkLlXgRSz0BT3v4hq5s=
Sec-WebSocket-Location: ws://example.com/
Copy the code
  • Connection must be set to Upgrade, indicating that the client wants to connect to the Upgrade.
  • The Upgrade field must be set to Websocket, indicating that you want to Upgrade to the Websocket protocol.
  • Sec-websocket-key is a random string that the server uses to construct a summary of sha-1 information. Add “sec-websocket-key” to the special string “258eAFa5-E914-47DA-95CA-C5AB0DC85B11”, calculate the SHA-1 digest, and then BASE 64 encoding, Returns the result as the value of the sec-websocket-accept header to the client. In this way, ordinary HTTP requests are avoided from being mistaken for Websocket protocols.
  • Sec-websocket-version Indicates the supported WebSocket Version. RFC6455 requires version 13 to be used, and previous drafts should be deprecated.
  • The Origin field is optional and is usually used to indicate the page from which the Websocket connection was initiated in the browser, similar to Referer. However, unlike Referer, Origin contains only the protocol and host name.
  • Other fields defined in HTTP, such as cookies, can also be used in Websockets.

WebSocket connection process

In WebSocket, the server and browser only need to shake hands through HTTP protocol, and then establish a SEPARATE TCP communication channel for data transmission.

  • First, the client initiates an HTTP request and establishes a TCP connection after three handshakes. The HTTP request stores information about the Version supported by WebSocket, such as Upgrade, Connection, and websocket-version.
  • After receiving the handshake request from the client, the server also uses HTTP protocol to send back data.
  • Finally, after receiving the message that the connection is successful, the client starts to use the TCP transport channel for full-duplex communication.

What does WebSocket solve?

  • 1. Passive questions

    • For traditional request-response patterns, such as Ajax polling, long polling
      • Ajax polling works by having the browser send a request every few seconds asking if the server has new information.
      • Long Poll principle: Polling is also adopted, but the blocking model is adopted, that is, after the client initiates a connection, if there is no message, no Response will be returned to the client. It does not return until there is a message, after which the client establishes the connection again and the cycle starts again.
    • As can be seen from the above two methods, HTTP connections are constantly established and then processed by the server. The server cannot actively contact the client, only the client initiates the connection. This is very resource-intensive. Ajax polling requires fast processing speed and resources on the server. (Speed) Long poll requires high concurrency, that is, the ability to receive customers at the same time. (Site size)
    • For WebSocket, when the server completes the protocol upgrade (HTTP -> WebSocket), the server can actively push information to the client.

  • 3. Resource consumption

    • The program used is to go through two layers of proxy, that is, HTTP protocol in Nginx server parsing, and then transmitted to the corresponding Handler (JAVA, PHP, etc.) to process. Servers like Nginx are fast enough to process requests, but the Handler can’t process them fast enough to get stuck with the Handler.
    • For WebSocket, it can directly establish persistent connection with Nginx and other servers. When there is information, the Handler will find a way to notify the server, and then the server in the unified forward to the client. This will solve the problem of slow Handler processing.

  • 4. Efficiency

    • In the traditional way, HTTP is constantly set up and turned off. Since HTTP is stateless, each time you retransmit identity Info to tell the server who you are. This leads to a loss of efficiency and consumes too much traffic/time in network traffic.
    • For WebSocket, only one HTTP handshake is required, so the entire communication process is set up in one connection/state, thus avoiding HTTP statelessness. The server will know your information until you close the request, thus eliminating the need for the operator to repeatedly parse the HTTP protocol. Also check identity Info for information.

WebSocket vs. HTTP

  • The same
    • Both are application layer protocols based on TCP.
    • Request/Response model is used to establish the connection.
    • Errors are handled the same way during connection establishment, and WS may return the same return code as HTTP at this stage.
    • Can transfer data over the network.
  • The difference between
    • WebSocket uses HTTP to establish connections, but defines a new set of header fields that are not used in HTTP.
    • A WebSocket connection cannot be forwarded through a middleman; it must be a direct connection.
    • Websockets require a handshake between the browser and the server to establish a connection. HTTP is a connection initiated by the browser to the server that the server does not know about in advance.
    • After the WebSocket connection is established, both parties can send data to the other party at any time.
    • After the WebSocket connection is established, data is transferred using frames instead of Request messages. WebSocket data frames are in order. HTTP, on the “flow” level, is an ordered sequence of “frames”, while on the “connection” level, messages are out-of-order “frames”.

WebSocket case analysis

  • Case introduced
    • The customer is A mobile device manufacturer. The mobile device is loaded with Android/IOS operating system. The devices are divided into two categories (hereinafter referred to as category A and CATEGORY B). Customers need to view the location and status information of class A devices in Class B devices at any time. For example, when A Class A device goes online or offline, A Class B device needs to receive A notification immediately. When A Class A device reports A report, A Class B device also needs to obtain the geographical location information of the reported Class A device in real time.
    • In order to reduce the difficulty and workload of cross-platform implementation, the customer considers lightweight Web App to shield the differences between Android and IOS platforms. There are A large number of Category A devices, and they are in the state of irregular movement in working state. However, Class B devices have high requirements on the real-time perception of state changes of Class A devices (second level).
    • According to the above requirements, the information of class A/B devices is stored in the background database. The interaction of Class A/B devices involves frequent and highly concurrent requests from Web clients/servers. Accordingly, if the traditional HTTP request-response mode is used, the Web App of Class B devices needs to poll services. In addition, when category A devices do not go online or report active events, polling of Category B devices wastes network resources.
  • The solution
    • To sum up, the project adopts WebSocket technology to realize real-time message notification and push. Whenever class A devices/Class B devices login successfully, the HTTP long connection of WebSocket will be opened, and new class A devices come online and their positions change. The WebSocket Server processes the real-time messages of class A devices and pushes them to the subordinate class B devices in real time.