WebRTC vs WebSockets

TL;DR

Feature	WebRTC	WebSockets
Primary purpose	Real‑time peer‑to‑peer audio, video, and low‑latency data streams (e.g., video chat, screen sharing, online gaming).	Full‑duplex client‑to‑server messaging (e.g., chat, notifications, live dashboards).
Transport layer	UDP (with optional fallback to TCP); built‑in congestion control, NAT‑traversal (ICE/STUN/TURN).	TCP (reliable, ordered).
Media support	Native codecs, SRTP encryption, jitter buffer, echo‑cancellation, etc.	No built‑in media handling – you have to serialize and send your own binary blobs.
Data channel	SCTP over DTLS over UDP – unreliable (unordered) or reliable (ordered) modes possible.	Simple byte‑stream over a single TCP socket (always reliable & ordered).
Connection model	Peer‑to‑Peer (P2P) after an initial signaling exchange; can also be relayed through TURN servers.	Client‑Server – every message goes through the server.
Latency	Typically < 50 ms for media because UDP avoids head‑of‑line blocking.	Usually a few milliseconds extra due to TCP and the server hop, but still low (10‑30 ms) for small messages.
Reliability	Configurable: you can choose unreliable, unordered delivery (good for live video); also reliable mode for data.	Always reliable, in‑order delivery (good for chat, state sync).
Security	DTLS (data) + SRTP (media) – end‑to‑end encryption between peers.	TLS (wss://) – encryption between client and server; the server can read everything.
Scalability	P2P scales well for small groups (e.g., 2‑4 participants). For large conferences you need an SFU/MCU which re‑introduces a server.	Scales by adding more server instances or using a message broker (e.g., Redis, Kafka).
Browser support	Chrome, Edge, Firefox, Safari (≥ 11) – all expose `RTCPeerConnection`, `RTCIceCandidate`, `MediaStream`, `RTCDataChannel`.	All modern browsers support `WebSocket`.
Typical libraries	Simple‑Peer, PeerJS, mediasoup, Jitsi, Twilio Video, Kurento.	socket.io, ws (Node), SignalR, Phoenix Channels, SockJS.
When to use	Real‑time audio/video, low‑latency gaming, file‑transfer where you want P2P or can tolerate NAT traversal.	Chat, notifications, live‑updates, command/control, telemetry, any classic request/response‑style messaging.

1. What WebRTC really is

WebRTC (Web Real‑Time Communication) is a suite of standards that lets browsers (and native apps) communicate directly with each other, without a middle‑man for the media path.

Core components
- RTCPeerConnection: negotiates the media/data path, handles ICE (Interactive Connectivity Establishment), DTLS, SRTP, and (optionally) TURN relaying.
- RTCDataChannel: a datagram‑style channel built on top of SCTP/DTLS. You can choose reliable (like WebSocket) or unreliable (like UDP) delivery.
- MediaStream/getUserMedia: grabs microphone/camera and feeds the tracks into the peer connection.
Transport
- UDP is the default because it avoids the head‑of‑line blocking that hurts live media. WebRTC adds its own congestion control (similar to TCP’s AIMD) and can switch to TCP via TURN if UDP is blocked.
- NAT/Firewall traversal is handled automatically through ICE – a combination of STUN (discover your public IP) and TURN (relay when direct connection fails).
Security
- Media is encrypted with SRTP; data is encrypted with DTLS. Encryption is end‑to‑end – the server that performed signaling never sees the media unless it’s also a TURN relay.
Use‑case pattern
1. Signaling (any channel – often WebSocket, HTTP POST, or even email) to exchange SDP offers/answers and ICE candidates.
2. Both peers create an RTCPeerConnection, set the remote description, add ICE candidates, and start streaming.
3. Media flows P2P (or via TURN) and data can go through the RTCDataChannel.
When it shines
- Video calls, screen‑share, VoIP.
- Real‑time multiplayer games where you need sub‑50 ms latency and can tolerate occasional packet loss.
- Large file transfer between two browsers (e.g., using the unordered, unreliable mode for speed).

2. What WebSockets really is

WebSocket is a single, long‑lived TCP connection that upgrades an HTTP request (GET /socket HTTP/1.1 → Upgrade: websocket). After the handshake, both ends can send frames at any time, achieving full‑duplex communication.

Transport – always TCP, guaranteeing ordered, reliable delivery.
Message framing – each frame can carry a text or binary payload up to 2⁶³‑1 bytes.
Security – you usually run it over TLS (wss://). Encryption is client‑to‑server; the server can read, inspect, and modify the payload.
Typical server stacks
- Node: ws, socket.io (adds fall‑backs, rooms, acknowledgments).
- .NET: SignalR (auto‑selects WebSocket → Server‑Sent Events → Long‑Polling).
- Java: Undertow, Jetty, Spring WebSocket.
- Go: gorilla/websocket, nhooyr/websocket.
Use‑case pattern
1. Client opens a WebSocket to wss://example.com/ws.
2. Server accepts, holds the socket open.
3. Either side can push JSON, protobuf, or binary blobs whenever they like.
When it shines
- Real‑time dashboards (stock tickers, IoT telemetry).
- Chat rooms, collaborative editors (e.g., operational transform or CRDT messages).
- Server‑driven push notifications where you need reliable delivery.

3. Head‑to‑Head Comparison

Aspect	WebRTC	WebSocket
Direction	Peer‑to‑Peer (P2P) after signaling.	Client‑to‑Server (C2S).
Network path	Direct (or via TURN relay).	Always goes through the server.
Protocol stack	ICE → DTLS → SRTP (media) / SCTP (data) over UDP (or TCP via TURN).	HTTP/1.1 (Upgrade) → TLS (optional) → TCP → WebSocket frames.
Reliability	Configurable – you can choose unreliable, unordered delivery (good for live video).	Always reliable, ordered.
Latency	Usually lower for media because UDP avoids retransmission delay.	Slightly higher due to TCP ACK round‑trips and server hop, but still milliseconds.
Scalability	Good for 2‑4 peers; larger groups need an SFU/MCU (adds server load).	Horizontally scalable by adding more WebSocket servers or a message broker.
Bandwidth	Media uses codecs (~1‑2 Mbps per HD stream) plus overhead; data channel is lightweight.	Payload limited only by TCP; you typically send small messages (< 1 KB) but can stream large binaries too.
Firewall/NAT	Handles NAT via ICE; can fail if UDP blocked and no TURN server available.	Works through most corporate firewalls because it’s just HTTP → WebSocket on port 80/443.
Complexity	Higher: you need signaling, ICE handling, TURN infrastructure, media codec considerations.	Simpler: just open a socket, optionally add rooms or a pub/sub layer.
Browser API	`RTCPeerConnection`, `getUserMedia`, `RTCDataChannel`.	`new WebSocket(url)`, `socket.send()`, `socket.onmessage`.
Server role	Optional (only for signaling & TURN).	Mandatory (receives and forwards all traffic).
Use‑case recommendation	• Video/voice calls <br>• Real‑time gaming <br>• P2P file transfer	• Chat & notifications <br>• Live dashboards <br>• Command & control messages

4. Example Code Snippets

4.1 WebRTC DataChannel (Peer‑to‑Peer)

// === Signaling (could be a simple WebSocket) ===
const signaling = new WebSocket('wss://signaler.example.com');

let pc = new RTCPeerConnection({
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }],
});

