Standard HTTP is a one-way street: the client asks, the server answers, and the connection closes. That works for loading pages, but not for chat, live dashboards, multiplayer games or collaborative editors, where the server needs to push updates the instant they happen. WebSockets are the answer, and this guide explains how they work.
The limitation of plain HTTP
With HTTP, the server cannot speak unless spoken to. To simulate real-time updates, apps used to poll — repeatedly asking "anything new?" — which wastes requests and adds delay. WebSockets remove that limitation by keeping a single connection open through which either side can send data freely.
The upgrade handshake
A WebSocket connection starts life as an ordinary HTTP request with an Upgrade header. If the server agrees, the connection is "upgraded" from HTTP to the WebSocket protocol and stays open. From then on, messages flow in both directions over that one persistent connection, with very little overhead per message.
When to use WebSockets
- Chat and messaging, where messages arrive unpredictably.
- Live dashboards and feeds that update continuously.
- Collaborative editing, where many users change shared state.
- Multiplayer games needing low-latency two-way updates.
When not to
WebSockets are not always the right tool. If you only need occasional server-to-client updates, Server-Sent Events are simpler. If data changes infrequently, ordinary requests are fine. A persistent connection has costs — it holds server resources and needs reconnection logic — so reach for it when genuine real-time, two-way communication is the requirement.
The takeaway
WebSockets turn the request-response web into something interactive and live. Understanding the upgrade handshake and the persistent, bidirectional nature of the connection is the key to knowing when they are worth the added complexity.