WebRTC vs WebSockets

Problem Compare WebRTC and WebSockets - what are the pros and cons of each, and when would you choose one over the other?

Be ready to discuss

• WebSockets: a persistent, full-duplex connection over a single TCP socket, established by an HTTP Upgrade handshake.
• The WebSocket topology: everything is client-server, so all traffic traverses your server - simple to reason about, secure, and easy to authenticate, but server bandwidth and fan-out scale with users.
• WebSocket strengths: trivial to deploy, passes through firewalls and proxies on ports 80/443, and ideal for chat, notifications, live dashboards, and collaborative editing.
• WebSocket limits: TCP head-of-line blocking and guaranteed in-order delivery make it a poor fit for real-time media where a late packet is worthless.
• WebRTC: peer-to-peer audio, video, and arbitrary data channels running over UDP (SRTP/DTLS), with data channels configurable as unreliable and unordered.
• NAT traversal: ICE gathers candidates, STUN discovers the public address, and TURN relays when direct connection fails - and the cost reality that a meaningful share of connections fall back to TURN.
• The signaling gap: WebRTC deliberately doesn't specify signaling, so you still need an out-of-band channel (commonly WebSockets) to exchange SDP offers/answers and ICE candidates.
• WebRTC strengths: lowest latency, media-optimised, and it offloads bandwidth from your servers.
• WebRTC costs: substantially more complexity, mandatory encryption, and P2P mesh doesn't scale past a handful of peers - larger calls need an SFU or MCU.
• The decision rule: server-mediated messaging with reliable ordering points to WebSockets; low-latency media or direct peer data points to WebRTC - and real systems commonly use both together.