91 WebSockets Interview Questions and Answers (2026)

WebSocket is a protocol that provides a persistent, full-duplex communication channel over a single TCP connection, letting client and server exchange messages freely once the connection is established. It differs from HTTP's request-response model where the client must always initiate and the server can only reply.

• Connection model: HTTP opens a connection per request-response cycle (though keep-alive reuses TCP); WebSocket keeps one long-lived connection open.

• Communication direction: HTTP is half-duplex and client-initiated; WebSocket is full-duplex, either side can send at any time.

• Handshake: WebSocket starts as an HTTP request with an Upgrade: websocket header, then switches protocols (HTTP 101).

• Overhead: After the handshake, messages are small framed payloads with no repeated HTTP headers, unlike each HTTP request carrying full headers.

• URL scheme: Uses ws:// or wss:// (TLS) instead of http://.

WebSockets shine wherever you need low-latency, server-pushed, or bidirectional updates in real time, so the client doesn't have to poll.

• Chat and messaging: Messages must reach all participants instantly in both directions.

• Live financial data: Stock tickers, crypto prices, and dashboards that stream frequent updates.

• Collaborative editing: Tools like shared docs or whiteboards where edits propagate to all users live.

• Multiplayer gaming: Fast, continuous exchange of player state where latency matters.

• Live notifications and feeds: Server pushes alerts, sports scores, or activity streams without client polling.

• IoT telemetry: Devices continuously stream sensor data and receive control commands.

Full-duplex means both the client and server can send and receive messages simultaneously over the same connection, with no need to wait for the other side to finish. WebSockets provide this natively after the handshake.

• Simultaneous two-way flow: A client can send a message while the server is pushing another message on the same socket.

• Contrast with half-duplex: HTTP is effectively half-duplex: the client asks, then the server answers, one direction at a time.

• Enabled by framing: The protocol splits data into frames over one TCP connection, so independent messages interleave in both directions.

• Practical benefit: No polling and no round-trip waiting: the server pushes the instant it has data.

You choose WebSockets when you need real-time, low-latency, server-initiated communication: the core problem they solve is that plain HTTP can't let the server push data to the client without the client asking first.

• Server push: HTTP requires the client to poll; WebSockets let the server send the moment data is available.

• Low latency: No repeated handshakes or header overhead per message, so updates arrive faster.

• Eliminates polling waste: Traditional workarounds (short polling, long polling) waste bandwidth and CPU on empty or held requests; WebSockets avoid this.

• True bidirectional flow: Both sides exchange messages freely, which request-response can't model cleanly.

• When NOT to use them: If data is fetched occasionally on demand, REST is simpler; consider SSE if you only need one-way server push.

A persistent connection means the WebSocket stays open after the initial handshake and is reused for all subsequent messages, rather than opening and closing a connection per exchange like classic HTTP.

• Established once: After the HTTP Upgrade handshake, one TCP connection remains open for the session's lifetime.

• Lower latency and overhead: Avoids repeated TCP/TLS setup and HTTP headers on every message.

• Enables server push: Because the channel is always open, the server can send data at any time without a new client request.

• Kept alive: Ping/pong control frames detect dead peers and keep intermediaries from closing idle connections.

• Trade-off: Holding many open connections consumes server resources and requires reconnection handling on drops.

These three terms describe complementary properties of a WebSocket channel: it is persistent (stays open), full-duplex (both sides can transmit at the same time), and bidirectional (either side can initiate). Together they make real-time interaction possible.

• Persistent: One connection is opened via the handshake and reused for the whole session, avoiding repeated setup.

• Full-duplex: Data can flow in both directions simultaneously; neither side waits for the other to finish sending.

• Bidirectional: Either the client or the server can initiate a message, unlike HTTP where only the client starts.

• How they relate: Bidirectional is about who can start; full-duplex is about doing it at the same time; persistent is what keeps the channel available for both.

Over HTTP, WebSockets give you a single persistent, low-overhead, full-duplex channel, which translates into faster, more efficient real-time communication.

• Real-time server push: The server sends data instantly instead of waiting for a client request.

• Lower overhead per message: After the handshake, frames are small with no repeated HTTP headers, saving bandwidth.

• Reduced latency: No new connection or handshake per message, so exchanges are quicker.

• Full-duplex: Both sides communicate simultaneously, which HTTP's request-response can't do.

• No polling: Eliminates wasteful short/long polling that consumes resources checking for updates.

• Efficient at scale for streaming: For frequent updates, one open connection is cheaper than many repeated HTTP requests.

WebSockets shine when you need low-latency, bidirectional, real-time communication; skip them when data is infrequent, one-directional, or fits normal request/response.

• Good use cases:

  • Chat and messaging apps (both sides send continuously).

  • Live dashboards, stock tickers, sports scores.

  • Multiplayer games and collaborative editing (frequent, low-latency updates).

  • Live notifications and presence indicators.

• When not to use them:

  • Simple request/response CRUD: plain HTTP/REST is simpler and cacheable.

  • Only server-to-client updates: Server-Sent Events (SSE) are lighter and auto-reconnect.

  • Infrequent updates: polling avoids holding open connections.

  • Large file transfers or heavy static content: better served by HTTP with CDNs/caching.

• Rule of thumb: reach for WebSockets only when you genuinely need persistent, two-way, real-time flow.

WebSockets give real-time, full-duplex, low-overhead communication, but at the cost of connection state, scaling complexity, and weaker infrastructure support than plain HTTP.

• Advantages:

  • Full-duplex: client and server both push whenever they want.

  • Low latency and low overhead: no repeated handshakes or headers after the initial upgrade.

  • Efficient for high-frequency messaging (games, live feeds).

• Disadvantages:

  • Stateful: each open connection consumes server resources, complicating horizontal scaling.

  • No built-in reconnection, caching, or request semantics (you build these yourself).

  • Proxies, firewalls, and load balancers may not handle long-lived connections well.

  • More complex to secure and debug than stateless HTTP.

HTTP polling repeatedly opens new stateless requests to check for data, while WebSockets keep one persistent connection where the server pushes data instantly.

• Connection model: Polling: a new short-lived request/response per check; WebSockets: one long-lived full-duplex connection.

• Latency: Polling adds delay equal to the poll interval; WebSockets deliver as soon as data exists.

• Overhead: Polling resends full HTTP headers each request, often returning empty responses; WebSocket frames are tiny.

• Direction: Polling is client-initiated only; WebSockets let the server push unprompted.

• Trade-off: Polling is simple and stateless (easy to scale/cache); WebSockets are efficient but stateful and harder to scale.

