learninfra · Linux · Networking · Kubernetes · System Design · AI Infrastructure · Exam blueprints · Drills

WebSockets

HTTP can only answer. A WebSocket turns one TCP connection into a line both ends may speak on, and you have to keep that line alive.

An interactive Networking lesson: 23 steps, about 30 minutes, on a live simulation in your browser.

You bought something at shop.example. Order 42 is somewhere between the warehouse and your door, and the order page on your laptop should say where.

The page asks the only way HTTP allows: the laptop opens a TCP connection to web, sends GET /orders/42, and the server answers 200 OK. Follow the request out through home-router and the response back.

What you will learn

  1. The server cannot speak first

    • HTTP is ask, then answer: HTTP is ask-then-answer: the client speaks first, every time. A server with news has to wait to be asked.
    • Polling: are we there yet?: Polling turns "tell me when it changes" into "has it changed yet?", asked forever. You pay for every no.
    • Long polling: the stopgap

  2. The upgrade

    • Asking to stop speaking HTTP: A WebSocket is an HTTP/1.1 request that asks to stop being HTTP. After 101, the same TCP connection carries frames in both directions.
    • Reading the handshake
    • Drill: test an upgrade by hand
    • The server speaks first: After the upgrade there are no requests and no responses, only messages. Either end sends when it has something to say.

  3. Frames

    • A message is not a request: WebSocket gives you messages, not answers. Matching a reply to a question is your application's job.
    • Inside a frame: A frame is a two-byte header, an opcode that says text, binary, close, ping or pong, and a payload. Clients add a four-byte mask; servers never do.
    • Drill: talk to a socket from a shell

  4. Idle connections die quietly

    • Ping and pong: A ping is traffic with no meaning. It proves the other end is alive and resets every idle timer on the path.
    • Break it: two quiet hours: Every NAT, firewall and load balancer on the path keeps per-connection state with an idle timer. Stay silent longer than the shortest timer and the connection is dead.
    • Half-open: one end still believes: An idle TCP connection sends nothing, so a dead one and a quiet one look identical. Only traffic can tell them apart.
    • Reconnect, then catch up: WebSocket delivers every message, in order, within one connection. Across a reconnect, catching up is your protocol's job.
    • Fix it: a heartbeat: Send a heartbeat more often than the shortest idle timer on the path. You rarely know that timer, so use 20 to 30 seconds.

  5. Ending and reconnecting

    • Break it: the server goes away
    • Closing on purpose: A close frame says "I am done, and here is why". A connection that ends without one ended by accident.

  6. What sits in the path

    • A proxy has to pass the upgrade: Upgrade is hop-by-hop. Every HTTP proxy on the path must be told to pass it, or the handshake ends in something other than 101.
    • Pinned to one backend: A WebSocket is balanced once, at the handshake, and then pinned to that backend for life. Adding capacity helps only connections that open afterwards.
    • wss://: the same thing inside TLS: wss:// is TCP, then TLS, then the same upgrade. Use it always: it is private, and nothing in the middle can interfere with an upgrade it cannot see.
    • When not to use a WebSocket: Pick the least powerful tool that fits: polling for rare updates, Server-Sent Events for a one-way stream, a WebSocket when both ends need to talk.

  7. Recap & playground

    • Cheat sheet
    • Playground