let dataChannel = pc.createDataChannel('chat', {
  ordered: true,          // true = like WebSocket; false = unordered (faster)
  maxRetransmits: 0,      // 0 => unreliable (no retransmission)
});

dataChannel.onopen = () => console.log('DataChannel open');
dataChannel.onmessage = e => console.log('Peer says:', e.data);

// ICE candidate handling
pc.onicecandidate = ({ candidate }) => {
  if (candidate) signaling.send(JSON.stringify({ candidate }));
};

// Signaling exchange
signaling.onmessage = async ({ data }) => {
  const msg = JSON.parse(data);
  if (msg.offer) {
    await pc.setRemoteDescription(msg.offer);
    const answer = await pc.createAnswer();
    await pc.setLocalDescription(answer);
    signaling.send(JSON.stringify({ answer }));
  } else if (msg.answer) {
    await pc.setRemoteDescription(msg.answer);
  } else if (msg.candidate) {
    await pc.addIceCandidate(msg.candidate);
  }
};

// Initiator (first client) creates the offer
async function startCall() {
  const offer = await pc.createOffer();
  await pc.setLocalDescription(offer);
  signaling.send(JSON.stringify({ offer }));
}

Note: The signaling channel (here a plain WebSocket) is not part of WebRTC. It can be any transport you like (HTTP, MQTT, etc.).

