How WebSockets Work
IntermediateWebSockets provide a persistent, two-way connection between a client and server over a single TCP connection. A normal HTTP request-response cannot push data to the client; the client must keep asking. WebSockets solve this: after an HTTP handshake that "upgrades" the connection, both sides can send messages any time (full-duplex) with very low overhead. They power real-time features — chat, live dashboards, multiplayer games, collaborative editing.
Think of a phone call versus sending letters
Plain HTTP is like sending letters: you mail a question and wait for a reply, one exchange at a time, each with its own envelope and postage (headers). To hear updates, you keep mailing "anything new?" WebSockets are like opening a phone call: you dial once (the handshake), then both people talk freely whenever they want, instantly, until someone hangs up. The line stays open, so there is no per-message envelope overhead.
Step by Step
Key Concepts
The Upgrade Handshake
WebSockets start as an HTTP request with Upgrade headers. A 101 Switching Protocols response converts the connection to the WebSocket protocol, reusing the same TCP connection.
Full-Duplex
Both client and server can send messages at any time over the one connection, unlike HTTP request-response or the one-way flow of Server-Sent Events.
WebSocket vs SSE vs Polling
Polling repeatedly asks over new HTTP requests (simple, wasteful). SSE is a one-way server-to-client stream over HTTP. WebSockets are two-way and lowest-latency, best when the client also sends frequently.
Scaling Challenge
Because each client holds a persistent connection to one server, broadcasting across many servers requires a shared pub/sub layer (e.g., Redis) to relay messages between instances.
Key Facts
- The handshake reuses the existing HTTP/TCP connection via a 101 Switching Protocols response — WebSockets do not open a second port.
- Use wss:// (WebSocket Secure) in production, the TLS-encrypted equivalent of ws://, just as HTTPS is to HTTP.
- For purely server-to-client updates, Server-Sent Events are simpler; reach for WebSockets when the client also needs to send frequently (chat, games).
Real-World Applications
Chat and collaboration
A chat app keeps a WebSocket open per user so messages appear instantly in both directions, and collaborative editors sync keystrokes in real time — impossible efficiently with polling.
Live dashboards and trading
A trading or monitoring UI receives a stream of price or metric updates pushed the instant they change, with the low latency WebSockets provide over a persistent connection.
Frequently Asked Questions
How does the WebSocket handshake work?
It begins as a normal HTTP request that includes Upgrade: websocket and Connection: Upgrade headers plus a Sec-WebSocket-Key. If the server supports WebSockets, it replies with a 101 Switching Protocols response, and the existing TCP connection is upgraded from HTTP to the WebSocket protocol. From then on, both sides exchange lightweight WebSocket frames instead of HTTP messages.
What is the difference between WebSockets and HTTP polling?
With polling, the client repeatedly sends HTTP requests asking if there is new data, each with full request/response overhead and latency between polls. WebSockets open a single persistent, full-duplex connection where the server can push data the moment it is available and the client can send anytime — far lower latency and overhead for real-time communication.
What is the difference between WebSockets and Server-Sent Events?
Server-Sent Events (SSE) provide a one-way stream from server to client over a standard HTTP connection — simple and great for pushing updates. WebSockets are full-duplex, so both client and server can send messages any time. Choose SSE for server-to-client feeds like notifications, and WebSockets when the client also sends frequently, such as chat or multiplayer games.
How do you scale WebSocket servers?
Each client holds a persistent connection to a single server instance, so broadcasting a message to all clients requires coordination across instances. The common approach is a shared pub/sub backend (like Redis) that relays messages between servers, so a message received on one instance reaches clients connected to others. Load balancers with sticky sessions or a dedicated connection layer also help manage the persistent connections.