WebSocket
Full-duplex over the webWebSocket is the open line. HTTP is request-then-response — the server can’t speak unprompted. WebSocket upgrades a single HTTP connection into a persistent channel where either side can send a message at any time. It is how chat, live dashboards and multiplayer games stay in sync.
WebSocket starts as HTTP, then upgrades to a lasting channel where both ends push freely.
How it works
After the 101 the HTTP semantics fall away — no more requests and responses, just a stream of frames either side sends whenever it has something to say.
What WebSocket does, step by step
The client sends an Upgrade request; the server answers 101 and both switch off HTTP semantics.
Small framed messages — text or binary — travel in either direction with almost no overhead.
Ping/Pong control frames keep the connection open through idle periods and detect a dead peer.
Either end sends a Close frame with a status code; the app usually reconnects with backoff.
In cybersecurity
A long-lived channel that skips the usual per-request checks needs its own discipline — the browser’s same-origin rules don’t protect it the way they protect fetches.
Plain ws:// is cleartext; wss:// runs the whole channel over TLS, just like HTTPS.
The handshake isn’t bound by CORS — check the Origin header and use a token, not just a cookie.
Auth happens once at connect — validate it there, and re-check authorization on sensitive messages.
Messages arrive outside the request pipeline, so input validation must live in the socket handler.
Idle open sockets tie up memory; cap connections per user and time out the silent ones.
Many WAFs inspect the handshake but not the frames — put message-level checks on the server.