Why WebSockets

HTTP has a shape: the client asks, the server answers, the connection goes quiet. That shape is perfect for documents and APIs — and fundamentally wrong for chat, multiplayer games, and collaborative editors, where the interesting events happen on the server and the client just needs to hear about them immediately.

The workarounds we lived with

Short polling. The client asks "anything new?" every few seconds. Simple, but you pay a full HTTP request (headers, routing, auth) per poll, and your latency is the polling interval. 10,000 idle users polling every 2 seconds is 5,000 requests/second of nothing.

Long polling. The client sends a request and the server holds it open until there is data (or a timeout), then the client immediately re-requests. Latency improves, but every message still costs a request cycle, and holding requests ties up server resources in frameworks built for quick responses.

Server-Sent Events (SSE). The server keeps one HTTP response open forever and streams text/event-stream events down it. Genuinely good — but it is one-way. Client-to-server traffic still needs separate HTTP requests.

What WebSockets actually are

RFC 6455 (2011) takes a different deal: start as a normal HTTP/1.1 request, then upgrade the underlying TCP connection into a persistent, bidirectional, full-duplex message channel. After the upgrade, either side can send a message at any time — no request/response pairing, no per-message headers beyond a tiny frame header (as small as 2 bytes).

Client                    Server
  |                         |
  | --- HTTP Upgrade --->   |
  | <--- 101 Switching ---  |
  | <==== WS frames ====>   |     both directions, any time
  | <==== WS frames ====>   |
  | --- close handshake --> |

One TCP connection, kept open for the life of the session. That is why Slack, Discord, Figma, trading platforms, and multiplayer games all sit on WebSockets: sub-100ms push in both directions, thousands of messages over one connection.

Choosing the right tool

The engineering skill is knowing when you don't need a WebSocket:

WebSockets cost you: stateful servers, connection bookkeeping, heartbeats, reconnect logic, and trickier load balancing (all coming later in this course). If HTTP or SSE covers the need, take the simpler tool. gRPC streaming and HTTP/2 push exist too, but for browser-to-server real-time, WS remains the standard.

Your exercise

Implement the 4-rule decision table exactly as specified, in order, first match wins, case-insensitive. The mistakes the grader catches: outputs must be the exact uppercase tokens WS, HTTP, SSE, WEBRTC — ws fails. Do not invent rules: periodic poll for status matches no keyword, so the default applies and the grader expects exactly HTTP (not SSE, even though polling "feels" like a push problem). And server-pushed news feed contains feed, so rule 2 fires: the expected output is SSE. Check every keyword in the rule — the hidden test collab document editing only matches via collab.