Web & Backend
WebSockets
Ordinary HTTP is request-response: the client always speaks first. A WebSocket starts as an HTTP request that asks to 'upgrade' the connection, and once the server agrees, that same TCP connection stays open and either side can send messages at any time, with no need for the client to ask first. It's the standard way to get low-latency, server-initiated updates into a browser or app.
Why it matters
- It's the usual choice for genuinely real-time features
- Chat apps, live dashboards, multiplayer games, and collaborative editors all need the server to push data the moment something happens, not just when the client asks.
- It avoids the overhead of repeated polling
- Polling every few seconds means most requests return 'nothing changed'; a WebSocket sends a message only when there's actually something to say.
- It keeps one connection open instead of opening a new one per update
- Once the handshake is done, there's no repeated HTTP header overhead or new TCP/TLS setup cost for every message.
The handshake that starts a connection
A WebSocket connection begins as a normal HTTP GET request carrying an Upgrade: websocket header. If the server supports it, it responds with a 101 Switching Protocols status instead of the usual 200, and from that point on the same TCP connection is used to send WebSocket frames instead of further HTTP requests.
GET /chat HTTP/1.1
Host: chat.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=Frames and the connection lifecycle
After the handshake, both sides exchange lightweight frames rather than full HTTP messages, which is what makes the connection cheap per message. A connection can be closed by either side, and a well-behaved client handles drops with reconnection and backoff, since networks (especially mobile ones) close idle or interrupted connections without warning.
WebSockets vs polling vs Server-Sent Events
Polling (asking on an interval) is simple and stateless but wastes requests and adds latency up to the poll interval. Server-Sent Events give one-way server-to-client push over plain HTTP, which is simpler to deploy than WebSockets when the client never needs to send anything back. WebSockets are the right tool specifically when both sides need to send messages at any time with low latency.
Mistakes people make here
- Reaching for WebSockets for infrequent updates
- If new data arrives every few minutes, a WebSocket's open-connection overhead buys little over simple polling or Server-Sent Events, which are far simpler to deploy and debug.
- Not handling reconnection and backoff
- Mobile networks, laptop sleep, and load balancer timeouts all close WebSocket connections without warning; a client that doesn't detect and reconnect just goes silently stale.
- Forgetting that WebSocket connections are stateful for load balancing
- Unlike stateless HTTP requests, a WebSocket connection is pinned to one server process, so scaling across multiple servers needs either sticky routing or a shared pub/sub layer so a message can reach a client connected to a different server.
- Skipping heartbeat pings
- Some proxies and load balancers silently drop idle connections; periodic ping/pong frames keep the connection alive and let both sides detect a dead connection instead of writing into a socket that looks open but isn't.
Strengths and trade-offs
Where it is strong
- Low-latency, genuinely bidirectional communication without repeated request overhead.
- One long-lived connection avoids the handshake cost of opening a new request for every update.
- Broad, mature browser and server support across every major platform.
The trade-offs
- Stateful connections complicate horizontal scaling — a load balancer needs sticky sessions, or the backend needs a shared broker so messages reach a client wherever it's actually connected.
- None of the standard HTTP caching or CDN benefits apply, since there's no request/response cycle to cache.
- Harder to observe and debug than request-response traffic, since a connection's message history isn't just sitting in normal HTTP logs.
- Holding many open idle connections costs server memory, which matters at scale in a way stateless HTTP requests don't.
Who needs this
Relevant to developers building genuinely real-time features; most CRUD applications never need it and are better served by ordinary requests or occasional polling.
Questions about websockets
- What's the difference between WebSockets and Server-Sent Events?
- Server-Sent Events are one-way, server-to-client only, and run over plain HTTP, which makes them simpler to deploy through existing infrastructure. WebSockets are fully bidirectional and use their own framing after an initial HTTP handshake, which is necessary when the client also needs to push data to the server in real time.
- Do WebSockets use HTTP?
- Only to start: the initial handshake is a real HTTP request, but once the server responds with 101 Switching Protocols, further communication uses the WebSocket frame format over the same TCP connection, not further HTTP requests.
- Is a WebSocket connection secure?
- wss:// is the WebSocket equivalent of https:// — the connection runs over TLS, encrypting the traffic the same way HTTPS does. Plain ws:// carries no encryption, the same way plain http:// doesn't.
- Why not just poll instead of using WebSockets?
- Polling is simpler to build and debug, and is perfectly reasonable when updates are infrequent or a few seconds of delay doesn't matter. WebSockets earn their complexity when updates need to reach the client with low latency and can happen at any time.