What is a WebSocket? - Definition & Meaning

What is WebSocket?

WebSocket is a communication protocol (RFC 6455) that establishes a persistent, full-duplex connection between a client and server over a single TCP connection. Unlike HTTP, where each interaction requires a new request-response cycle, WebSocket allows both parties to send messages independently at any time after the initial handshake. This makes it the standard protocol for real-time web applications like chat, live dashboards, collaborative editing, and multiplayer games.

How does WebSocket work technically?

A WebSocket connection begins with an HTTP upgrade handshake: the client sends a GET request with an Upgrade: websocket header, and if the server supports it, it responds with HTTP 101 Switching Protocols. From that point, the TCP connection is reused as a WebSocket channel with minimal framing overhead (as little as 2 bytes per frame for small messages, compared to hundreds of bytes of HTTP headers per request). The protocol defines several frame types: text frames (UTF-8 encoded), binary frames (for images, audio, or custom binary protocols), ping/pong frames (heartbeat mechanism to detect dead connections), and close frames (for graceful shutdown with a status code). WebSocket connections use ws:// on port 80 or wss:// (WebSocket Secure, encrypted with TLS) on port 443. The connection is stateful and long-lived, which has important implications for infrastructure. Load balancers must support sticky sessions or layer-7 WebSocket awareness, since a connection cannot be rerouted mid-stream the way an HTTP request can. Reverse proxies like NGINX and Cloudflare require explicit WebSocket configuration, and idle timeout settings must accommodate long-lived connections with appropriate ping/pong intervals. Scaling WebSocket horizontally across multiple server instances requires a message distribution layer. The most common pattern uses Redis pub/sub or a dedicated message broker (NATS, RabbitMQ) to fan out messages to all servers that have connected clients in a given channel or room. Socket.IO is a widely used library that wraps WebSocket with automatic reconnection, room-based broadcasting, acknowledgments, and fallback to HTTP long polling when WebSocket is unavailable. Supabase Realtime provides a managed WebSocket layer on top of PostgreSQL changes via logical replication. Server-Sent Events (SSE) is a simpler, HTTP-based alternative for unidirectional server-to-client streaming, using a standard HTTP connection with the text/event-stream content type. SSE is sufficient when only the server needs to push data (notifications, live feeds) and the client does not need to send messages back on the same channel. The WebSocket protocol supports extensions negotiated via the Sec-WebSocket-Extensions header, with permessage-deflate being the most common: it compresses each individual frame using zlib deflate, reducing bandwidth consumption by 60 to 80 percent for text-heavy messages. Subprotocols are negotiated via the Sec-WebSocket-Protocol header, allowing structured message formats like STOMP, MQTT over WebSocket, or custom JSON-RPC to be agreed upon before the connection becomes active. Connection multiplexing over HTTP/2 is not possible for WebSocket; each WebSocket connection requires its own TCP socket, though the IETF is working on WebTransport over HTTP/3 that uses QUIC streams to support multiple logical channels over a single connection with lower latency and improved congestion control.

How does MG Software apply WebSocket in practice?

MG Software uses WebSockets in client projects that require instant, bidirectional communication. We implement Supabase Realtime for database-driven live updates (new records, status changes, notifications reflecting database events in real-time) and Socket.IO for more complex scenarios like multi-user collaboration and chat. For horizontal scaling, we distribute messages across server instances via Redis pub/sub. Every WebSocket endpoint includes authentication on the handshake, ping/pong heartbeats tuned to the proxy timeout, and exponential backoff on client reconnection to prevent thundering herd effects after outages. We enable permessage-deflate compression for channels with heavy text traffic to reduce bandwidth, and disable it for binary payloads where the overhead negates the savings. In our monitoring dashboards, we track the number of active connections per server, message volume per channel, and average end-to-end latency, allowing us to spot capacity issues early and scale horizontally when configured thresholds are reached.

Why does WebSocket matter?

For any application where users expect instant feedback, such as chat, live collaboration, dashboards, or notifications, the choice between WebSocket and traditional HTTP polling determines whether the experience feels immediate or sluggish. WebSocket eliminates the latency inherent in polling intervals and the wasted bandwidth of repeatedly asking for updates when nothing has changed. For businesses, this translates to more engaging user experiences and lower infrastructure costs for real-time features. Users who receive instant feedback spend more time in the application and convert faster, measurably contributing to retention and revenue. Compared to polling, which at scale can generate millions of unnecessary HTTP requests per hour across thousands of clients, WebSocket keeps server utilization low because idle connections consume negligible resources.

Common mistakes with WebSocket

Leaving connections open without ping/pong heartbeats, causing proxies with idle timeouts to silently drop them. Reconnecting immediately without backoff after a disconnection, creating a thundering herd that overwhelms the server when hundreds of clients reconnect simultaneously. Using WebSockets for simple request-response interactions where standard HTTP would be simpler and more cacheable. Forgetting to authenticate the WebSocket handshake, allowing unauthorized users to subscribe to private channels. Scaling horizontally without a message distribution layer (Redis pub/sub), so messages only reach clients connected to the same server instance. Incoming messages are not validated for format and size on the server side, allowing a malicious client to send extremely large frames that exhaust server memory. State reconciliation after reconnection is missing, so the client displays an incomplete view of the data after connection loss without the user realizing it.

What are some examples of WebSocket?

• A customer service platform with live chat where messages are exchanged in real-time between customer and agent via WebSocket, with typing indicators and read receipts updating instantly.
• A financial dashboard streaming live stock prices, order book changes, and portfolio values via WebSocket so traders always see current market data without refreshing.
• A collaborative document editor synchronizing cursor positions, text changes, and selection highlights from multiple simultaneous users in real-time via WebSocket with conflict resolution.
• A logistics tracking dashboard where dispatchers see vehicle positions updating on a map every second via WebSocket, with automatic reconnection and state reconciliation if the connection drops.
• A SaaS application using Supabase Realtime to push database change events to connected clients, so a shared project board updates instantly when any team member creates, moves, or completes a task.

Related terms