The WebSocket Protocol
WebSocket (RFC 6455) is a protocol providing full-duplex, persistent communication over a single TCP connection. It begins as an HTTP request that upgrades, then both client and server can send messages anytime, enabling real-time apps without HTTP's…
Why it exists
Plain HTTP is request-response and client-initiated: the server cannot push data unless the client asks. Building real-time features on HTTP meant hacks like short polling (repeatedly asking 'anything new?') or long polling, both wasteful in latency and overhead. WebSocket was created to give a true bidirectional, persistent connection so servers can push to clients the instant something happens.
The mental model
Think of HTTP as mailing letters back and forth, one request per reply, versus WebSocket as opening a phone line that stays connected so either party can speak at any moment. It is full-duplex (both directions simultaneously) and persistent (one connection reused for the whole session).
How it works
The connection begins as an ordinary HTTP request carrying an Upgrade: websocket header and a Connection: Upgrade header, plus a Sec-WebSocket-Key. If the server agrees, it responds with status 101 Switching Protocols, and the same TCP connection is now a WebSocket. From then on, data travels as lightweight binary frames rather than HTTP messages, so there are no repeated headers per message. Either side can send text or binary frames at any time, plus control frames for ping/pong (keepalive) and close. The URL schemes are ws:// and wss:// (the latter being WebSocket over TLS).
When it matters
Use WebSocket when the server must push updates with low latency and high frequency: chat and messaging, live sports or stock tickers, collaborative editors, multiplayer games, and live dashboards. It is overkill for occasional updates, where simpler approaches like server-sent events or periodic polling suffice, and it adds complexity around connection state, reconnection, and scaling across servers.
A concrete example
In a chat app, each browser opens one WebSocket to the server. When Alice sends a message, it travels up her socket; the server immediately pushes it down Bob's already-open socket, so Bob sees it instantly with no polling. In Node.js this is typically built with a library like ws or Socket.IO layered on top of the HTTP server.
Interview question
How does a WebSocket connection initially get established between a browser and a server?
- a.By repeatedly polling an HTTP endpoint until the server keeps the connection open
- b.By opening a raw TCP socket with no HTTP involvement at all
- c.By sending a UDP datagram that the server acknowledges
- d.By starting as an HTTP request that uses an Upgrade header to switch protocols, answered with 101 Switching ProtocolsCorrect
Why? this is the answer
WebSocket begins with an HTTP handshake that requests an Upgrade and receives a 101 Switching Protocols response, after which the same TCP connection becomes full-duplex. It is not a raw socket, UDP, or polling, which are the misconceptions the distractors capture.
Just read this? Test yourself on what you have been reading.
Read the original → datatracker.ietf.org
- #websocket
- #nodejs
- #real-time
- #protocol
- #networking
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles