Why Can’t Servers Push Data? Exploring HTTP Polling, Long Polling, and WebSocket

Using HTTP Polling

When a user clicks a product list on a shopping site, the browser sends an HTTP request and the server returns a response; this request‑response model works for most web pages but the server never initiates a message on its own.

To make a page receive updates without user interaction, developers often let the front‑end repeatedly send timed HTTP requests. The server replies with data, creating a "pseudo‑push" effect. This technique is commonly used for QR‑code login, where the front‑end polls the back‑end every 1–2 seconds to check whether the code has been scanned.

Problems with constant polling include excessive bandwidth consumption and noticeable latency (the user may wait 1–2 seconds after scanning before the next poll triggers a page jump).

Many small HTTP requests fill the network and increase server load.

If the next poll occurs after the user has already scanned, the UI experiences a noticeable lag.

Long Polling

Long polling extends the request timeout (e.g., to 30 seconds). The client sends a request and the server holds it open until an event occurs (such as a QR‑code scan). If the event happens, the server immediately responds; otherwise, after the timeout the client sends a new request.

This reduces the number of requests and provides near‑instant feedback for scenarios like QR‑code login.

Long polling is essentially a "long‑hold" mechanism, similar to the way message queues such as RocketMQ let consumers wait for data.

What Is WebSocket?

TCP is full‑duplex, allowing both ends to send data at any time. HTTP 1.1, built on TCP, is half‑duplex: only the client initiates a request and the server replies.

Because HTTP was designed for static page retrieval, it does not support server‑initiated pushes needed by real‑time applications like web games.

WebSocket is a new application‑layer protocol that upgrades an HTTP connection to a full‑duplex channel, enabling the server to push data whenever needed.

How to Establish a WebSocket Connection

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

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

HTTP status 200 is a normal response; 101 indicates a protocol switch.

Both client and server then use the WebSocket frame format for communication.

WebSocket Frame Format

Each WebSocket message (frame) consists of a header and payload data. Important fields include:

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

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

payload data : the actual bytes to transmit.

If the first 7 bits are 0–125, they directly represent the payload length. A value of 126 (0x7E) means the next 16 bits contain the length (126–65535). A value of 127 (0x7F) means the following 64 bits hold the length (≥ 65536).

Typical Use Cases for WebSocket

WebSocket inherits TCP’s full‑duplex capability and solves the “sticky‑packet” problem by framing messages with length headers. It is ideal for scenarios requiring frequent bi‑directional interaction, such as browser games, chat rooms, and collaborative web applications.

In a web‑game, monster movements and attacks are generated by server logic and must be pushed to the client in real time; WebSocket enables this server‑to‑client push without the client polling.

Summary

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

For simple scenarios like QR‑code login, periodic polling or long polling can simulate push (comet) effects.

Complex, real‑time interactions (e.g., web games) should use WebSocket.

WebSocket is unrelated to traditional socket programming despite the similar name.

After the initial HTTP upgrade handshake, WebSocket communication no longer depends on HTTP.