Most web users know WebRTC as the engine behind Google Meet and Discord video calls. But few realize that the exact same protocol can transport raw binary data—gigabytes of photos, videos, and archives—directly between two web browsers without passing through any intermediate server.
The WebRTC Handshake: Breaking Down the Magic
Normally, browsers cannot talk to each other directly because of Network Address Translation (NAT) firewalls and dynamic IP addresses. WebRTC solves this via an elegant three-step dance:
Step 1: The Signaling Phase
Before browsers can connect directly, they need an initial rendezvous point. A lightweight signaling server (like Sendly's WebSocket backend) helps the two browsers introduce themselves. Device A sends an SDP Offer (Session Description Protocol), containing its network capabilities and supported codecs. Device B replies with an SDP Answer.
Step 2: NAT Traversal with STUN and TURN
Most home and corporate routers hide your computer's real IP address behind NAT. WebRTC uses STUN (Session Traversal Utilities for NAT) servers to ask: 'What is my public IP and port as seen from the outside world?'
Each discovered network path is bundled into an ICE Candidate (Interactive Connectivity Establishment). The browsers exchange these candidates and automatically pick the fastest, lowest-latency direct route.
Step 3: Direct SCTP DataChannels
Once the direct UDP route is established, the signaling server steps out of the loop completely. The browsers open an encrypted SCTP DataChannel running over DTLS (Datagram Transport Layer Security).
Streaming Massive Files with ArrayBuffer Chunking
How can a web browser with limited RAM send a 10GB video file without crashing the tab? The secret is stream chunking:
- The source browser uses the HTML5 File API and
ReadableStreamto slice the file into 64KB binary chunks. - Each chunk is buffered and piped into the WebRTC DataChannel.
- The receiving browser reads the stream via a
WritableStreamor reconstructs the chunks directly into an IndexedDB cache or immediate download trigger. - Because chunks are processed sequentially, browser memory usage stays below 50MB regardless of whether the file is 100MB or 20GB!
Why WebRTC Beats HTTP Uploads Hands Down
When you upload a file via standard HTTP/POST to a cloud server, your packets incur multiple rounds of TCP handshake latency, proxy buffering, and disk write overhead. With WebRTC, throughput is limited solely by the physical network pipe between the sender and receiver. There are no server storage limits, no artificial download caps, and no waiting in server queues.