WebSockets vs WebRTC

Analogy categoryAnalogies

WebSockets vs WebRTC: Choosing the Right Real-Time Protocol

WebSockets and WebRTC both enable real-time communication in browsers, but they solve different problems. WebSockets give you a persistent, ordered, client-server TCP connection ideal for pushing structured events like chat messages, stock ticks, or game state updates through a single server. WebRTC is built for peer-to-peer media and data exchange, letting two browsers exchange audio, video, or arbitrary data directly, using a server only to help the peers discover and connect to each other.

🏏

Cricket analogy: A WebSocket is like a stump microphone feeding audio to one broadcast van (the server), which then relays commentary to every viewer, while WebRTC is like two players signalling directly to each other across the pitch without going through the commentary box.

How WebSockets Work

A WebSocket connection begins as a standard HTTP request carrying an Upgrade: websocket header; if the server agrees, the TCP connection is repurposed into a full-duplex WebSocket channel identified by the ws:// or wss:// scheme. After the handshake, both sides can send framed messages at any time without re-establishing headers or connections, and the server is always in the loop, either broadcasting to many clients or routing between them.

🏏

Cricket analogy: The WebSocket handshake is like a DRS review request: a formal ask ('Upgrade please') that gets a formal acknowledgment from the third umpire before the new protocol (ball-tracking feed) takes over the broadcast.

How WebRTC Works

WebRTC establishes a direct peer-to-peer connection using ICE (Interactive Connectivity Establishment) to find a viable network path, often via STUN servers to discover public IP addresses and TURN servers to relay traffic when direct connections are blocked by NATs or firewalls. Signaling — exchanging SDP offers/answers and ICE candidates — is not standardized by WebRTC itself, so applications commonly use a WebSocket or another out-of-band channel just to bootstrap the peer connection before data flows directly between browsers.

🏏

Cricket analogy: ICE negotiation is like two teams' captains exchanging playing conditions before a day-night match: they try the floodlit ground directly (P2P), but if visibility (NAT) is an issue, they fall back to a neutral venue (TURN relay) to still get the game played.

Key Differences at a Glance

text

WebSocket                          WebRTC
----------------------------------------------------------------
Transport: TCP (via HTTP upgrade)   Transport: UDP (SRTP/SCTP over DTLS), TCP fallback
Topology:  client <-> server        Topology: peer <-> peer (mesh or SFU for groups)
Use case:  chat, notifications,     Use case: audio/video calls, low-latency
           dashboards, feeds        game state, file sharing
Setup:     one HTTP handshake       ICE negotiation + STUN/TURN + SDP exchange
Ordering:  guaranteed, in-order     media unordered/unreliable by default,
           delivery                 DataChannel configurable per use case
NAT traversal: handled by normal    requires STUN/TURN infrastructure
           HTTP infra

Many production apps use both together: a WebSocket server handles signaling (exchanging SDP offers/answers and ICE candidates) to bootstrap a WebRTC peer connection, then the actual audio/video/data flows directly between browsers over WebRTC, keeping the signaling server's bandwidth cost low.

Don't assume WebRTC is always peer-to-peer in practice. In group calls with more than a handful of participants, a full mesh of peer connections doesn't scale, so most production apps route media through a Selective Forwarding Unit (SFU) server, which behaves more like a WebSocket's server-mediated model but for media streams.

WebSockets provide a persistent, ordered client-server TCP channel; WebRTC provides peer-to-peer audio/video/data with UDP-based transport by default.
Choose WebSockets for chat, live dashboards, notifications, and game state relayed through a server.
Choose WebRTC for video/audio calls, screen sharing, and low-latency peer data where you want to avoid routing media through your own server.
WebRTC needs STUN servers to discover public IPs and TURN servers to relay traffic when direct P2P connections are blocked by NAT/firewalls.
WebRTC does not define a signaling protocol; a WebSocket is commonly used to exchange the SDP offer/answer and ICE candidates needed to start a WebRTC session.
Group WebRTC calls typically use an SFU rather than a full mesh, because peer connections don't scale linearly with participants.
WebSockets guarantee ordered, reliable delivery; WebRTC media is often unordered and lossy by design for lower latency, while its DataChannel can be configured to be reliable if needed.