A persistent, two-way connection instead of request-response.
HTTP is fundamentally request-response: the client asks, the server answers, the connection closes. WebSockets replace that with a single long-lived, full-duplex connection — after an initial HTTP handshake that upgrades the connection, both the client and server can send messages to each other at any time, with none of the overhead of opening a new connection per message.
That persistence is powerful but comes with real responsibilities that HTTP requests don't have: a dropped connection needs manual reconnection logic (usually with exponential backoff), a silently dead connection needs a heartbeat/ping-pong mechanism to detect, and the server needs to track connection state per client rather than treating each request as independent. WebSockets aren't always the right tool either — for updates that only flow server-to-client, Server-Sent Events are simpler and reconnect automatically; for occasional updates, polling is often good enough and far less operationally complex.
What you'll walk away knowing