Vijay T - Technical Blog

Overview

WebRTC and WebSockets are both protocols that enable real‑time communication in browsers, but they serve very different purposes and work in fundamentally different ways. This post breaks down their core characteristics, compares them side‑by‑side, and outlines when you should reach for one over the other.

---

Quick Reference Table

Feature	WebRTC	WebSockets
Primary purpose	Peer‑to‑peer audio/video and low‑latency data (e.g., video chat, gaming)	Full‑duplex client‑to‑server messaging (e.g., chat, live dashboards)
Transport	UDP (with optional TCP fallback via TURN)	TCP
Reliability	Configurable – reliable or unreliable, ordered or unordered	Always reliable & ordered
Latency	Typically < 50 ms for media (no head‑of‑line blocking)	Slightly higher due to TCP & server hop, but still low for small messages
Security	DTLS + SRTP (end‑to‑end)	TLS (wss://) – encryption only client‑to‑server
Connection model	Peer‑to‑peer after an initial signaling exchange; can be relayed through TURN	Client‑to‑server; every message passes through the server
Media support	Native handling of audio/video, codecs, jitter buffer, echo cancellation	No built‑in media handling – you must serialize your own payloads
Scalability	Scales well for a few peers; larger conferences need an SFU/MCU	Scales horizontally by adding more server instances or a message broker
Browser API	RTCPeerConnection, MediaStream, RTCDataChannel	WebSocket
Typical libraries	Simple‑Peer, PeerJS, mediasoup, Jitsi, Twilio Video	socket.io, ws (Node), SignalR, Phoenix Channels, SockJS
Best use‑cases	Video calls, screen sharing, real‑time gaming, P2P file transfer	Chat, notifications, telemetry, collaborative editing, command‑control streams

---

Deep Dive

What WebRTC Is

WebRTC (Web Real‑Time Communication) is a suite of standards that lets browsers exchange audio, video, and arbitrary data directly with each other.

Component	Role
RTCPeerConnection	Negotiates the media/data path, handles ICE (STUN/TURN) discovery, DTLS/SRTP encryption, and (optionally) TURN relaying.
RTCDataChannel	SCTP over DTLS over UDP. You can ask for reliable (like WebSocket) or unreliable (like UDP) delivery.
MediaStream / getUserMedia	Captures microphone and camera and feeds them into a peer connection.

Transport details – By default WebRTC uses UDP, which avoids the head‑of‑line blocking that hurts live media. It implements its own congestion control and can fall back to TCP when a TURN relay is required.

Security – Media is encrypted with SRTP, data with DTLS, providing true end‑to‑end encryption; the signaling server never sees the media unless it also acts as a TURN relay.

Typical flow

1. Signaling (any channel – often a WebSocket) exchanges SDP offers/answers and ICE candidates.
2. Both peers create an RTCPeerConnection, set the remote description, add ICE candidates, and start streaming.
3. Media & data travel P2P (or via TURN) without touching the server.

What WebSockets Are

WebSocket creates a single, long‑lived TCP connection that upgrades an HTTP request (Upgrade: websocket). After the handshake, both ends can push text or binary frames at any time.

Key traits

• Always reliable & ordered (TCP).
• Secure when used as wss:// (TLS encrypts client‑to‑server traffic).
• Simple API: new WebSocket(url), socket.send(), socket.onmessage.

Typical flow

1. Client opens a WebSocket to wss://example.com/ws.
2. Server accepts and keeps the socket open.
3. Either side can push JSON, protobuf, or binary blobs whenever needed.

Typical server stacks – Node (ws, socket.io), .NET (SignalR), Java (Spring WebSocket), Go (gorilla/websocket), etc.

---

When to Use Which

Scenario	Recommended Choice	Why
Video/voice call	WebRTC	Built‑in media handling, low latency, P2P media path.
Real‑time multiplayer game	WebRTC (data channel)	Unreliable, unordered mode gives sub‑30 ms latency.
Simple chat or notifications	WebSocket	Simpler client‑server model, guaranteed delivery.
Large‑scale broadcast (thousands of viewers)	WebSocket + pub/sub	Scales horizontally; WebRTC would need an SFU/MCU.
P2P file transfer between two browsers	WebRTC	Data never touches the server, saving bandwidth.
Corporate network behind strict firewalls	WebSocket	Operates over standard HTTPS ports; UDP may be blocked.
You already have a signalling server	Either (reuse it)	The same server can host both a signalling endpoint and a WebSocket endpoint.

---

Code Samples

WebRTC DataChannel (Peer‑to‑Peer)

// Signaling channel (could be any transport, here a WebSocket)
const signaling = new WebSocket('wss://signaler.example.com');

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

let dc = pc.createDataChannel('chat', {
  ordered: true,         // reliable, ordered (set false for unordered)
  maxRetransmits: 0,     // 0 → unreliable (no retransmission)
});

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

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

// Receive signalling messages
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 creates the offer
async function startCall() {
  const offer = await pc.createOffer();
  await pc.setLocalDescription(offer);
  signaling.send(JSON.stringify({ offer }));
}

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', ({ data }) => {
  const msg = JSON.parse(data);
  if (msg.type === 'chat') {
    console.log('🗨️', msg.user, ':', msg.text);
  }
});

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

---

Best‑Practice Tips

WebRTC

• TURN servers cost bandwidth – budget for them if many users are behind restrictive NATs.
• Handle ICE time‑outs – give 30 s–2 min for candidate gathering on cellular networks.
• Watch browser quirks – Safari’s autoplay restrictions, Chrome’s limit on simultaneous video tracks.
• Keep signalling stateless – treat it as a simple message broker; the heavy lifting is inside WebRTC.

WebSocket

• Heartbeat/ping – Some proxies drop idle sockets; send a ping every 30 s.
• Back‑pressure – Monitor socket.bufferedAmount to avoid memory bloat when sending fast bursts.
• Chunk large payloads – For > 10 MB files, consider uploading via HTTP POST and only notifying via WebSocket.
• Scale broadcasting – Use a pub/sub layer (Redis, NATS, Kafka) behind your WebSocket servers to keep fan‑out cheap.

---

TL;DR Summary

• WebRTC = peer‑to‑peer media + optional data, built on UDP, with configurable reliability and end‑to‑end encryption. Ideal for video calls, low‑latency gaming, and direct file transfers.
• WebSockets = client‑to‑server full‑duplex channel over TCP, always reliable & ordered, easy to set up, works through firewalls, perfect for chat, notifications, telemetry, and any scenario where a central server must see the data.

You can even combine them: use WebSocket for signaling, presence, and UI updates, while WebRTC carries the actual media and high‑speed data. Choose the tool that matches the latency, scalability, and architectural requirements of your application.