What are WebSockets? A plain explanation

WebSockets are a protocol for full-duplex communication over a single TCP connection: once connected, both the browser and the server can send messages any time, without the other side asking. The protocol was standardized by the IETF in December 2011 as RFC 6455, and it is what powers chat apps, live dashboards, multiplayer games and collaborative editing tools.

The problem: HTTP is half-duplex

Normal HTTP is request-response: the browser asks, the server answers, the connection is done. The server can never send something first. If a page needs live data — a chat message, a stock price, a game move — older sites had to fake it by polling: asking the server "anything new?" every few seconds, wasting requests even when nothing changed. More elaborate workarounds (long polling, Comet, Flash sockets) existed, but none was a clean standard.

The handshake: HTTP says "switch"

A WebSocket connection starts life as an ordinary HTTP request. The client sends a GET request with special headers:

• Upgrade: websocket and Connection: Upgrade — asking to switch protocols
• Sec-WebSocket-Key — a base64-encoded 16-byte random value
• Sec-WebSocket-Version: 13 — the protocol version
• Origin — the page's origin, sent by all browser clients

If the server agrees, it answers with HTTP/1.1 101 Switching Protocols and a Sec-WebSocket-Accept header derived from the key. Any other status code means the handshake failed and no WebSocket connection exists. The protocol is designed to run over ports 80 and 443 and to work through HTTP proxies and intermediaries — which is why it can reach users behind firewalls that block everything else.

The connection: small frames, both directions

After the handshake, both sides talk in frames: a tiny header (FIN bit, opcode, masking bit, payload length) plus the payload. Text and binary are the two main frame types, and a message can be split across several frames. Two details matter in practice:

• Masking — every frame a client sends to the server must be masked with a fresh random key. This protects web infrastructure: without it, a malicious script could craft data that looks like an HTTP request and poison caching proxies.
• Control frames — close, ping and pong frames are capped at 125 bytes of payload and never fragmented. A ping must be answered with a pong as soon as practical, which is how connections stay alive through idle periods and proxies.

Closing the connection

Either side can end the conversation by sending a Close frame with a status code. The common ones:

Both sides exchange Close frames, then the TCP connection is closed — by the server first in the normal case, so the server (not the client) holds the TIME_WAIT state.

Security: wss:// and the Origin check

WebSocket URLs come in two flavors: ws:// (plain) and wss:// (encrypted, WebSocket over TLS — the same protection HTTPS gives HTTP). Use wss:// anywhere the data matters.

Two safeguards are built into the protocol. First, the server should verify the Origin header and reject handshakes from origins it does not expect (a 403 Forbidden reply). That blocks other websites from abusing the connection. Second, masking keeps scripts from weaponizing proxies. One caveat: non-browser clients can send any Origin they like, so a server must treat all incoming data as untrusted and validate it like any other input. Authentication itself is not part of the protocol — servers use the usual HTTP mechanisms: cookies, HTTP authentication, or TLS client certificates.

When to use WebSockets — and when not

Use them when you need low-latency two-way exchange: chat, live sports scores or stock tickers, multiplayer games, real-time dashboards, collaborative editing. Don't reach for them when HTTP does the job — regular pages, occasional updates (caching works fine), or one-way server-to-client streams, where a simpler mechanism often fits better. WebSockets keep a connection open per session, which costs server resources and needs careful handling of disconnects and reconnects.

A bit of history

The name "WebSocket" was coined by Ian Hickson and Michael Carter in 2008, and the protocol was authored for inclusion in the HTML5 specification. Google Chrome 4 was the first browser to ship it enabled by default in December 2009. Development moved to the IETF in February 2010, and RFC 6455 was finalized in December 2011 under Ian Fette. Early protocol drafts had security flaws and were disabled in Firefox 4 and 5 and Opera 11. On the server side, nginx added support in version 1.3.13 (2013), Apache in 2.4.5 (July 2013), and lighttpd in 1.4.46 (2017).

Summary

A WebSocket is a full-duplex channel over one TCP connection: an HTTP handshake upgrades the link, then small frames flow both ways until a Close frame ends it. It is the standard answer when a web page needs the server to push data live — and with wss://, origin checks, and masking, the protocol was built with the web's security model in mind.

FAQ

What problem do WebSockets solve that HTTP can't?

Plain HTTP is request-response: the client asks, the server replies, then the connection ends — the server can never send first. WebSockets keep one connection open so either side can push data at any time, removing the need to fake "live" updates with polling.

Is WebSocket the same as HTTP?

No. A WebSocket connection starts as an HTTP request (the 101 Switching Protocols handshake), then upgrades to a separate protocol that runs over the same TCP connection. After that, it is no longer HTTP — it sends small bidirectional frames instead of request/response pairs.

Is wss:// necessary?

Use wss:// (WebSocket over TLS) whenever the data matters. Like HTTPS for HTTP, it encrypts the traffic so it cannot be read or tampered with on the wire. ws:// is plain text and should only be used for throwaway, non-sensitive data.

Can any website open a WebSocket to my server?

Not freely. The server should check the Origin header and reject handshakes from origins it does not expect (a 403). But non-browser clients can send any Origin, so the server must still validate every incoming message as untrusted input — the protocol itself does not authenticate the peer.