WebSocket is ideal for high-frequency updates. HTTP polling at 100ms would create enormous overhead - 10 requests/second with full HTTP headers. WebSocket's persistent connection handles rapid updates efficiently.

Code 1006 means 'Abnormal Closure' - the connection was lost without a proper close handshake. This usually indicates network issues, server crash, or timeout. Implement reconnection logic for this case.

Each server only knows its own connections. Redis pub/sub creates a message bus - when Server 1 receives a message, it publishes to Redis, and Server 2 receives it to broadcast to its clients.

WebSocket connections are stateful. If your load balancer sends reconnection attempts to different servers, you lose the connection state. Sticky sessions route the same client to the same server.

onopen fires when the WebSocket handshake completes successfully. Only after onopen can you safely send messages. onmessage fires when data arrives, onclose when connection ends.

HTTP requests include full headers (~800 bytes) every time. WebSocket frames have just 2-14 byte headers. For frequent small messages, this overhead difference is massive.

Ping/pong frames detect dead connections. Server sends ping, client auto-responds with pong. If no pong received within timeout, the connection is dead and should be terminated.

WebSocket sends strings or binary data - it doesn't know about JSON. You must stringify before sending and parse after receiving: ws.send(JSON.stringify(data)) and JSON.parse(event.data).

There's no built-in room broadcast. You get the Set of clients in that room (rooms.get('sports')), iterate through them, check each is OPEN, and send. It's manual but gives you full control.

Redis pub/sub has a quirk: once a connection enters subscribe mode, it can only receive messages and issue subscribe commands. You need a separate connection to publish messages.

URL parameters appear in access logs, browser history, and referrer headers. Better to authenticate via a message after connection, or use short-lived tokens that are immediately invalidated.

101 Switching Protocols is the server's response accepting the upgrade from HTTP to WebSocket. After this, the connection is no longer HTTP - it's a persistent WebSocket connection.

WebSocket uses TCP, which guarantees delivery and order. If a packet is lost, TCP waits for retransmission. For ultra-low-latency games, some use WebRTC (UDP-based) for state updates where occasional packet loss is acceptable.

Exponential backoff (1s, 2s, 4s, 8s... up to max 30s) prevents overwhelming the server. Immediate retries can create retry storms. Fixed delays don't adapt to server recovery time.

Node.js is single-threaded. If your message handlers do CPU-intensive work or synchronous I/O, the event loop blocks and can't process other messages. Check for sync operations and move heavy work to worker threads.