What are WebSockets in one sentence?

WebSockets are a protocol that turns a single HTTP connection into a persistent, two-way channel, so the browser and server can send messages to each other at any time without polling.

How is a WebSocket different from HTTP?

HTTP is request-response: the client asks, the server answers, the connection is typically done. A WebSocket stays open and is full-duplex — either side can send a message whenever it wants.

When should I use WebSockets?

Use them when the server needs to push updates to clients in real time and frequently: chat, live dashboards, collaborative editing, multiplayer, and trading feeds. For occasional updates, simpler options like SSE or polling often suffice.

Are WebSockets hard to scale?

They add complexity. Each open connection consumes server memory and is stateful, so you need sticky sessions or a pub/sub backplane (like Redis) to broadcast across many server instances behind a load balancer.

What is the ws vs wss difference?

ws:// is an unencrypted WebSocket connection; wss:// is the TLS-encrypted version, the WebSocket equivalent of HTTPS. Production traffic should always use wss.

Glossary · Web Platform

What are WebSockets?

WebSockets are a protocol that upgrades an ordinary HTTP connection into a single, persistent, full-duplex channel — once open, the browser and server can each send messages to the other at any moment, with no new request needed — which is what makes real-time features like chat, live dashboards, and collaborative editing feel instant.

The problem they solve

Plain HTTP is one-directional in spirit: the client asks, the server answers. To fake real-time updates, the early web hammered the server with repeated requests — polling — or held requests open until data arrived, a trick called long polling. Both are wasteful. WebSockets, standardized as RFC 6455 in 2011, replaced the workarounds with a real persistent channel where the server can push the instant something changes.

The upgrade handshake

A WebSocket starts life as a normal HTTP request carrying an Upgrade: websocket header. If the server agrees, it responds with status 101 Switching Protocols, and from that point the same TCP connection stops speaking HTTP and starts exchanging WebSocket frames. Because it begins as HTTP, it travels over the same ports (80 and 443) and slips through firewalls and proxies that already allow web traffic — a big part of why it won.

Full-duplex, and what that buys you

Full-duplex means both directions are live at once, like a phone call rather than a walkie-talkie. The latency drops because there is no per-message handshake, and the overhead is tiny — a few bytes of framing instead of a fresh set of HTTP headers on every update. For a live trading screen, a multiplayer game, or a shared document where keystrokes appear on everyone's screen, that difference is the whole product.

The scaling tax

Persistent connections are stateful, and state is what makes scaling hard. Each open socket holds memory on a specific server, so you cannot just round-robin requests across a fleet the way you would with stateless HTTP behind a load balancer. You need sticky routing to keep a client pinned to its server, and a pub/sub backplane — frequently Redis or a dedicated message queue — so a message published on one node reaches clients connected to all the others.

When something simpler will do

WebSockets are not always the answer. If updates only flow from server to client — a notifications feed, a progress bar — Server-Sent Events are lighter and auto-reconnect for free. If updates are rare, ordinary polling is fine and far easier to operate. Reach for WebSockets when you genuinely need frequent, low-latency, two-directional traffic; otherwise you are paying the scaling tax for capability you do not use. We lay out the choice in our long polling vs WebSockets explainer.

At QUANT LAB

We build real-time features the boring, reliable way: wsseverywhere, authenticated connections, heartbeat pings to detect dead sockets, exponential-backoff reconnection on the client, and a Redis-backed backplane so the system scales past one server. Our API development work treats the WebSocket layer as a first-class part of the architecture rather than a demo that falls over under load. And when a project does not actually need a live socket, we say so.

Long-form deep-dives that use this term

All posts

Related terms

Building real-time features?

We design WebSocket layers that survive reconnects, scale past one server, and stay secure. Book a 30-minute call.

API development