From HTTP Polling to Real‑Time Push: Why WebSocket Is the Game‑Changer

When we browse a typical e‑commerce site, clicking a product list triggers a single HTTP request and the server returns a response with the product details. In this request‑response model the server never initiates communication, similar to a girl who never contacts you first.

In a web game, however, the server can continuously push monster movement and attack data to the client even when the player does not click anything, creating a seamless experience.

Using HTTP Continuous Polling

The simplest way to receive server‑initiated messages is for the front‑end to repeatedly send HTTP requests at short intervals (e.g., every 1–2 seconds). The server replies with any new data, which mimics a “pseudo‑push” mechanism. This approach is common in QR‑code login scenarios, where the front‑end polls the back‑end to check whether the user has scanned the code.

Drawbacks of continuous polling include excessive bandwidth consumption, increased load on downstream servers, and noticeable latency (1–2 s) when the next poll coincides with the user action.

Long Polling

Long polling extends the request timeout (e.g., to 30 s). If the server receives a relevant event within that window, it immediately returns a response; otherwise, the client re‑issues another request. This reduces the number of HTTP requests and provides faster feedback for actions such as QR‑code login.

Long polling is used by services like a certain cloud drive to achieve near‑instant page redirection after scanning a QR code.

What Is WebSocket?

TCP connections are inherently full‑duplex, allowing both ends to send data at any time. HTTP 1.1, built on TCP, operates in a half‑duplex manner: only the client initiates a request and the server replies. Because HTTP was designed for simple page retrieval, it does not suit scenarios where the server must push frequent updates, such as online games.

Therefore a new application‑layer protocol—WebSocket—was created to provide true full‑duplex communication over TCP.

How to Establish a WebSocket Connection

After the TCP three‑way handshake, the browser sends an HTTP request containing special headers to upgrade the protocol:

Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: T2a6wZlAwhgQNqruZ2YUyg==

The server, if it supports WebSocket, responds with a 101 Switching Protocols status and includes a Sec-WebSocket-Accept header generated from the client’s key using a public algorithm:

HTTP/1.1 101 Switching Protocols
Sec-WebSocket-Accept: iBJKv/ALIW2DobfoA4dmr3JHBCY=
Upgrade: websocket
Connection: Upgrade

Both sides then communicate using the WebSocket data format.

WebSocket Packet Capture

Tools like Wireshark show the first HTTP request with the upgrade headers (e.g., line 2445) and the server’s 101 response (e.g., line 4714). After the handshake, subsequent frames are pure WebSocket traffic, independent of HTTP.

WebSocket Message Format

WebSocket frames consist of a header and payload data. Important fields include:

opcode : indicates the frame type (1 = text, 2 = binary, 8 = connection close).

payload length : specifies the size of the payload. Values 0–125 are encoded directly; 126 indicates that the next 16 bits contain the length; 127 indicates that the next 64 bits contain the length.

payload data : the actual transmitted bytes.

The header always begins with a 7‑bit field that determines whether additional 16‑bit or 64‑bit length bytes follow.

WebSocket Use Cases

Because WebSocket retains TCP’s full‑duplex capability and solves the “sticky packet” problem with explicit length fields, it is ideal for scenarios requiring frequent bidirectional interaction, such as web/mini‑program games, chat rooms, and collaborative tools like Feishu.

Summary

TCP is full‑duplex, but HTTP 1.1 is half‑duplex, making server‑push inefficient for many real‑time scenarios.

For simple cases (e.g., QR‑code login), timed polling or long polling can simulate push.

For complex, high‑frequency interactions (e.g., web games), WebSocket provides a proper full‑duplex solution.

WebSocket’s name is unrelated to traditional sockets; it merely reuses the “socket” metaphor.

WebSocket upgrades via HTTP headers once, then operates independently of HTTP.