What Are WebSockets?

Every real-time feature you've ever used — a chat message appearing without refreshing, a live scoreboard ticking up, a collaboration cursor moving across a shared document — is powered by a persistent connection between the browser and the server. WebSockets are the technology that makes those connections possible. This lesson explains what WebSockets are, how they differ from HTTP, and when you actually need them.

The problem with HTTP for real-time

HTTP is a request–response protocol. The browser asks; the server answers; the connection closes. That model works perfectly for loading a webpage, submitting a form, or fetching data. But it breaks down the moment you need the server to push something to the client without the client asking first. With plain HTTP, you have two bad options.

• Polling — The client asks the server "anything new?" every second. This works but wastes bandwidth and server resources when nothing has changed. At 1,000 users polling every second, you have 1,000 pointless requests per second.
• Long polling — The client asks the server and the server holds the connection open until there is something to say, then closes it. Better than polling, but still creates a new HTTP connection on every message cycle. High overhead for frequent updates.

What WebSockets actually do

A WebSocket connection starts as an HTTP request — specifically an HTTP Upgrade request. The client says 'I want to switch to WebSocket protocol' and the server agrees. From that point on, the connection stays open and both sides can send messages to each other at any time, with no request-response overhead. A single TCP connection handles an entire session.

WebSocket vs HTTP: the wire-level difference

Once the handshake completes, WebSocket frames are much smaller than HTTP messages because they carry no headers on each exchange — only the payload and a few bytes of framing metadata. For applications sending hundreds of small messages per second, this overhead difference is meaningful.

# Client → Server (HTTP Upgrade request)
GET /socket HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

# Server → Client (101 Switching Protocols)
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

# Both sides can now send frames freely

When to use WebSockets

Not every real-time feature needs WebSockets. Choose the right tool for the frequency and direction of your updates.

• Use WebSockets for: chat and messaging — Messages need to arrive the moment they are sent. Polling would feel laggy; WebSockets feel instant.
• Use WebSockets for: collaborative editing — Cursor positions, document changes, and presence indicators all require low-latency bidirectional updates.
• Use WebSockets for: live dashboards with high update frequency — Prices, sensor readings, game state — anything updating more than once every few seconds.
• Consider Server-Sent Events instead for: one-way streams — If the server pushes but the client never needs to respond in real time (notifications, news feeds, AI token streaming), SSE is simpler and works over plain HTTP.
• HTTP is fine for: infrequent updates — Refreshing a dashboard every 30 seconds, checking order status every minute — polling HTTP is perfectly adequate and much simpler to operate.

The WebSocket ecosystem

The raw WebSocket API is built into every modern browser and into Node.js (via the `ws` package). In practice, most developers use Socket.io, which wraps the raw WebSocket API with automatic reconnection, rooms, namespaces, and a fallback to long polling for environments where WebSockets are blocked. Later lessons cover both.

Summary