Chapter 10 — WebSockets & Real-Time (HTTP/2 & HTTP/3)
Chapter 10 — WebSockets & Real-Time (HTTP/2 & HTTP/3)
Hey everyone! Welcome to the final chapter of Namaste Computer Networks! 🙏
Everything so far has been request/response: the client asks, the server answers, done. But chat apps, live scores, and notifications need the server to push updates without being asked. Enter WebSockets. We'll also see how HTTP itself evolved — HTTP/1.1 → HTTP/2 → HTTP/3 — to make the modern web fast. A great closer that ties the whole series together.
What we will cover:
- The limits of request/response for real-time
- Polling vs long polling vs WebSockets
- How WebSockets work
- HTTP/1.1 → HTTP/2 → HTTP/3, briefly
- When to use what
- Interview Questions
1. The Problem: The Server Can't Start a Conversation
Normal HTTP: the CLIENT must always ask first.
[ Client ] ──ask──▶ [ Server ]
[ Client ] ◀answer─ [ Server ]
But for a chat app, when your friend sends a message, the SERVER
needs to push it to YOU — and you didn't ask. HTTP can't do that
on its own. So how do we fake or fix it?
2. Three Approaches to Real-Time
| Technique | How it works | Verdict |
|---|---|---|
| Polling | Client asks "any updates?" every few seconds | ❌ Wasteful, laggy, lots of empty requests |
| Long polling | Client asks; server holds the request open until it has data, then responds | ⚠️ Better, but clunky (reopen each time) |
| WebSockets | One persistent, two-way connection stays open | ✅ The right tool for real-time |
3. How WebSockets Work
┌─────────────────────────────────────────────────────────────┐ │ WEBSOCKET = a persistent, full-duplex (two-way) connection │ │ between client and server. Once open, EITHER side can send │ │ data anytime, instantly, without a new request. │ └─────────────────────────────────────────────────────────────┘
1. Starts as a normal HTTP request with an "Upgrade" header:
"Hey server, let's upgrade this to a WebSocket."
2. Server agrees (101 Switching Protocols).
3. The connection stays OPEN as a two-way pipe:
[ Client ] ══════ persistent WebSocket ══════ [ Server ]
▲ │
└───── server pushes updates anytime ────────┘
Perfect for: chat, live notifications, multiplayer games,
live dashboards, collaborative editing (Google Docs).
(This is exactly the tech behind the chat-app design in the System Design series — it all connects!)
4. The Evolution of HTTP
HTTP/1.1 (1997) — one request at a time per connection
✗ "head-of-line blocking": requests queue up; a slow one
blocks the rest. Browsers opened many connections to cope.
HTTP/2 (2015) — MULTIPLEXING
✔ Many requests/responses share ONE connection at once, in
parallel. Also compresses headers, and the server can
"push" resources. Much faster page loads.
HTTP/3 (2022) — runs over QUIC (built on UDP, not TCP!)
✔ Removes TCP's head-of-line blocking entirely, faster
connection setup (combines transport + TLS handshake),
and better on flaky mobile networks.
THE TREND: each version reduces waiting and does more in parallel. HTTP/3 even swaps TCP for UDP+QUIC — proving (from Chapter 04) that reliability can be rebuilt on UDP when you want more control over latency.
5. When to Use What
Request/response (REST over HTTP) → most things: pages, APIs,
CRUD. The default.
WebSockets → true real-time, two-way: chat, live feeds, games.
Server-Sent Events (SSE) → server → client push ONLY (one-way),
simpler than WebSockets. Good for live notifications/tickers.
Long polling → a fallback when WebSockets aren't available.
Interview Questions — Quick Fire!
Q: Why can't plain HTTP do real-time server push?
"Because HTTP is request-response — the client must always initiate, and the server can only reply to a request it received. So the server can't spontaneously push data, like a new chat message, to the client. Workarounds include polling and long polling, but the proper solution is WebSockets, which keep a persistent two-way connection open."
Q: What is a WebSocket and how is it established?
"A WebSocket is a persistent, full-duplex connection between client and server where either side can send data anytime without a new request. It starts as a normal HTTP request with an Upgrade header asking to switch protocols; the server agrees with a 101 Switching Protocols response, and the connection then stays open as a two-way channel. It's ideal for chat, live notifications, and multiplayer games."
Q: What's the difference between polling, long polling, and WebSockets?
"Polling has the client repeatedly ask for updates on a fixed interval, which wastes requests and adds lag. Long polling has the client send a request that the server holds open until it has data, then responds, and the client immediately reopens it — better, but still request-based. WebSockets keep a single persistent bidirectional connection open, so the server can push updates instantly. WebSockets are the most efficient for genuine real-time."
Q: What did HTTP/2 improve over HTTP/1.1?
"HTTP/1.1 largely handled one request at a time per connection, causing head-of-line blocking where a slow request delayed others. HTTP/2 introduced multiplexing, letting many requests and responses share one connection in parallel, plus header compression and server push. This significantly sped up page loads by reducing waiting and the need for many connections."
Q: What's notable about HTTP/3?
"HTTP/3 runs over QUIC, which is built on UDP rather than TCP. This eliminates TCP's head-of-line blocking, speeds up connection setup by combining the transport and encryption handshakes, and performs better on unreliable mobile networks. It shows that reliability can be rebuilt on top of UDP when you want finer control over latency."
Key Points to Remember
| Concept | Key Takeaway |
|---|---|
| Real-time problem | HTTP is request-response; server can't push on its own. |
| WebSockets | Persistent two-way connection; either side sends anytime. For chat/live. |
| Polling ladder | Polling (wasteful) → long polling (better) → WebSockets (best). |
| HTTP/2 | Multiplexing many requests on one connection; header compression. |
| HTTP/3 | Runs over QUIC/UDP; kills head-of-line blocking; faster setup. |
What's Next? — You Finished the Core!
That's all three seasons! You can now explain how data travels from your keystroke to a distant server and back. Treat yourself to the Deep Dives: the complete "what happens when you type a URL" journey that ties every chapter together, and a TCP connection lifecycle trace. Then hit the Bonus interview round.
Keep learning, keep connecting! See you in the deep dives! 🚀
Post a Comment