Why HTTP Polling Falls Short and How WebSocket Enables Real‑Time Server Push

Using HTTP Continuous Polling

The simplest way to receive server messages without user interaction is to let the front‑end repeatedly send HTTP requests; the server replies with data each time. This "pseudo‑push" works for scenarios like QR‑code login, where the client polls the server every 1–2 seconds.

Frequent requests increase bandwidth usage and can cause noticeable latency when the next poll happens after the user scans the code.

When many clients poll simultaneously, the downstream server load grows significantly.

Long Polling

Long polling extends the request timeout (e.g., to 30 seconds). The server holds the request open and returns a response as soon as an event occurs; otherwise it times out and the client immediately sends a new request. This reduces request volume and improves responsiveness for actions like QR‑code login.

Long polling is essentially a "server push" mechanism, similar to the comet technique used in message queues such as RocketMQ.

What Is WebSocket?

TCP is full‑duplex, but HTTP/1.1, built on TCP, operates in a half‑duplex manner: the client must always initiate communication. For scenarios requiring frequent bidirectional data exchange (e.g., web games), a new protocol—WebSocket—was created to provide true full‑duplex communication over a single TCP connection.

How to Establish a WebSocket Connection

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

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

The server, if it supports WebSocket, responds with status 101 and a calculated Sec-WebSocket-Accept value:

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

Both sides then switch to the WebSocket data format for subsequent communication.

WebSocket Packet Capture

Using tools like Wireshark, you can see the first HTTP request containing the upgrade headers (line 2445) and the server's 101 response (line 4714). After the handshake, all traffic follows the WebSocket framing protocol.

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 = close).

payload length : encoded in 7 bits, 7 + 16 bits, or 7 + 64 bits depending on size.

payload data : the actual bytes being transmitted.

The initial 7 bits always tell the receiver whether additional length bytes (16 bit or 64 bit) follow.

WebSocket Use Cases

Because WebSocket preserves TCP's full‑duplex nature and solves the packet‑sticking problem, it is ideal for scenarios requiring frequent client‑server interaction, such as web/mini‑program games, chat rooms, and collaborative tools like Feishu.

In a web game, monster movements and attack data are generated by the server and pushed to the client via WebSocket, allowing real‑time updates without user actions.

Summary

TCP is full‑duplex, but HTTP/1.1 is half‑duplex; for server‑initiated pushes, use WebSocket.

Simple scenarios (e.g., QR‑code login) can use periodic or long polling, but they still rely on client‑initiated requests.

Complex, high‑frequency interactions (e.g., web games) benefit from WebSocket’s true bidirectional communication.

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

The protocol’s frame structure (header + payload) mirrors many other protocols that need explicit message boundaries.