4.2 WebSocket (Client‑Server)

const socket = new WebSocket('wss://api.example.com/ws');

socket.addEventListener('open', () => {
  console.log('WebSocket connected');
  socket.send(JSON.stringify({ type: 'join', room: 'lobby' }));
});

socket.addEventListener('message', event => {
  const msg = JSON.parse(event.data);
  if (msg.type === 'chat') {
    console.log('🗨️', msg.user, ':', msg.text);
  }
});

// Send a chat message
function sendChat(text) {
  socket.send(JSON.stringify({ type: 'chat', text }));
}

5. Choosing the Right Tool for Your Project

Situation	Choose WebRTC	Choose WebSocket
Need a video call	✅	❌ (you’d have to implement your own media pipeline).
Low‑latency game state sync (sub‑30 ms)	✅ (unreliable data channel).	✅ if you can tolerate TCP’s extra RTT; otherwise WebRTC is usually faster.
Simple chat or notifications	✅ (you can cheat with a data channel) but WebSocket is far simpler because you already have a server.	✅ Recommended.
Large broadcast (thousands of viewers)	❌ (P2P scales poorly; you’d need an SFU/CDN).	✅ (push to a distributed message broker).
File transfer between two browsers	✅ (WebRTC data channel can stream without hitting the server).	✅ (but the file passes through the server, consuming bandwidth).
Corporate network behind strict firewalls	❌ (UDP may be blocked, TURN adds latency).	✅ (WebSocket works over HTTPS).
You already have a signalling server	✅ (you can reuse it for WebRTC).	✅ (same server can host the WebSocket endpoint).

6. Gotchas & Best Practices

WebRTC

TURN costs – TURN servers relay traffic when direct P2P fails; they consume bandwidth and you’ll typically pay for that.
Browser quirks – Safari’s getUserMedia has stricter autoplay rules; Chrome caps the number of simultaneous video tracks.
Stateless signalling – Keep your signalling channel stateless (e.g., REST or WebSocket), because WebRTC itself is stateful.
ICE timeouts – Give enough time (30s–2 min) for ICE to discover a viable candidate, especially on cellular networks.
Security – Never expose raw SDP/ICE information to unauthenticated users; it can be used for recon‑structing network topology.

WebSocket

Heartbeat/Ping – Some proxies drop idle connections; implement a periodic ping (e.g., every 30 s).
Back‑pressure – The browser buffers outgoing frames; if you send faster than the network, you can run out of memory. Use socket.bufferedAmount.
Message size – Large binary payloads (≥ 10 MB) should be chunked or transferred via HTTP POST with an ID, then notified via WebSocket.
Scalable broadcasting – Use a pub/sub system (Redis, NATS, Kafka) behind the WebSocket servers to avoid “fan‑out” bottlenecks.

7. TL;DR Summary

WebRTC = peer‑to‑peer media + optional data, built on UDP, offers configurable reliability, low latency, and end‑to‑end encryption. Best for video/audio, real‑time games, and direct file transfer.
WebSockets = client‑to‑server full‑duplex channel over TCP, always reliable/ordered, easy to set up, and works in any environment that allows HTTPS. Best for chat, live updates, telemetry, and any scenario where a central server must see the data.

Pick WebRTC when you need real‑time media or ultra‑low‑latency P2P data; pick WebSocket when you just need a reliable, simple, server‑mediated message pipe. If you need both (e.g., a video call with a side‑channel chat that also reaches a server), you can run them side‑by‑side – use WebRTC for the media/data path and WebSocket for control, presence, and UI updates. Happy coding!

Vijay T - Technical Blog