WebSocket Protocol Overview

WebSocket is a protocol that enables full-duplex communication over a single TCP connection, allowing real-time data transmission between the client and the server. While based on HTTP protocols, WebSocket supports bidirectional communication, enabling both clients and servers to send data independently; in contrast, traditional HTTP only supports unidirectional communication where the client sends requests and the server responds with replies.

The primary advantage of the WebSocket protocol is its ability to facilitate real-time interaction without requiring continuous request polling from the client to fetch updated data, as seen with conventional HTTP protocols. This makes WebSocket highly valuable for real-time applications such as online gaming, chat applications, and stock trading platforms.

WebSocket operates on top of the HTTP protocol, utilizing the HTTP handshake process to establish connections. During this phase, the client sends an HTTP request to the server requesting a protocol upgrade to WebSocket. If the server supports WebSocket, it responds with an HTTP 101 status code indicating successful upgrading; subsequently, the client and server can commence WebSocket communication.

WebSocket employs a fixed frame structure for data transmission. Each frame contains information such as identifier type of data, payload length, masking flag, and payload data itself. Masking is used to encrypt data, ensuring security during network transmission.

Lifecycle

The lifecycle of the WebSocket protocol primarily consists of four phases: Handshake, Connection, Data Transfer, and Close.

  1. Handshake Phase: During this phase, the client establishes a WebSocket connection by sending an HTTP request to the server. The request includes an Upgrade header field indicating that the client wishes to upgrade to the WebSocket protocol. If the server agrees to the upgrade, it returns an HTTP 101 status code and includes Upgrade and Connection headers in its response, signifying a successful upgrade. At this point, the WebSocket connection is established successfully, allowing data transmission between the client and server.
  2. Connection Phase: In this phase, data transfer occurs over the established WebSocket connection between the client and server. Both parties can send bidirectional data of various types, including text, binary, ping, and pong messages. The WebSocket connection is full-duplex, meaning both the client and server can simultaneously transmit and receive data. This phase persists until a decision is made to close the connection.
  3. Data Transfer Phase: During this phase, arbitrary types of data can be transmitted between the client and server via the WebSocket connection. Both parties may send and receive real-time or historical data at any time. This phase continues for an extended period until it becomes necessary to terminate the connection.
  4. Close Phase: In the close phase, either the client or server can shut down the WebSocket connection by sending a Close frame. The Close frame contains a specific Opcode and a Close Code indicating the reason for disconnection. Upon receiving this Close frame, the other party sends a corresponding Close Response frame to confirm that the connection has been successfully closed. At this stage, the WebSocket connection is terminated, marking the end of its lifecycle.

Frame Structure

WebSocket utilizes a fixed frame structure for data transmission. Each frame comprises several components:

  1. FIN (1 bit): Indicates whether the current frame represents the final fragment of a message; set to 1 if it is the last one, otherwise 0.
  2. RSV1, RSV2, RSV3 (each 1 bit): Reserved bits currently unused and must be set to 0.
  3. Opcode (4 bits): Specifies the type of data contained in the frame, including text, binary, close connection control frames, ping, and pong messages.
  4. Mask (1 bit): Indicates whether masking is applied to the payload; client-to-server data must be masked, while server-to-client data does not require masking.
  5. Payload length (7 bits or 7+16 bits or 7+64 bits): Specifies the size of the payload. If the length is less than 126, only the lower 7 bits are used; if it equals or exceeds 126 but does not exceed 65535, an additional 16-bit field follows (totaling 23 bits); if greater than 65535, a further 64-bit extension is added.
  6. Masking key (32 bits): If the Mask bit is set to 1, this field contains a four-byte masking key used to mask the payload data before transmission.
  7. Payload data: The actual message content whose length corresponds to the value indicated by Payload Length; if Mask is 1, decoding requires applying the masking key derived from the Masking Key field.