Table of Contents
- Why WebSocket Exists
- The WebSocket Protocol
- Building With Websocket
- Server Sent Events (SSE)
- Building with SSE
- Websocket at scale
- Websocket VS SSE
- When Not to Use It
Why WebSocket Exists
The request-response assumption baked into HTTP. What Ajax and XMLHttpRequest actually changed, and what they did not. Comet as a category, with long polling and HTTP streaming as its two techniques. Where each one breaks: latency from connection setup and sequential requests, header overhead outweighing payloads, ordering and delivery guarantees, and the resource cost of holding thousands of long-polled connections open. Why none of this could be fixed inside HTTP, and how that constraint produced WebSocket in 2008. Close on what WebSocket actually is in one paragraph, so the reader has the answer before the mechanics.
The WebSocket Protocol
The ws and wss schemes. The opening handshake as an HTTP upgrade, and what each required header does. Why Sec-WebSocket-Key and Sec-WebSocket-Accept exist at all, which is the part most tutorials skip and the part that makes the protocol click. Frames: FIN and fragmentation, opcodes, masking and why the client masks but the server does not, payload length encoding. The closing handshake and the close code ranges. Subprotocols and extensions as the negotiated extension points. Security: origin checking, TLS, and the fact that the protocol deliberately says nothing about authentication, which is a design decision worth dwelling on.
Building With It
The WebSocket API surface: constructor, the four events, send and close, and the properties that actually matter in production, particularly bufferedAmount and readyState. Then your own application, built and explained rather than copied. This is where your teaching material carries the post, so make the app yours rather than a cursor-sharing clone. End with what breaks the moment you have more than one server, which sets up part four.
Scale
Why persistent stateful connections resist the scaling patterns people already know. Vertical versus horizontal, and why the interesting question is how many servers rather than how many connections per server. Load balancing at L4 and L7, algorithm choice driven by whether your traffic is uniform or lumpy, and why sticky sessions are the wrong instinct. Sharing connection state across nodes, and pub/sub as the standard answer. Reconnection done properly: naive reconnect, exponential backoff, then jittered backoff, and why each step exists. Heartbeats and their cost at scale. Backpressure, and the fork between dropping messages and acknowledging them. Load shedding and fault tolerance.
When Not to Use It
Server-Sent Events: the EventSource interface, the event stream format, automatic reconnection and Last-Event-ID resumption. The two limitations that historically held SSE back, browser support and the HTTP/1 six-connection limit, and why both are largely gone. Where SSE wins: one-way streams, which is most applications, with a separate POST channel when the client occasionally needs to talk back. Where it does not: chat and anything needing genuine bidirectional flow. The authentication problem with tokens and EventSource. HTTP streaming as the more flexible, less convenient sibling. Close with the decision framework, which is the section readers will actually bookmark.
Top comments (0)