Concepts
Persistent bidirectional connections (WebSocket)
Intuition
Imagine you want to know whether any news has arrived and, to find out, you call the other side from time to time, introduce yourself in full on each call, and listen to the answer before hanging up. It is tiring, and the other side can only speak when you ask. The alternative is to make a single call and leave it open: from then on either of you speaks when there is something to say, and there is an agreed way to signal that you are about to hang up.
How it works
RFC 6455 starts from the cost of simulating bidirectional communication over HTTP: repeated polling, one TCP connection for the server to send and a new one for each client message, the overhead of full HTTP headers on every client-to-server message, and the script's work of matching each request to its corresponding response. WebSocket trades that for a single TCP connection that carries traffic in both directions, made up of an opening handshake followed by a thin layer of message framing. The handshake is an ordinary HTTP GET request, which lets it traverse infrastructure that already understands HTTP, with the headers Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Version 13 and a random Sec-WebSocket-Key; if the server accepts, it replies 101 Switching Protocols with a Sec-WebSocket-Accept derived from the key (fixed GUID concatenated, SHA-1, base64), and the same TCP connection now carries WebSocket frames instead of HTTP. From then on each side sends messages whenever it wants, in text or binary frames that can be fragmented, and every client-to-server frame must be masked with an unpredictable key, so that a script cannot control the bytes that go over the network and poison an intermediary proxy. A Ping (which the receiver must answer with a Pong repeating the data, unless it has already received a Close) can serve as a keepalive or to check whether the other side is still responding. Closing is also message-based: whoever wants to end the connection sends a Close frame with an optional status code (such as 1000, normal closure), sends no more data after that, and the peer replies with its own Close, if it has not already sent one; once both sides have sent and received Close, the server should close the TCP connection immediately. In the origin model, the browser always sends the Origin header, and a server that only wants to serve certain sites should, as a rule, compare it against the expected origins and, if the origin is not acceptable, respond 403. This blocks malicious scripts in a trusted browser, but it does not prove who is calling, because a non-browser client can put any value in Origin; confidentiality and integrity come from running over TLS (wss URIs), and client authentication is left to the mechanisms an ordinary HTTP server would use.
In practice
The RFC presents WebSocket as a simpler replacement for HTTP polling when a browser application needs to exchange data with the server in both directions, avoiding multiple connections per client and full HTTP headers on every client message. In practice, it is worth using wss to get TLS, validating the Origin of the handshake but treating it only as protection against scripts in browsers and not as authentication, using Ping/Pong as a keepalive, and always closing with the Close handshake and an appropriate status code. Because the handshake is an HTTP request, the connection can traverse infrastructure that already understands HTTP before it becomes a WebSocket.
Use it in a design
Practice the cases that rely on this concept in the System Design school.