One Connection, Both Directions

Long polling lets the server answer as soon as news arrives, but every answer ends a request. Server-Sent Events let the server keep writing, but only the server. The scoreboard needs both at once: viewers who hear every change the moment it happens, and a scorekeeper who sends scores whenever a question is marked. A WebSocket is the connection built for exactly that. This lesson lists what it provides, and the rest of the course builds it.

Four things a WebSocket provides

1. One connection that stays open. A viewer connects once, at the start of the evening, and keeps the same TCP connection until the quiz ends. No new request is needed for the next piece of news.

2. Either side may send at any time. This is called full duplex. The server sends a score change the moment it happens, without waiting to be asked, and a client sends whenever it has something to say, without waiting for the server. Neither message is a reply to the other.

3. Data arrives as whole messages. You know from Networks with Python that TCP is a stream of bytes with no boundaries: two messages sent one after the other may arrive glued together or cut in pieces. So a WebSocket frames each message, much as your length-prefixed protocol in that course put a length in front of every message. The reader gets Owls 12 as one message, never Ow and then ls 12. Chapter 3 takes those frames apart byte by byte.

4. It starts as an HTTP request. The client opens a connection to the same ports as HTTP and sends an ordinary HTTP request first, so anything that already handles HTTP sees a familiar first few bytes. That request asks the server to switch the connection to the WebSocket protocol, and if the server agrees, the same connection carries WebSocket messages from then on. That switch is called the opening handshake.

Points 1 and 2 are what long polling and Server-Sent Events could not give you together. Point 3 is what makes a long-lived connection usable for messages, and point 4 is how it gets started without anything new between client and server.

What a message costs

Once the connection is open, a message carries very little besides its own bytes. The framing in front of a message the server sends, up to 125 bytes long, is 2 bytes. A message from a client to a server carries 6, because clients add a 4-byte masking key that Chapter 4 explains. The largest framing any message can carry is 14 bytes, for very large messages from a client.

Compare that with one empty poll from Lesson 2: a request line, a Host header and an If-None-Match header going out, and a status line and an ETag header coming back, all to learn that nothing changed. The request line GET /scores HTTP/1.1 alone is 20 bytes before its line ending, and the frame header of a short message is 2. On a WebSocket nobody has to ask, so a minute with no news sends no requests at all.

Four techniques side by side

In the picture, each technique gets two time lines, the client above and the server below, with time running right; a diamond is a score change. Follow each diamond to the arrow that carries it to the client.

The table says the same in columns:

The table makes the WebSocket look like the winner every time, and it is not. Polling is the simplest of the four, and when news is rare, a few requests an hour cost almost nothing. Server-Sent Events are a good fit when only the server has news. A WebSocket earns its extra machinery when both sides talk often.

A WebSocket starts as an ordinary HTTP request, and an HTTP request expects one response and then is done. How can that request turn into a connection that never ends? That is the puzzle of Chapter 2, where you write both sides of the opening handshake yourself.