WebSocket

Standard HTTP works in one direction at a time. The browser sends a request, the server sends a response, and the connection is done. If you want fresh data you have to ask again. That model is fine for loading a page, but it falls apart when the server is the one with news to share, like a new chat message or a stock price tick.

A WebSocket fixes this by upgrading a normal HTTP connection into a persistent, two-way channel. Once it is open, either side can send a message whenever it wants without starting a new request. This is called full-duplex communication, the same way a phone call lets both people talk at once instead of mailing letters back and forth.

The protocol is defined in RFC 6455 and uses the ws:// scheme for plain connections and wss:// for encrypted ones over TLS. It runs over the same ports as the web, 80 and 443, so it passes through most firewalls and proxies that already allow web traffic.

Every WebSocket starts life as an ordinary HTTP request. The browser sends a GET with the header Upgrade: websocket and Connection: Upgrade, plus a random Sec-WebSocket-Key. If the server agrees, it replies with status 101 Switching Protocols and a hashed Sec-WebSocket-Accept value that proves it understood the request. This exchange is called the handshake.

After the 101 response, the connection stops speaking HTTP. The same TCP socket now carries lightweight WebSocket frames. Each frame has only a few bytes of overhead compared to the hundreds of bytes of headers a fresh HTTP request would need, so high-frequency updates stay cheap.

Frames can carry text (usually JSON) or binary data, and there are control frames for ping, pong, and close. The ping and pong frames act as a heartbeat so each side can tell the connection is still alive and clean up dead sockets. To detect broken connections faster, servers commonly send a ping every 20 to 30 seconds.

On the server you are now holding one open connection per client. A server keeping 100,000 live chat users connected is holding 100,000 sockets in memory, which is a very different scaling shape from stateless HTTP where connections come and go in milliseconds.

Reach for WebSockets when the server needs to push data without being asked and updates are frequent: chat, collaborative editing, live dashboards, multiplayer games, and trading feeds. They beat the old trick of polling, where the client asks every few seconds and mostly gets back nothing, which wastes requests and adds delay.

The cost is that connections are stateful. A crashed server drops every socket it was holding, and load balancers must be configured for sticky sessions or for proxying the upgrade, since a connection is pinned to one backend. Scaling out means a shared layer like Redis pub/sub so a message arriving on server A reaches a user connected to server B.

If the data only flows one way, server to client, Server-Sent Events (SSE) are simpler because they run over plain HTTP and reconnect automatically. If updates are rare, ordinary polling or a request when the user acts is cheaper than holding an idle socket open. Use WebSockets when you genuinely need low-latency two-way traffic, not by default.

Picture a live football score page. With polling, the browser hits the server every 5 seconds asking has the score changed, and 99 percent of the time the answer is no. That is thousands of wasted requests and a goal might still show up to 5 seconds late.

With a WebSocket, the browser opens one connection when the page loads and then waits. The moment a goal is scored, the server pushes a single small frame like {"home":2,"away":1} to every connected viewer at once. Latency drops to tens of milliseconds and the server does almost no work while nothing is happening.

Slack works the same way for messages, Figma uses the pattern to sync cursors and edits between collaborators in real time, and trading platforms stream price ticks this way. In each case the value comes from the server being able to speak first.