Is anyone there? How the web learned to talk back

From polling to WebSockets: the whole story, with diagrams.

How the web went from asking "anything new?" over and over to one open, two-way connection. The tricks that came before, how a WebSocket actually works, and when you should and should not use one.

Saransh14 Oct 20269 min read

HTTP was built for documents: the browser asks, the server answers, the conversation ends. That works for pages. It does not work for a chat message, a moving bus on a map or a price that changes every second, where the server has news and the browser has not asked yet.

For about fifteen years the web worked around this with tricks. WebSockets replaced the tricks with a real two-way connection. To see why it matters, it helps to see what came before.

Before WebSockets

Every approach below tries to answer one question: how does the server tell the browser something the moment it happens?

How the web did "real-time" before WebSockets
Technique	How it works	The catch
Short polling	The browser sends a request every few seconds: anything new?	Most answers are "no". Each one costs a full HTTP request with headers, and news waits until the next poll.
Long polling (Comet)	The browser asks, and the server holds the request open until there is news or a timeout, then the browser asks again at once.	Near real-time, but every message still needs a fresh request, and servers hold many idle requests open.
HTTP streaming	The server never finishes the response and keeps writing to it (the "forever iframe" trick).	One way only, fragile through proxies and buffers, and awkward to parse.
Flash and Java sockets	A browser plugin opened a raw socket for the page.	Needed a plugin; died with Flash.
Server-Sent Events (SSE)	The browser opens an EventSource and the server streams text events down one long HTTP response.	Server to browser only, text only. The browser still sends anything back with ordinary requests.

Polling and long polling, side by side

With short polling the browser keeps asking on a timer. With long polling the server waits before it answers, so news arrives sooner, but every message still costs a whole new request.

Short polling

Long polling

Server-Sent Events: one way, built in

Server-Sent Events are part of the HTML standard. The browser opens a connection with new EventSource(url), and the server answers with the content type text/event-stream and keeps writing events to it. The browser reconnects by itself if the connection drops, and sends a Last-Event-ID header so the server can resume.

SSE is a good fit when only the server talks: notifications, a live feed, progress of a long job, or tokens streaming from an AI model. It runs over plain HTTP, so it passes through most proxies. What it cannot do is let the browser talk back on the same connection.

Server-Sent Events

What a WebSocket is

A WebSocket is one long-lived connection between the browser and the server, over which either side can send a message at any time. It was standardised as RFC 6455 in December 2011, and every modern browser supports it.

Bidirectional and full-duplexBoth sides can send at the same time. The server does not wait to be asked, and the browser does not open a new request to reply.
PersistentOne TCP connection stays open for minutes or hours, so there is no new handshake per message.
Low overheadAfter the handshake a message carries a frame header of 2 to 14 bytes, not a full set of HTTP headers.
Message-basedData travels as messages, either UTF-8 text or binary, so you are not parsing a raw byte stream.
Starts as HTTPThe connection begins as a normal HTTP request on port 80 or 443, which is why it gets through most firewalls.
Encrypted when you want itwss:// runs the same protocol over TLS, just as https:// does for HTTP.

The handshake

A WebSocket starts life as an HTTP/1.1 request that asks to switch protocols. If the server agrees, it answers 101 Switching Protocols, and from that moment the same TCP connection speaks WebSocket instead of HTTP.

GET /live HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: https://example.com

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

The Sec-WebSocket-Accept value proves the server really understood the request: it is the client’s key joined to a fixed string from the standard, hashed with SHA-1 and base64-encoded. It is not security on its own; it only stops a plain HTTP server from being mistaken for a WebSocket one.

WebSocket

Frames, briefly

On the wire, every message is one or more frames. Each frame has a small header with an opcode that says what it carries.

WebSocket frame types (opcodes)
Opcode	Frame	Used for
0x1	Text	A UTF-8 message, for example JSON
0x2	Binary	Raw bytes: images, audio, compact encodings
0x0	Continuation	The next part of a message split across frames
0x8	Close	Starts a clean shutdown, with a status code
0x9	Ping	Checks the other side is still there
0xA	Pong	The reply to a ping

Frames sent from the browser to the server are always masked with a random key. That is not encryption; it stops a malicious page from making the traffic look like something a badly written proxy would cache.

All four, compared

Polling, long polling, SSE and WebSockets
	Short polling	Long polling	SSE	WebSocket
Direction	Client asks	Client asks	Server → client	Both ways
Connection	New each time	New per message	One, long-lived	One, long-lived
Delay	Up to the interval	Low	Low	Lowest
Overhead per message	Full HTTP request	Full HTTP request	Small	Smallest (2–14 byte header)
Data	Any	Any	Text only	Text or binary
Auto-reconnect	n/a	Your code	Built in	Your code
Works through HTTP caches/CDNs	Yes	Mostly	Mostly	Needs Upgrade support
Best for	Rare changes	Fallback	Feeds, notifications, AI token streams	Chat, games, tracking, collaboration

Where WebSockets are used

Chat and messagingMessages, typing indicators and read receipts both ways.
Live trackingVehicles, deliveries and devices pushing their position every few seconds.
Multiplayer gamesPlayer moves going out and the game state coming back many times a second.
Collaborative editingMany people editing one document or board and seeing each other’s cursors.
Trading and live pricesTickers and order books that change faster than a page could poll.
IoT and telemetryDevices streaming readings and receiving commands on the same connection.
Live dashboards and opsMetrics, logs and alerts appearing as they happen.

When not to use one

If data changes every few minutes and a short delay is fine, polling is simpler, cacheable and works everywhere. If only the server talks, Server-Sent Events give you reconnection for free over plain HTTP. Reach for a WebSocket when both sides need to talk, often, with as little delay as possible.

What to plan for in production

ReconnectionConnections drop on every network change. Reconnect with backoff, and have the client say what it last saw so it can catch up.
HeartbeatsSend pings so dead connections are noticed and idle proxies do not cut you off.
AuthenticationCheck who the user is during the handshake, and check the Origin header: browsers do not apply the same-origin policy to WebSockets.
Message formatAgree a small envelope, for example a type and a payload, and validate every message, especially from devices.
Scaling outA connection lives on one server. With several servers, use a shared channel such as Redis pub/sub so a message reaches the right connection.
BackpressureA slow client can fall behind. Drop, merge or buffer updates on purpose instead of letting memory grow.

What comes next

WebSockets can also run over HTTP/2 (RFC 8441), sharing one connection with other requests. WebTransport, built on HTTP/3 and QUIC, adds multiple streams and unreliable datagrams for cases like games and media. For most real-time features today, though, a WebSocket is still the simple, well-supported answer.