Networking & Protocols
WebSocket: multiple-choice review
Crux Multiple-choice synthesis across the WebSocket unit: upgrade, framing, transport choice, backpressure, reconnection, scaling ceilings, and production failure modes.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. None is a definition to recite — each mirrors a decision a senior engineer makes while a real-time service is degrading under load.
Goal
Confirm you can connect the upgrade, the frame format, transport choice, backpressure, reconnection, and scaling ceilings into one coherent operational model — the synthesis the individual lessons built toward.
Quiz
Completed
A teammate proposes opening a raw TCP socket on a custom port to skip the HTTP upgrade and 'save a round-trip'. Why is this the wrong reasoning?
Heads-up The key/accept exchange is a single SHA-1 hash, microseconds of CPU. It adds no round-trips and is not a latency cost — it exists to prove the server intentionally processed the upgrade, not a cached response.
Heads-up Browsers cannot open arbitrary raw TCP sockets at all; the WebSocket API exists precisely because raw TCP is unavailable to page JavaScript. The premise is impossible, not merely non-portable.
Heads-up The upgrade rides the connection that already exists; the 101 is the response to the same GET. There is no extra round-trip to save.
Quiz
Completed
A custom WebSocket client (outside a browser) sends server-to-client-style unmasked frames to your server. Should the server accept them, and why does masking exist at all?
Heads-up Masking is not encryption; it carries the key in plaintext in the frame. It is a structural defense against cache poisoning, and the RFC makes it mandatory for client frames regardless of trust.
Heads-up It is the reverse: server-to-client frames are never masked (same-origin policy already blocks reading them), while client-to-server frames must always be masked.
Heads-up Unmasked frames are trivially decodable — there is no key to apply. The reason to reject is the RFC requirement and the cache-poisoning threat model, not a decoding failure.
Quiz
Completed
A dashboard pushes ~5 updates per minute to 100k users who never send data back. An engineer reaches for WebSocket. What is the better default and why?
Heads-up WebSocket's 0-5 ms vs SSE's 3-8 ms is real but meaningless at 5 updates per minute. It costs you custom reconnection logic and proxy-compatibility risk with no payoff for a server-push-only feed.
Heads-up Long-polling also works everywhere, but at 100k users it holds 100k open requests and pays ~500 bytes of headers per poll. SSE gives the same proxy compatibility with a single efficient stream and built-in reconnect.
Heads-up There is one channel per user here; multiplexing many streams per client solves a problem this feature does not have. It is needless complexity over plain SSE.
Quiz
Completed
A broadcast server's memory climbs steadily under load until the OOM killer fires; 100 of 10,000 clients are on slow mobile links. What is the mechanism, and what is the first durable fix?
Heads-up The 'leak' is unbounded send queues for clients that cannot keep up — bounded, intentional buffers with no eviction policy. Scheduled restarts mask the symptom; the high-water mark fixes the cause.
Heads-up GC pauses lengthen because the heap is bloated by queued messages — a symptom, not the cause. Capping queue growth removes the bloat; the collector choice is downstream.
Heads-up More servers spread the same flaw; each still bloats from its slow clients. Without a high-water mark and eviction, scaling out just delays the OOM.
Quiz
Completed
You deploy a new build; all 10 million connected clients drop with code 1006 and reconnect. Your client uses exponential backoff but no jitter. Why does the server still struggle to recover?
Heads-up A larger backlog raises the cliff but synchronized 10 M waves still overrun it. The structural fix is desynchronizing the clients with jitter, not absorbing the synchronized burst.
Heads-up 1006 is an abnormal close (no close frame) — exactly the case where clients should reconnect. The problem is how they reconnect, not whether.
Heads-up Plain exponential backoff is deterministic doubling; jitter is a separate, explicit randomization (e.g. delay times random(0.5,1.5)) that you must add on top.
Quiz
Completed
Two WebSocket servers sit behind a load balancer. User A on Server 1 sends a chat message that must reach User B on Server 2. Sticky sessions are enabled. Why is sticky routing alone insufficient, and what closes the gap?
Heads-up Stickiness routes a given client consistently to its own server; it has no mechanism to deliver A's message to B's different server. Cross-server fan-out needs pub/sub.
Heads-up Per-frame balancing would scatter a single client's state across servers and break in-flight unACK'd state. Stickiness plus pub/sub is the combination — stickiness for per-connection state locality, pub/sub for fan-out.
Heads-up A shared database stores messages but does not push them; a server has no signal that a new row appeared without polling. Pub/sub (or streams with consumers) provides the real-time fan-out signal.
Recap
The unit’s through-line is one operational model: the upgrade reuses the existing connection so shared infrastructure still routes it; framing and mandatory client masking defend the wire; transport choice (WebSocket vs SSE vs long-polling) follows the direction of data flow; backpressure is the canonical failure mode, answered by a high-water mark; reconnection must be jittered or it becomes a thundering herd; and horizontal scale needs pub/sub for fan-out plus sticky sessions for per-connection state. Every production incident in this unit resolves back to those levers.