WebSockets carry two payload data types: UTF-8 text and arbitrary binary, distinguished purely by the frame's opcode so the receiver knows how to interpret the bytes.

• Text frames (opcode 0x1):

  • Payload must be valid UTF-8; a receiver must fail the connection on invalid encoding.

  • In browsers arrive as a string from onmessage.

• Binary frames (opcode 0x2):

  • Raw bytes with no encoding constraints: images, protobuf, MessagePack, etc.

  • In browsers arrive as Blob or ArrayBuffer per ws.binaryType.

• How they're handled:

  • The opcode alone tags the type; the protocol adds no further schema, so application-level formats are your responsibility.

  • Both types share the same framing, masking, and fragmentation rules.

A frame is the smallest unit of the WebSocket wire protocol; a message is the complete application-level chunk of data, which may be split across one or more frames.

• Frame:

  • A protocol-level packet with a header (opcode, FIN bit, mask, payload length) plus payload.

  • The opcode marks it as text, binary, continuation, or a control frame (close, ping, pong).

• Message:

  • The logical unit an app cares about (a full text string or binary blob).

  • Can be one frame or fragmented into a first frame + continuation frames.

• The FIN bit ties them together: FIN=1 means this frame completes the message; FIN=0 means more continuation frames follow.

• Why fragmentation exists: Lets a sender stream data of unknown total length without buffering the whole message first.

• Practical note: browser APIs hide framing and deliver whole messages to onmessage.

The browser WebSocket API is a small event-driven object: you construct a WebSocket with a URL, listen for lifecycle events, and use send() and close() to communicate.

• Construction: new WebSocket(url, protocols) opens the connection; optional subprotocols negotiate an app protocol.

• ws:// vs wss://: ws:// is plaintext; wss:// is TLS-encrypted (required from HTTPS pages).

• readyState: Numeric connection state: CONNECTING, OPEN, CLOSING, CLOSED.

• Events: onopen (handshake done), onmessage (data received), onclose (connection ended), onerror (failure).

• Sending and closing: send() transmits text or binary; close(code, reason) starts a graceful close.

• binaryType: Controls whether received binary arrives as a Blob or ArrayBuffer.

The WebSocket object exposes four event handlers covering its lifecycle: onopen, onmessage, onclose, and onerror.

• onopen: Fires once the handshake succeeds and readyState becomes OPEN; safe to start sending here.

• onmessage: Fires for each received message; the data is in event.data (string or binary).

• onclose: Fires when the connection closes; the event has code, reason, and wasClean.

• onerror: Fires on failure (and is typically followed by onclose); the event carries little detail for security reasons.

• You can also use addEventListener for the same events to attach multiple handlers.

readyState is a read-only number reporting the connection's lifecycle stage, with four constants defined on the WebSocket object.

1. CONNECTING (0): handshake in progress, not yet open.

2. OPEN (1): connection established, data can flow.

3. CLOSING (2): close handshake started, not yet finished.

4. CLOSED (3): connection closed or failed to open.

Practical use: check ws.readyState === WebSocket.OPEN before calling send() to avoid throwing on a not-yet-open or closed socket.

Handle errors by listening to onerror and, crucially, onclose (which carries the real reason via close codes), then implement guarded sends and reconnection logic since the API gives few error details.

• Listen to both onerror and onclose: onerror signals something went wrong but is intentionally vague; onclose gives the code, reason, and wasClean.

• Inspect close codes: 1000 is normal; 1006 means abnormal closure (no clean handshake, often a network drop).

• Guard your sends: Check readyState === WebSocket.OPEN before send() to avoid exceptions.

• Reconnect with backoff: On unexpected close, reconnect using exponential backoff (with jitter) rather than a tight retry loop.

• Application-level resilience: Use heartbeats/timeouts to detect dead connections, and re-authenticate or resync state after reconnecting.

Plain ws:// is unencrypted, so anyone on the network path can read and modify traffic; wss:// wraps the connection in TLS, giving confidentiality, integrity, and server authentication just like HTTPS.

• Confidentiality: Messages and any tokens/cookies in the handshake are encrypted, so they can't be sniffed on shared Wi-Fi or by intermediaries.

• Integrity: TLS prevents man-in-the-middle tampering with frames in flight.

• Proxy and firewall compatibility: Many proxies mangle or block plaintext ws:// upgrades; wss:// on port 443 tunnels through them reliably.

• Mixed-content rule: An HTTPS page is not allowed to open an insecure ws:// connection: browsers block it, so wss:// is effectively mandatory.

For debugging you inspect frames directly: the browser DevTools Network tab shows live frames for a connection, and CLI clients like wscat or websocat let you connect, send, and receive by hand, while packet tools help when you need the wire level.

• Browser DevTools:

  • Network tab: select the request with type WS, open the Messages (frames) view to see each frame, direction (up/down arrows), size, and timestamp.

  • Confirm the handshake: check the 101 Switching Protocols response and Upgrade/Sec-WebSocket-Accept headers.

• CLI clients:

  • wscat -c wss://host/path opens an interactive session to send/receive messages without a frontend.

  • websocat is a more powerful alternative (piping, binary, subprotocols) for scripted testing.

• Wire-level and proxy tools:

  • Wireshark decodes WebSocket frames and opcodes; useful for masking, fragmentation, and close-code issues (harder over TLS without keys).

  • An intercepting proxy (mitmproxy, Charles) can view and even rewrite frames to reproduce edge cases.

• Techniques:

  • Reproduce with a minimal client to isolate app logic from browser/proxy behavior.

  • Watch ping/pong and close codes to distinguish idle-timeout drops from application errors.

WebSockets add real-time power but bring costs in resource usage, infrastructure, and complexity that make them the wrong choice for simple request-response needs.

• Stateful, resource-heavy connections: Each open socket consumes server memory and a connection slot, limiting how many clients one server holds.

• Scaling is harder: Persistent connections complicate load balancing and horizontal scaling; you often need sticky sessions or a pub/sub layer (e.g. Redis) to share state.

• No built-in reconnection or delivery guarantees: Dropped connections must be detected and re-established manually; you build your own retry and message-recovery logic.

• Proxy and firewall issues: Some intermediaries don't handle the Upgrade or long-lived connections well; use wss:// to improve compatibility.

• Weaker native HTTP features: Caching, standard status codes, and simple stateless semantics don't apply as they do with REST.

• Overkill for infrequent updates: For rare data changes, polling or SSE may be simpler and cheaper.

