Open a live sports score, a chat app, a collaborative document where you can see other people's cursors moving, or a trading dashboard where prices tick in real time. In every case, the server has news and needs to get it to your screen the instant it happens. But the web was not built for that. HTTP, the protocol the whole web runs on, is request/response: the client asks a question, the server answers, and then the conversation is over. The server has no way to speak up on its own. It cannot push.

So how did the web learn to feel alive? The answer is a thirty-year arc of increasingly clever workarounds and, finally, a protocol built for the job: the WebSocket, a persistent, full-duplex, bidirectional channel that begins its life as an ordinary HTTP request and then transforms into a raw two-way pipe. This page walks that whole evolution — polling, long-polling, Server-Sent Events, and WebSockets — so you understand not just how real-time works but why each rung of the ladder exists.

The fundamental mismatch

HTTP's request/response shape is a wonderful fit for fetching pages: you ask for a URL, you get a document, done. Each exchange is independent and the connection can be closed and forgotten. But that same shape is exactly wrong for real-time updates, because the interesting event — "a new message arrived", "the price moved", "your teammate typed" — originates at the server, at a moment the client cannot predict. In pure HTTP, the client would have to somehow guess when to ask. The whole history of real-time web is a series of answers to one question:

how does the server get data to the client without the client having asked for that specific thing right now?

There are only two fundamental strategies, and everything else is a refinement of them:

• The client keeps asking ("are we there yet?") — polling and its smarter sibling long-polling. Works over plain HTTP; wastes effort or ties up requests.
• The client opens a channel the server can speak down whenever it likes — Server-Sent Events (one-way) and WebSockets (two-way). Needs a persistent connection; far more efficient for chatty, live data.

Climbing the ladder

Each technique fixes the flaw of the one before it. It is genuinely a ladder, and knowing the rungs is how you choose the right tool.

• Short polling. The client asks "anything new?" on a timer — every few seconds, forever. Simple and works everywhere, but it is a firehose of mostly-empty requests: if you poll every 3 seconds but news arrives once an hour, you have sent ~1,200 pointless round-trips (each with full HTTP headers) for one useful answer. And you still have up to 3 seconds of latency before you see the news.
• Long polling. The clever twist: the client asks "anything new?" and the server holds the request open, not answering until it actually has something (or a timeout fires). The moment news arrives, the server responds, the client immediately re-asks, and the cycle repeats. This cuts the waste and the latency dramatically — but it ties up a request/connection per client the whole time, and every message still pays a full round-trip of HTTP overhead.
• Server-Sent Events (SSE). A standard, elegant, one-way stream: the client opens a single HTTP connection with Accept: text/event-stream, and the server keeps it open and writes a sequence of text events down it over time, server → client. Built into browsers as EventSource, with automatic reconnection. Perfect for feeds — notifications, live scores, a status ticker — but the client cannot send anything back on the same channel.
• WebSockets. The full solution: a single, persistent, full-duplex connection over which both sides can send messages at any time, with tiny per-message overhead. This is the tool for anything genuinely interactive — chat, multiplayer games, collaborative editing.

How a WebSocket is born: the HTTP Upgrade handshake

The clever part of WebSockets is how they start. A WebSocket does not bypass the web — it begins as a perfectly ordinary HTTP GET that politely asks to be upgraded. The client sends headers like these:

If the server agrees, it replies with a special status code — 101 Switching Protocols — and from that instant the same TCP connection stops speaking HTTP and becomes a raw WebSocket channel:

This is why WebSockets work through the existing web infrastructure — they ride ports 80/443 and start as HTTP, so firewalls and proxies let them through — yet escape HTTP's request/response straitjacket once upgraded. The handshake is the bridge from the old world to the new.

After the handshake: frames and opcodes

Once upgraded, the two sides no longer send HTTP requests — they exchange frames. A WebSocket frame is a lightweight envelope: a few bytes of header (an opcode saying what kind of frame it is, a length, and — from client to server — a masking key) wrapped around the payload. That is the source of the efficiency: where each long-poll message dragged a fat block of HTTP headers along, a WebSocket message adds only a handful of framing bytes.

The opcode tells the receiver how to treat the frame. The important ones:

The ping/pong pair matters more than it looks: a persistent connection that goes quiet is indistinguishable, to the network, from a dead one. Intermediaries (proxies, NAT boxes, load balancers) happily drop idle TCP connections after a minute or two. So both ends periodically ping and expect a pong; a missing pong means the peer is gone and the connection should be torn down and re-established. Keeping the pipe alive is your job, not magic.

Count the cost yourself

Why does everyone reach for persistent connections? Overhead. The demo below simulates a 60-second window in which the server has 3 real pieces of news to deliver, and counts the network round-trips and the bytes of overhead each strategy spends to deliver them. The numbers make the case better than prose.

Short polling burns a huge, fixed cost whether or not anything happens; long polling scales with the message count but pays full HTTP headers each time; the WebSocket pays one handshake and then almost nothing per message — and the client can talk back on the same connection. For a chatty, interactive workload the persistent connection wins by a mile.

Choosing — and the newest rungs

More power is not always the right answer; each tool fits a shape of problem.

SSE and WebSockets cover the vast majority of real-time web today. WebRTC is the choice when the payload is live audio/video and you want peers talking (nearly) directly to each other. WebTransport over QUIC is the emerging successor for cases where a single WebSocket's strict in-order TCP stream causes head-of-line blocking — QUIC's independent streams over UDP dodge it.