Realtime from First Principles, Part 2: WebSocket and The WebSocket Protocol

WebSocket is a communication protocol that enables full-duplex, bi-directional communication between a client and a server over a single, persistent connection built on top of TCP. Unlike the request-response model that defines regular HTTP traffic, where the client must always initiate every exchange and the server can only reply when asked, WebSocket keeps the connection open once it is established, so either side, the client or the server, can send data to the other at any moment, without waiting for a request first. Before going further, it helps to be clear on what full-duplex actually means, since it is easiest to understand next to its two relatives: simplex and half-duplex. All three describe the direction data is allowed to flow between two devices that are communicating with each other. Simplex communication only allows data to move in one direction, from a sender to a receiver, and never the other way. Think of a keyboard or a mouse sending input to a computer. The keyboard tells the computer what key was pressed, but the computer never sends anything back to the keyboard through that same channel. Data flows one way, permanently. Half-duplex communication allows data to move in both directions, but never at the same time. Only one side can send at any given moment, and the other side has to wait its turn. A walkie-talkie conversation is the clearest everyday example of this. When one person is speaking, the other person has to stay quiet and listen, and only after the first person finishes and signals that they are done, usually by saying something like "over," can the second person start talking. Both sides can send and receive, but taking turns is mandatory. Full-duplex communication allows data to move in both directions at the same time, with neither side needing to wait for the other. A regular phone call is the clearest example of this. Both people on the call can speak and listen at once, and if you interrupt the other person mid-sentence, they still hear you, because both directions of the conversation are open simultaneously. This is exactly the behavior WebSocket gives to a client and a server. Once the connection is open, the server does not have to wait for the client to ask before sending data, and the client does not have to wait for the server to finish before sending its own message. Both sides can talk over the same open connection whenever they need to. WebSocket came about as a direct answer to the limitations already discussed with HTTP-based workarounds like polling, long polling, and HTTP streaming in the first series. The design intent was to give developers something closer to raw TCP itself, a connection where data can flow freely in both directions with minimal overhead. At the same time, they could not hand developers pure, unmodified TCP, because TCP on its own knows nothing about how the web works. It has no concept of an HTTP-based origin, no built-in way to distinguish one message from another, and no knowledge of the security assumptions browsers already rely on. So WebSocket layers a small number of abstractions on top of TCP, just enough to let it work correctly within the existing web platform, without reintroducing the request-response overhead it was designed to escape. The WebSocket Protocol At a high level, the WebSocket protocol has three phases. It begins with an opening handshake, where a regular HTTP connection is upgraded into a WebSocket connection. This is followed by the data transfer phase, where the actual back-and-forth communication happens, with both the client and the server free to send messages whenever they need to, in either direction. Finally, there is a closing handshake, where either side signals that it wants to end the connection, and both sides agree to close it cleanly. Each of these phases is worth walking through in detail, starting with how the opening handshake actually works.