A WebSocket keeps one TCP connection open for the life of the session, so both sides exchange messages freely without repeating the setup cost of a new HTTP request each time.

• No repeated handshakes: Each HTTP request may pay for TCP setup and (over TLS) a new handshake; a WebSocket does this once, then reuses the pipe.

• No repeated headers: HTTP resends full headers and cookies every request; WebSocket frames carry only a tiny 2-14 byte header, cutting per-message overhead.

• Bidirectional and stateful: The server can push at any time without the client asking, unlike request/response where the server only speaks when polled.

• Lower latency: Data travels immediately over the already-open connection instead of waiting for the next request cycle.

• Cost: a persistent connection consumes server memory/sockets per client, so you trade per-message efficiency for holding many long-lived connections.

WebSockets cut latency and overhead by establishing the connection once, then sending lightweight frames over that open channel instead of rebuilding an HTTP request each time.

• One-time handshake: An HTTP Upgrade request switches the connection to the WebSocket protocol once; after that there's no per-message setup.

• Minimal framing: Each message carries a small frame header (as few as 2 bytes) versus hundreds of bytes of HTTP headers and cookies per request.

• Server push: The server sends data the instant it's ready, eliminating the poll interval delay of request/response.

• Persistent connection: Reusing one TCP (and TLS) session avoids repeated connection and handshake round-trips.

All four deliver real-time-ish data, but they differ in direction, efficiency, and complexity: short polling repeatedly asks, long polling holds a request open, SSE streams server-to-client, and WebSockets give full bidirectional streaming.

• Short polling:

  • Client requests on a fixed interval; simplest, but wasteful and high-latency (data waits for the next poll).

  • Choose for: infrequent updates where simplicity wins.

• Long polling:

  • Server holds the request open until data is ready, then the client reconnects; near-real-time over plain HTTP but heavy on connection churn.

  • Choose for: real-time-ish needs where WebSockets/SSE aren't supported.

• Server-Sent Events (SSE):

  • One-way server-to-client stream over HTTP with automatic reconnection; lightweight but text-only and unidirectional.

  • Choose for: live feeds, notifications, dashboards (server pushes, client just listens).

• WebSockets:

  • Full-duplex, low-latency, low-overhead after handshake; most complex to scale.

  • Choose for: chat, games, collaboration (frequent two-way messaging).

• Trade-off summary: efficiency and capability rise from short polling to WebSockets, but so does implementation and infrastructure complexity.

SSE is a lightweight one-way server-to-client stream over HTTP, while WebSockets are a full-duplex protocol: choose SSE when only the server pushes, WebSockets when both sides talk.

• Direction: SSE is unidirectional (server to client only); WebSockets are bidirectional.

• Protocol and transport: SSE runs over plain HTTP with the EventSource API and reconnects automatically; WebSockets use their own ws:///wss:// protocol after an upgrade.

• Data format: SSE is text/UTF-8 only; WebSockets carry text and binary.

• Simplicity and infrastructure: SSE is simpler, works with existing HTTP infrastructure, and has built-in retry; WebSockets need more setup and proxy/LB awareness.

• Choose SSE for: notifications, live feeds, dashboards (server push only).

• Choose WebSockets for: chat, games, collaborative editing (two-way, low-latency).

For one-way server-to-client updates, use SSE; for two-way client-server communication, use WebSockets. Long polling is a fallback when neither is supported.

• Unidirectional (server to client): SSE:

  • Lightweight, runs over HTTP, auto-reconnects, and matches the pattern where the client only listens (feeds, notifications, live scores).

  • No need to pay for the complexity of a full-duplex protocol.

• Bidirectional (client and server): WebSockets:

  • Full-duplex, low-latency channel where both sides send freely (chat, games, collaboration).

  • Worth the added scaling and setup cost when interactivity is core.

• Fallback: Long Polling: Use when clients or proxies block SSE/WebSockets; approximates real-time over plain HTTP at higher connection overhead.

They solve different problems: a WebSocket is a long-lived, bidirectional connection between a client and server, while a webhook is a one-off HTTP POST one server sends to another server's public URL when an event occurs.

• Connection lifetime:

  • WebSocket: persistent connection kept open for continuous two-way traffic.

  • Webhook: no persistent connection, just a fresh HTTP request per event.

• Direction and roles:

  • WebSocket: typically client (often a browser) to server, both can send.

  • Webhook: server-to-server; the receiver must expose a reachable endpoint.

• Delivery model:

  • WebSocket: push over an established socket, low latency.

  • Webhook: stateless callback, usually with retries and a signature (e.g. HMAC) for verification.

• When to use:

  • WebSocket: live UI updates and interactive sessions.

  • Webhook: integrations between backends (payment succeeded, CI finished) where a public endpoint receives events.

For pure server-to-client streaming, Server-Sent Events (SSE) are simpler and cheaper: they run over ordinary HTTP, and the browser's EventSource gives you automatic reconnection and event IDs for free, which WebSockets make you build yourself.

• Built-in reconnection:

  • EventSource reconnects automatically after a drop; WebSockets require your own reconnect/backoff logic.

  • SSE resumes with the Last-Event-ID header so the server can replay missed messages.

• Simplicity over plain HTTP:

  • No protocol upgrade; it's just a text/event-stream response, so proxies, load balancers, and auth work as usual.

  • Automatic UTF-8 text framing, no manual heartbeat framing needed.

• Right fit for one-way feeds: Ideal for notifications, live scores, stock tickers, log tails.

• Limitations to defend: Text only (binary must be encoded), no client-to-server channel, and HTTP/1.1 caps connections per domain (~6), though HTTP/2 multiplexing eases this.

WebSockets carry far less per-message overhead than traditional HTTP: HTTP re-sends full headers on every request, while a WebSocket pays the header cost once at the handshake and then sends tiny frames.

• Traditional HTTP / polling:

  • Every message is a full request plus response, with headers, cookies, and user-agent often totaling hundreds of bytes to kilobytes.

  • New connections may repeat TCP and TLS handshakes, adding latency and overhead.

• WebSockets:

  • One HTTP Upgrade handshake, then a persistent connection.

  • Each frame adds only a small header (~2 to 14 bytes), so small frequent messages are dramatically cheaper.

• Latency angle: No per-message connection setup means lower and more consistent latency for real-time flows.

• Caveat: For rare, infrequent requests plain HTTP is simpler and the overhead difference is negligible; WebSockets win when message frequency is high.

WebSocket is a client-to-server TCP protocol usually relayed through your server; WebRTC is a peer-to-peer protocol (mainly over UDP) built for low-latency media and data directly between clients. Use WebSockets for reliable server-mediated messaging, WebRTC for real-time audio/video or direct peer data.

