When HTTP isn't enough
Why realtime apps need a different kind of connection
⏱ Est. ~7 min
01 · Read
You built servers that respond to requests. The browser asks for a page, the server sends it back. A form submits data, the server processes it. This request-response loop is how most of the web works.
But what if the server needs to talk to you first, without you asking?
A chess opponent makes a move. A chat message arrives. A stock price changes. With regular HTTP, the server can't initiate — it has to wait for you to ask. That's a problem when you're building anything realtime.
💡 Picture thisHTTP is like sending letters back and forth. You write, mail it, wait for a reply. It works, but there's a delay every time. WebSocket is like a phone call — the line is open, and either side can talk whenever. No waiting for letters.
Key points
- HTTP is request-response: the client always initiates
- A server can never push data to a client with HTTP alone
- Realtime features like games, chat, and live updates need something else
- WebSocket solves this with a persistent, bidirectional connection
02 · Read
Before WebSocket existed, engineers tried to hack realtime behavior with a technique called polling. The browser would ask the server every second or two: "Any updates?" If there were, the server sent them. If not, the server sent an empty response.
Polling technically works. But it's wasteful. Imagine calling the pizza place every 30 seconds to ask "Is my order ready yet?" Most of the time the answer is no, and you've wasted everyone's time.
WebSocket replaces this hack with the real solution: a persistent connection where either side can send messages whenever, without asking.
Key points
- Polling: client asks "any updates?" on a timer — wasteful
- Most polls return nothing — wasted bandwidth and server load
- WebSocket: one connection, kept open, both sides free to send
- Every major realtime app uses WebSocket: Slack, Discord, Google Docs, multiplayer games
03 · Step-through
Here's how a WebSocket connection gets established — it starts as a regular HTTP request and upgrades.
1. Client sends an HTTP request
The browser sends a normal HTTP request to the server, but with a special header: 'Upgrade: websocket'. It's telling the server "I want to switch from HTTP to WebSocket."
2. Server agrees to upgrade
If the server supports WebSocket, it responds with status code 101 (Switching Protocols). The HTTP connection is now upgraded to a WebSocket connection.
3. Persistent connection is open
Now either side can send messages whenever. The server can push data to the client without being asked. The client can send data to the server without waiting for a response.
4. Messages flow freely
Either side sends small data packets called 'frames'. There's no request-response pattern — just messages going back and forth as needed. This is how a chess move appears instantly on the opponent's screen.
5. Connection closes when done
Either side can close the connection whenever. The browser closes it when you leave. The server closes it when you log out. Until then, it stays open.
04 · Drag to sort
Sort each feature: HTTP or WebSocket?
(This section is interactive — please enable JavaScript.)
05 · Quiz
What's the main advantage of WebSocket over HTTP for a multiplayer game?
- The server can push updates to players instantly without them asking
- WebSocket is more secure than HTTP
- WebSocket uses less bandwidth for initial page loads
- WebSocket doesn't need a server at all
06 · Fill in the blank
Unlike HTTP's request-response loop, WebSocket builds a _____ connection where either side can send messages whenever.
Other lessons in this chapter
⚠ The full interactive experience needs JavaScript. Please enable it and reload.
※ This is an independent Traditional Chinese teaching project — not an official Anthropic product. Claude™ is a trademark of Anthropic, PBC.