What WebRTC is
Browser/API for peer-to-peer real-time: audio, video, and RTCDataChannel for arbitrary binary/text.
Signaling (SDP offer/answer, ICE candidates) happens out of band — typically your WebSocket/HTTPS server. Media/data flows P2P when possible.
Key components
| Piece | Role |
|---|---|
| RTCPeerConnection | ICE, codecs, encryption (DTLS-SRTP) |
| ICE | Finds best network path between peers |
| STUN | Discovers public IP/port (NAT hole punch) |
| TURN | Relays when P2P impossible (~10–20% of calls) |
| SDP | Session description (codecs, streams) |
| DataChannel | Ordered/unordered, reliable/unreliable messages |
NAT traversal (interview favorite)
Most users behind NAT/firewall → direct UDP often fails → need STUN first, TURN fallback.
TURN costs bandwidth (all media through your servers) — budget for scale.
Signaling flow (simplified)
A Signaling server B
|-- offer (SDP) ---->|--------------------------->|
| |<-------- answer (SDP) -----|
|<-- ICE candidates exchanged via signaling ----->|
|=========== optional direct P2P path ===========|
|=========== or relay via TURN ===================|
Signaling is not standardized — you design JSON messages over HTTPS/WS.
DataChannel use cases
- File transfer P2P (reduces server egress)
- Low-latency game state
- Screen share metadata
Limits: both peers must be online; mobile backgrounding kills connections.
vs WebSocket to server
| WebSocket via server | WebRTC DataChannel | |
|---|---|---|
| Path | Client↔Server | Client↔Client (often) |
| Server load | All traffic | Signaling + TURN only |
| NAT | N/A | Complex |
| Recording/compliance | Easy | Hard |
SFU vs MCU (video architecture)
- MCU — server mixes streams (expensive CPU)
- SFU — server forwards streams (Selective Forwarding Unit) — Zoom/Meet pattern
Staff depth for video interviews; data transfer interviews may stop at DataChannel + TURN.
Security
DTLS encryption on media/data channels. Verify signaling auth — attacker controlling signaling can MITM. Use TURN credentials with TTL.
Cross-reference: Bulk transfer topic for TB-scale (WebRTC is wrong tool); Networking for UDP/TLS concepts underlying QUIC/DTLS.
Further Reading
Hands-On Tasks (Optional)
API design drills and whiteboard exercises — protocol selection, contract design, and bulk-transfer architecture. Assumes Networking and sibling tracks on the hub page (Distributed Systems, Databases, Concurrency, LLD).
- Sketch WebRTC signaling flow20m
Two browsers behind NAT: diagram offer/answer SDP exchange via your HTTPS signaling server, ICE candidate trickle, and when TURN relay is required.