• Topology:

  • WebSocket: client to server, so your server sees and can persist all traffic.

  • WebRTC: peer-to-peer after signaling; media flows directly between clients (via STUN/TURN for NAT traversal).

• Transport and reliability:

  • WebSocket: TCP, always reliable and ordered.

  • WebRTC: typically UDP, can be unreliable/unordered for minimal latency (ideal for live media).

• Complexity:

  • WebSocket: simple to set up.

  • WebRTC: complex, needs a signaling channel (often a WebSocket) plus STUN/TURN servers.

• When to choose which:

  • WebSocket: chat, notifications, dashboards, any server-authoritative messaging.

  • WebRTC: video/voice calls, screen sharing, and low-latency peer data; note WebRTC often uses a WebSocket for its signaling handshake.

The handshake is an HTTP GET request that asks the server to switch protocols; if the server agrees it replies 101 Switching Protocols and the same TCP connection is then used for the WebSocket framing protocol.

• Client sends an upgrade request:

  • An HTTP/1.1 GET with Connection: Upgrade and Upgrade: websocket signalling it wants to leave HTTP.

  • Includes Sec-WebSocket-Key: a random 16-byte base64 nonce.

• Roles of the two hop-by-hop headers:

  • Connection: Upgrade tells intermediaries this connection is being upgraded.

  • Upgrade: websocket names the target protocol.

• Server proves it understood:

  • It echoes Sec-WebSocket-Accept, computed from the client key plus a fixed GUID, so a plain HTTP cache/proxy can't accidentally accept.

  • Responds 101 Switching Protocols, after which no more HTTP semantics apply.

• After 101 the socket carries WebSocket frames in both directions on the same connection.

Sec-WebSocket-Protocol lets client and server agree on an application-level subprotocol (the message format/semantics) layered on top of raw WebSocket frames.

• Client offers a preference list: Sends Sec-WebSocket-Protocol: v2.chat, v1.chat in priority order (in browsers, the second WebSocket constructor argument).

• Server picks exactly one:

  • Echoes a single chosen value back in its 101 response, or omits the header to select none.

  • The client must check ws.protocol and, if it can't speak what the server chose, close the connection.

• Purpose:

  • Names a contract (e.g. wamp, mqtt, STOMP) so both sides know how to interpret frames.

  • Enables versioning and graceful evolution of the message protocol.

They are a handshake confirmation, not security: Sec-WebSocket-Key is a random client nonce and Sec-WebSocket-Accept is the server's derived response proving it is a real WebSocket endpoint and not a cached or confused HTTP responder.

• Sec-WebSocket-Key:

  • A fresh, random 16-byte value base64-encoded, generated per handshake.

  • It is not authentication and grants no secrecy; anyone can read it.

• Sec-WebSocket-Accept:

  • The server transforms the key deterministically and returns it, proving it understood the WebSocket protocol.

  • The client verifies it matches its expectation before treating the connection as open.

• Why it matters: Prevents a non-WebSocket server or intermediary cache from accidentally completing the upgrade.

WebSockets reuse ports 80/443 because the connection begins as an ordinary HTTP request, which lets it traverse existing firewalls, proxies, and TLS infrastructure; after the 101 response the same TCP socket stops speaking HTTP and starts exchanging WebSocket frames.

• Firewall and proxy friendliness:

  • Networks routinely allow 80/443, so no new port needs opening.

  • Using 443 (wss://) wraps everything in TLS, which also helps pass proxies that would otherwise mangle the traffic.

• The transition:

  • The upgrade request and 101 Switching Protocols are the last HTTP messages on that connection.

  • The underlying TCP (or TLS) connection is kept open and reused; only the framing protocol changes.

  • From then on it is full-duplex binary/text frames, not request-response.

The server detects the upgrade headers on an incoming HTTP request, validates them, computes the accept key, and if it agrees switches the connection into WebSocket mode with a 101 response instead of returning a normal HTTP body.

• Detect and validate:

  • Check for Upgrade: websocket, Connection: Upgrade, a valid Sec-WebSocket-Version (13), and a Sec-WebSocket-Key.

  • Apply auth, origin checks, and route matching here; reject with a normal HTTP error if it fails.

• Complete the handshake: Compute Sec-WebSocket-Accept, optionally pick a subprotocol/extensions, and send 101 Switching Protocols.

• Hand off the socket:

  • The raw TCP connection is detached from the HTTP request/response cycle and given to a WebSocket read/write loop.

  • Frameworks abstract this: e.g. FastAPI/Starlette expose await websocket.accept(), which performs the whole handshake for you.

Every WebSocket message is transmitted as one or more frames, and each frame's opcode declares its type: data frames (text, binary) carry application content, while control frames (close, ping, pong) manage the connection.

• Data frames:

  • Text 0x1: UTF-8 application data.

  • Binary 0x2: raw byte application data.

  • Continuation 0x0: subsequent fragments of a text/binary message.

• Control frames:

  • Close 0x8: initiates the closing handshake, optionally with a status code and reason.

  • Ping 0x9: liveness/keepalive check.

  • Pong 0xA: reply to a ping (or unsolicited heartbeat).

• Rules for control frames:

  • Must be 125 bytes or fewer and must not be fragmented (FIN=1).

  • Can be interleaved between fragments of a data message.

You send text by passing a string to send() and binary by passing an ArrayBuffer, typed array, or Blob; on receive, event.data is a string for text frames and a Blob or ArrayBuffer for binary, based on binaryType.

• Sending text: ws.send("some string") produces a text frame.

• Sending binary: Pass an ArrayBuffer, a typed array like Uint8Array, or a Blob; the client sends a binary frame.

• Receiving: Check the type of event.data: strings for text, Blob/ArrayBuffer for binary.

• Control the binary form: Set ws.binaryType = "arraybuffer" if you want direct byte access instead of a Blob.

binaryType is a property on the WebSocket object that decides the JavaScript type used to deliver received binary messages: either "blob" (the default) or "arraybuffer".

• "blob" (default): event.data is a Blob; convenient for file-like handling but requires async reads to get bytes.

• "arraybuffer": event.data is an ArrayBuffer; best for immediate synchronous byte access via typed arrays.

• It only affects receiving: Sending accepts strings, ArrayBuffer, typed arrays, or Blob regardless of this setting.

• Set it before messages arrive: Assign it right after construction so all binary frames use the desired type.

bufferedAmount is a read-only property on a client WebSocket object that reports the number of bytes queued via send() but not yet transmitted to the network. Watching it lets you throttle a producer so you don't outrun a slow consumer or a congested link.

• What it measures:

  • Bytes buffered in the client after send() that the OS/network hasn't flushed yet; it grows if you send faster than the socket drains.

  • It does NOT confirm the peer received the data, only that it left (or is leaving) the local send buffer.

• Why it helps with slow consumers:

  • A steadily rising bufferedAmount signals backpressure: the receiver or link can't keep up.

  • You can pause sending, drop stale frames, or coalesce updates until it falls back toward zero.

• Typical pattern: Before enqueuing more, check the threshold; skip or defer if the buffer is too full.

Detect loss via the close and error events plus an application-level heartbeat, then reconnect with exponential backoff and jitter so many clients don't reconnect in lockstep and overwhelm the server.

• Detection:

  • Listen for onclose and onerror; a code 1006 usually means abnormal/abrupt loss.

  • TCP can go half-open silently, so add heartbeats (ping/pong or app-level messages) with a response timeout.

• Exponential backoff: Delay doubles each attempt (e.g. 1s, 2s, 4s, 8s) up to a cap, avoiding a tight reconnect loop.

• Jitter: Randomize the delay so clients that dropped together don't reconnect simultaneously (the thundering herd).

• After reconnect:

  • Re-authenticate, re-subscribe to channels, and resync missed state (e.g. via a last-seen cursor/sequence id).

  • Reset the backoff counter once a connection is stable.

Ping and pong are built-in WebSocket control frames (opcodes 0x9 and 0xA) used as heartbeats: one side sends a ping, the peer must reply with a matching pong, and missing pongs reveal a dead or half-open connection that TCP alone won't surface.

• How they work:

  • A ping may carry a small payload; the pong must echo that same payload back.

  • Endpoints must respond to a ping with a pong automatically (per RFC 6455), so it's a cheap liveness probe.

• Why they're needed:

  • A half-open connection (peer crashed, cable pulled) can look alive at the TCP layer for a long time; a missed pong detects it fast.

  • They also keep idle connections warm through proxies/load balancers that close silent sockets.

• Typical usage:

  • Server pings every N seconds; if no pong arrives within a timeout, terminate and let the client reconnect.

  • Note: browsers auto-respond to pings but expose no JS API to send them, so browser clients often use application-level heartbeat messages instead.

WebSocket close codes are 4-digit integers sent in the close frame (per RFC 6455) that explain why a connection ended; some are set by endpoints and some are reserved and generated locally by the implementation.

• 1000 Normal Closure: The purpose was fulfilled and the connection closed cleanly.

• 1001 Going Away: Endpoint is disappearing (server shutting down, or browser navigating away).

• 1006 Abnormal Closure: Reserved: set locally when the connection dropped without a proper close frame (network failure). It is never sent on the wire.

• 1011 Internal Error: Server hit an unexpected condition and can't complete the request.

• Other common ones:

  • 1002 protocol error, 1003 unacceptable data type, 1008 policy violation, 1009 message too big.

  • 1005 is also reserved (no status code was actually received).

WebSocket inherits ordering from TCP: a single connection runs over one TCP stream, and TCP guarantees in-order, reliable byte delivery, so frames arrive in the exact order they were sent.

• TCP does the heavy lifting: Sequence numbers reorder packets and retransmit losses, presenting an ordered byte stream to the WebSocket layer.

• Framing preserves message boundaries: WebSocket adds frame headers so the ordered byte stream is reassembled into discrete messages in send order, including multi-frame fragmented messages.

• Caveats:

  • Ordering holds only within one connection; across two separate WebSocket connections there is no ordering guarantee.

  • It's head-of-line blocking: a lost packet delays everything behind it until retransmission.

  • On reconnect the guarantee resets, so messages can be lost or duplicated unless you add your own sequencing.

Good WebSocket practice centers on securing the connection, keeping it alive, bounding resources, and designing for reconnection since the transport is inherently flaky.

• Security:

  • Always use wss:// (TLS) and validate the Origin header to prevent CSWSH.

  • Authenticate at the handshake and authorize each incoming message.

• Liveness: Send periodic ping/pong heartbeats to detect dead peers and defeat idle timeouts.

• Resource control:

  • Limit connections per user/IP, cap message size, and rate-limit inbound messages.

  • Apply backpressure and drop or slow-consume when a client can't keep up.

• Reliability & lifecycle:

  • Client-side auto-reconnect with exponential backoff and jitter.

  • Clean up server resources on disconnect; close with proper status codes.

  • Use a shared backplane (Redis pub/sub, etc.) to broadcast across multiple server instances.

A graceful close is a two-way handshake: one side sends a Close frame (opcode 0x8) with a status code, the peer replies with its own Close frame, and only then is the TCP connection torn down. This lets both sides finish cleanly and agree on why the connection ended.

• The exchange:

  • Initiator sends a Close frame with a status code and optional UTF-8 reason.

  • Peer responds with its own Close frame (echoing/choosing a code) and stops sending data messages.

  • After both frames, the underlying TCP connection is closed; the server typically closes TCP.

• Common status codes:

  • 1000: normal closure.

  • 1001: going away (server shutdown, page navigation).

  • 1006: abnormal, no Close frame received (never sent on the wire, TCP just dropped).

• Why it matters:

  • Distinguishes intentional close from network failure, so clients know whether to reconnect.

  • Allows in-flight messages to drain before the socket goes away.

Idle timeouts on proxies, load balancers, and servers close connections that send no traffic for some window, silently killing long-lived WebSockets. You keep them alive by generating periodic traffic (heartbeats) so the connection never appears idle.

• Where timeouts come from:

  • Reverse proxies / load balancers (e.g. nginx, ALB) drop idle connections after a configured period.

  • Intermediary NAT/firewall state tables also expire idle flows.

• Keeping connections alive:

  • Protocol-level ping/pong frames (opcodes 0x9/0xA) sent at an interval shorter than the shortest timeout.

  • Pong replies are automatic in most stacks, so a periodic ping is usually enough.

  • Application-level heartbeat messages also work if you can't send control frames.

• Tuning:

  • Set heartbeat interval below every hop's idle timeout (e.g. ping every 30s if the LB idles at 60s).

  • Use missed pongs as a liveness signal to trigger reconnect.

  • Balance frequency: too frequent wastes bandwidth/battery, too rare risks disconnects.

The Origin header, sent automatically by browsers on the handshake, tells the server which site initiated the connection: it's the primary defense against cross-site WebSocket hijacking, since WebSockets are not restricted by the same-origin policy or CORS the way XHR/fetch are.

• Why it matters: The handshake carries cookies automatically, so without an Origin check a malicious page could open an authenticated socket on the victim's behalf (cross-site WebSocket hijacking).

• How to use it: Validate Origin against an allowlist of trusted origins during the handshake and reject mismatches.

• Limitations: Browsers set it honestly, but non-browser clients (curl, scripts) can forge or omit it: treat it as one layer, not a substitute for real authentication and tokens.

Every WebSocket frame is untrusted input, and unlike a request/response the connection is persistent and often broadcast to others, so unvalidated data can trigger injection, corruption, or crashes: validate structure, types, size, and authorization on each message.

• Injection risks: Payloads may flow into SQL, shell commands, or (when broadcast and rendered) into other users' browsers as XSS; escape/parameterize at every sink.

• Malformed or hostile payloads: Bad JSON, unexpected types, or huge/deeply-nested objects can crash handlers or exhaust CPU/memory; validate against a schema and reject early.

• Trusting client-declared identity: Never accept a client-sent user ID, role, or room permission: derive identity and authorization from the authenticated session server-side.

• Broadcast amplification: One malicious message can reach many recipients, so sanitize before fan-out to avoid poisoning every subscriber.

• Practice: Treat frames like any external input: validate type and size, enforce an allowlist of message types, and fail closed on anything unexpected.

A maximum message/frame size caps how much a single client can force the server to buffer and process, preventing a cheap request from consuming disproportionate memory and CPU: it's a core resource-exhaustion defense.

• Bounded memory: Without a limit, a client can send (or fragment across frames) a huge message that the server must buffer entirely before handling, exhausting RAM: one connection can OOM the process.

• Fragmentation abuse: WebSocket messages can span many continuation frames; enforce a limit on total reassembled size, not just per-frame, so many small frames can't add up to an unbounded message.

• CPU protection: Large payloads cost more to parse, decompress, or validate; a cap bounds worst-case per-message work.

• Enforcement: Most servers expose a max-size setting and close the connection (code 1009, message too big) when exceeded; combine with rate limits for full coverage.

Rooms, channels, and topics are logical groupings of connections that let you address many clients at once: you publish to the group name instead of tracking individual sockets, giving you fan-out (one message, many recipients).

• They're a subscription abstraction:

  • A client joins/subscribes to a named group; the server maintains a mapping of group name to member connections.

  • Sending to the group iterates its members, so app code never manages socket lists directly.

• They enable fan-out: One publish event reaches all subscribers (a chat room, a live scoreboard, a document's collaborators).

• Across multiple servers:

  • Room membership is split across nodes, so a backplane like Redis Pub/Sub or Kafka relays the message to every server holding a member.

  • This maps naturally onto Pub/Sub topics: the room name is the topic.

• Naming/scoping: Terminology differs (Socket.IO "rooms", Phoenix "channels", MQTT "topics") but the model is the same: named groups you broadcast to.

Plain WebSockets give you only a raw bidirectional byte stream; libraries like Socket.IO layer on the production concerns you'd otherwise build yourself: reconnection, heartbeats, transport fallback, message framing, and multiplexing.

• Automatic reconnection: Detects dropped connections and retries with exponential backoff and jitter, restoring session state.

• Heartbeats (ping/pong): Periodic keep-alive detects dead connections that TCP hasn't noticed and keeps idle connections through proxies.

• Transport fallback: Falls back to HTTP long-polling when raw WebSockets are blocked (see the fallback question).

• Message semantics: Named events with callbacks/acknowledgements, automatic JSON serialization, and optional binary support: richer than raw frames.

• Rooms and namespaces: Built-in fan-out groups and logical channel multiplexing over one connection.

• Trade-off: Socket.IO uses its own protocol, so both client and server must speak it; it isn't interoperable with plain WebSocket clients.

Socket.IO falls back to HTTP long-polling because some networks (old proxies, corporate firewalls, misbehaving intermediaries) block or break WebSocket upgrades, and long-polling works over ordinary HTTP that virtually every network allows.

• WebSockets aren't universally reachable: The Upgrade handshake can be stripped or refused by intermediaries, or timed out entirely.

• Long-polling is a lowest-common-denominator transport: The client makes an HTTP request that the server holds open until data is available, then immediately reopens it, simulating a push channel over plain HTTP.

• Connect first, upgrade later: Socket.IO (via Engine.IO) typically establishes long-polling first for reliability, then transparently upgrades to WebSockets if the environment supports it.

• Trade-off: Long-polling has higher latency and overhead (repeated HTTP requests/headers), so it's a graceful degradation, not the preferred mode.

WebSockets carry either UTF-8 text frames (usually JSON) or binary frames; text/JSON is human-readable and easy to debug, while binary formats like Protobuf and MessagePack are smaller and faster to parse, trading readability for efficiency.

• Text/JSON:

  • Pros: human-readable, ubiquitous tooling, trivial to debug and log, no schema required.

  • Cons: verbose (field names repeated), slower to parse, larger on the wire.

• Binary payloads:

  • Pros: compact, fast to encode/decode, ideal for high-frequency or high-volume streams (game state, telemetry, media).

  • Cons: not human-readable, harder to inspect, may need schema management and versioning.

• Serialization formats:

  • JSON: text, schemaless, easiest but largest.

  • MessagePack: binary "JSON-like", schemaless drop-in that shrinks size with minimal code change.

  • Protobuf: schema-defined, smallest and fastest, with strong typing and versioning, but requires shared .proto definitions and codegen.

• Choosing:

  • Prefer JSON for simplicity and low message rates; move to MessagePack/Protobuf when bandwidth, latency, or throughput become bottlenecks.

  • Consider that compression (permessage-deflate) narrows JSON's size disadvantage, so measure before optimizing.

WebSockets give you a raw, bidirectional, persistent byte/message channel in the browser; gRPC gives you a structured, contract-first RPC framework (over HTTP/2) with typed messages and streaming. Choose WebSockets for browser real-time messaging, gRPC for typed service-to-service APIs.

• Protocol and transport:

  • WebSockets: a framing protocol upgraded from HTTP/1.1, carrying arbitrary text or binary you define yourself.

  • gRPC: RPC over HTTP/2 using Protocol Buffers for a strict schema and code generation.

• Communication model:

  • WebSockets: symmetric, unstructured message passing (you invent the message types and semantics).

  • gRPC: method calls with typed request/response, plus unary and streaming (client, server, bidirectional).

• Browser support:

  • WebSockets: first-class in every browser.

  • gRPC: needs gRPC-Web plus a proxy; native gRPC isn't usable directly from browsers.

• Use cases:

  • WebSockets: chat, live dashboards, multiplayer, notifications, anything browser-facing and event-driven.

  • gRPC: internal microservice APIs where a typed contract, performance, and streaming matter.

For frequent, constant updates WebSockets are the most bandwidth-efficient: after one handshake, each message carries only a tiny frame header. SSE is close behind, while long-polling is the worst because every update re-sends full HTTP request and response headers.

• WebSockets: One-time handshake, then frames add only ~2 to 14 bytes of overhead; no per-message headers or cookies.

• SSE: Single open response stream, so messages are lightweight text lines with no repeated headers, though slightly more per-message text framing than WebSocket frames.

• Long-polling:

  • Every update means a new request/response cycle: full headers, cookies, and TLS/connection setup cost repeated many times.

  • Overhead grows with update frequency, making it the least efficient for constant streams.

• Takeaway: The more frequent the updates, the more WebSockets and SSE win by amortizing setup across one long-lived connection.

HTTP/2 streaming (and, historically, server push) is a better fit when you need efficient server-to-client delivery within the normal request/response and multiplexing model, without the operational weight of managing a separate stateful WebSocket protocol.

• When streaming beats WebSockets:

  • Unidirectional server-to-client data (feeds, progress) fits a streamed HTTP/2 response or SSE, which multiplexes over one connection.

  • You want to keep standard HTTP semantics: caching, auth, compression, and existing middleware.

• As a complement: HTTP/2 multiplexing removes the old ~6-connection browser limit that hurt SSE, so SSE over HTTP/2 scales well alongside your APIs.

• About server push specifically: HTTP/2 server push was designed to preemptively send assets (CSS/JS), not app messages, and is now deprecated/removed in major browsers, so don't rely on it for real-time data.

• Stick with WebSockets when: You need genuine low-latency bidirectional traffic (chat, gaming, collaborative editing).

WebTransport is a modern browser API for low-latency client-server communication over HTTP/3 (QUIC). Unlike WebSockets, it offers both reliable ordered streams and unreliable datagrams, and because QUIC has independent streams, it avoids the TCP head-of-line blocking that affects WebSockets.

• Transport foundation: WebTransport runs on HTTP/3 over QUIC (UDP-based); WebSockets run on TCP.

• Head-of-line blocking:

  • On TCP, one lost packet stalls all data behind it, so a single WebSocket connection suffers HOL blocking.

  • QUIC has independent streams: a loss on one stream doesn't block others, eliminating transport-level HOL blocking.

• Reliable vs unreliable delivery:

  • WebSockets are always reliable and ordered.

  • WebTransport offers reliable streams AND unreliable datagrams (fire-and-forget), great for games/media where stale data isn't worth retransmitting.

• Multiplexing: Multiple independent streams over one connection without opening several sockets.

• Maturity caveat: Newer and less universally supported than WebSockets; requires HTTP/3 infrastructure, so WebSockets remain the safe default today.

No: the browser WebSocket API gives you no way to set arbitrary request headers (not even Authorization), so auth/metadata must ride on channels the API does expose.

• Why it's blocked:

  • The WebSocket(url, protocols) constructor only accepts a URL and subprotocols; there is no headers argument by design.

  • This prevents scripts from forging sensitive headers on cross-origin requests.

• Practical alternatives:

  • Query string token: wss://host/ws?token=... (beware it appears in logs).

  • Cookies: sent automatically for same-site connections, good for session auth.

  • Abuse Sec-WebSocket-Protocol to smuggle a token as a subprotocol value.

  • App-level: send an auth message as the first frame after the connection opens.

• Non-browser clients (Node, servers) can set real headers, so this limitation is browser-specific.

Extensions are negotiated with Sec-WebSocket-Extensions: the client offers extensions with optional parameters, and the server confirms the subset (with agreed parameters) it will use.

• Client offer: Lists candidates and parameters, e.g. Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits.

• Server response:

  • Echoes back only the extensions it accepts, possibly tightening parameters (e.g. server_max_window_bits=15), or omits the header to decline all.

  • Both sides must then apply the extension to every frame for the rest of the connection.

• permessage-deflate specifics:

  • Compresses message payloads; parameters tune the LZ77 window size and whether the compression context is reset per message (no_context_takeover).

  • Trade-off: saves bandwidth but costs CPU and memory, and can enable compression-based attacks on sensitive data.

On success the server returns 101 Switching Protocols (a header-only response, no body) whose Sec-WebSocket-Accept is derived by hashing the client's key concatenated with a fixed "magic" GUID, proving the server genuinely speaks WebSocket.

• The 101 response:

  • Repeats Upgrade: websocket and Connection: Upgrade, plus the accept header and any chosen subprotocol/extensions.

  • It has no message body; the connection immediately becomes a WebSocket.

• Computing the accept value:

  1. Take the client's Sec-WebSocket-Key string as-is.

  2. Append the magic GUID 258EAFA5-E914-47DA-95CA-C5AB0DC85B11.

  3. Take the SHA-1 of that string.

  4. Base64-encode the digest: that is Sec-WebSocket-Accept.

• Why the GUID: The fixed, well-known constant makes the response non-trivial to produce by accident, so caches/proxies that don't understand WebSocket won't spuriously validate the handshake.

The Sec-WebSocket-Key/magic-GUID handshake proves that the server genuinely understands the WebSocket protocol, so an intermediary (like a caching proxy) can't be tricked into treating a WebSocket request as a normal cacheable HTTP request/response.

• The mechanism:

  • Client sends a random base64 Sec-WebSocket-Key header (fresh per handshake).

  • Server appends the fixed GUID 258EAFA5-E914-47DA-95CA-C5AB0DC85B11, takes SHA-1, base64-encodes it, and returns it as Sec-WebSocket-Accept.

• Why this defeats cache poisoning:

  • An old/naive proxy might cache a GET response and later replay it to a different client. Because the key is random per request, the correct Sec-WebSocket-Accept cannot be predicted or reused, so a stale cached response won't validate.

  • The client rejects the upgrade unless the accept value exactly matches its computed hash, guaranteeing it's talking to a real WebSocket peer, not a cache.

• Not security, but integrity: The GUID is public, so this is not encryption or authentication: it only confirms protocol awareness and prevents accidental/replayed cached handshakes.

The handshake is an ordinary HTTP GET with an Upgrade header, so it rides an already-established TCP connection that then gets reused for the WebSocket, avoiding a second connection setup and letting TCP's congestion window already be partly warmed.

• Reuses the same socket: The TCP (and TLS) handshake happens once; the 101 Switching Protocols response converts that same connection into a WebSocket, so no new connection is opened.

• Passes through existing HTTP infrastructure: Because it looks like HTTP on port 80/443, it traverses firewalls, proxies, and load balancers that already permit HTTP traffic.

• Warm-up benefit:

  • TCP slow-start has already begun ramping the congestion window during the handshake exchange, so the first real WebSocket frames don't start from a cold window.

  • TLS session is established once, so encrypted frames need no further negotiation.

• Net effect: Lower latency for the persistent channel and no per-message connection cost, unlike repeated HTTP polling.

Yes: RFC 8441 defines WebSockets over HTTP/2 (and the same idea extends to HTTP/3) using the CONNECT method with the :protocol pseudo-header instead of an Upgrade header, which lets a WebSocket run inside a single multiplexed stream.

• Handshake changes:

  • Classic HTTP/1.1 uses GET + Upgrade: websocket + 101.

  • HTTP/2 uses an Extended CONNECT: :method = CONNECT and :protocol = websocket (enabled via the SETTINGS_ENABLE_CONNECT_PROTOCOL setting).

• Multiplexing changes:

  • Over HTTP/1.1 each WebSocket monopolizes its own TCP connection.

  • Over HTTP/2 the WebSocket lives in one stream, so many WebSockets and normal requests share a single connection.

• HTTP/3 (QUIC): Same Extended CONNECT approach, but QUIC's independent streams eliminate TCP head-of-line blocking across multiplexed WebSockets.

• Unchanged: The WebSocket frame protocol itself (opcodes, framing, masking) is identical; only the transport and handshake differ.

Clients must XOR-mask every frame with a random 32-bit key so that an attacker controlling browser JavaScript cannot craft byte sequences that a caching or transparent proxy would misinterpret as a real HTTP request (cache poisoning); servers don't mask because they aren't the untrusted party in that threat model.

• The threat: proxy cache poisoning: Without masking, a malicious page could send WebSocket payload bytes that look like a legit GET request; an intermediary unaware of WebSockets might cache/forward it, poisoning responses for other users.

• How masking prevents it:

  • Each frame carries a fresh random masking key; the payload is XORed with it, so the client cannot control the actual bytes on the wire.

  • This makes it impossible to reliably forge recognizable request bytes through a proxy.

• Why the asymmetry:

  • The danger is untrusted client-side script influencing shared infrastructure; the server is trusted and its responses aren't replayed as new requests, so server-to-client frames are sent unmasked (and masking them would waste CPU).

  • A server MUST reject an unmasked client frame; a client MUST reject a masked server frame.

A WebSocket frame is a compact binary structure: a first byte with the FIN bit and opcode, a second byte with the MASK bit and payload length, then optional extended length, an optional masking key, and finally the payload.

• FIN bit (1 bit): 1 means this is the final fragment of the message; 0 means more fragments follow.

• RSV1-3 (3 bits): Reserved for extensions (e.g. permessage-deflate); zero unless negotiated.

• Opcode (4 bits): Frame type: 0x0 continuation, 0x1 text, 0x2 binary, 0x8 close, 0x9 ping, 0xA pong.

• MASK bit (1 bit): Indicates payload is masked; required for client-to-server frames, so a 4-byte masking key follows.

• Payload length (7 bits, extendable): 0-125 means that exact length; 126 means the next 2 bytes hold the length; 127 means the next 8 bytes hold it.

• Masking key (0 or 4 bytes) and payload: If MASK is set, the payload is XORed byte-by-byte with the 4-byte key.

A single logical message can be split across multiple frames using the FIN bit and continuation opcode, letting a sender stream data without knowing the total size up front.

• How fragments are marked:

  • First fragment carries the real opcode (0x1 text or 0x2 binary) with FIN=0.

  • Middle fragments use opcode 0x0 (continuation) with FIN=0.

  • Final fragment uses continuation 0x0 with FIN=1.

• Ordering and interleaving rules:

  • Data fragments must arrive in order and cannot be interleaved with another data message.

  • Control frames (ping/pong/close) may be injected between fragments, since they must not be fragmented themselves.

• Why fragment:

  • Enables streaming of data of unknown length and bounds buffer usage on both ends.

  • Most libraries reassemble fragments and hand the application one complete message.

WebSocket payload length uses a variable-length field: 7 bits for small payloads, with escape values that extend to 16 or 64 bits for larger ones, so a single frame can carry up to a 64-bit length.

• The 7-bit base field: Values 0-125 encode the payload length directly.

• Value 126: 16-bit extension: The next 2 bytes hold an unsigned length (up to 65,535 bytes).

• Value 127: 64-bit extension: The next 8 bytes hold an unsigned 64-bit length (most significant bit must be 0).

• Multi-byte lengths are big-endian (network byte order).

• Fragmentation complements this: Very large or streaming messages can also be split across frames instead of relying on one huge frame.

Backpressure is managed by observing send-buffer depth and pausing production when it grows, both at the TCP layer (the sliding window) and the application layer (bufferedAmount on the client, stream/drain signals on the server). The goal is to stop enqueuing faster than the peer can consume.

• TCP-level flow control: The receive window naturally slows a fast sender, but frames still pile up in local send buffers above that layer.

• Client side: Check bufferedAmount before send() and defer/drop when it exceeds a threshold.

• Server side:

  • Respect the socket's writable/drain signals (e.g. Node's ws.send callback or stream backpressure) and stop reading upstream while the slow client is behind.

  • Use bounded per-connection queues; when full, apply a policy.

• Overflow policies:

  • Drop stale messages (fine for live telemetry where only the latest value matters).

  • Coalesce/conflate updates into a single latest snapshot.

  • Disconnect a hopelessly lagging client to protect server memory.

You detect dead or half-open connections with active heartbeats and timeouts, because a broken TCP link can appear open indefinitely; once detected you terminate the socket and let reconnection logic take over.

• Why detection is needed: Half-open: one side is gone but the other never got a FIN/RST, so send() succeeds while nothing is received.

• Detection techniques:

  • Ping/pong heartbeats: mark each connection unresponsive if no pong arrives before the next ping cycle.

  • Application-level heartbeats for browsers, which can't send protocol pings from JS.

  • Idle-read timeouts: if no bytes/frames arrive within a window, assume it's dead.

• Handling:

  • Terminate the socket (terminate(), not a graceful close) and free per-connection resources.

  • Client reconnects with backoff and resyncs state.