WebRTC vs WebSockets for File Transfer

A WebSocket (RFC 6455) is a long-lived, message-framed connection over TCP from a browser to a server. Browsers can open WebSockets but cannot accept them, so two browsers exchanging a file over WebSockets each connect to the same server, and the server copies every message from one socket to the other.

A WebRTC data channel is negotiated through a server too, but only the small offer, answer and network candidates take that route. After ICE finds a working address pair, the file travels on the peer-to-peer path inside DTLS. When no direct pair works, a TURN server forwards the encrypted packets, which makes it a relay of a different kind: it moves ciphertext it has no key for, and it is used only as a last resort. The data channel guide explains that stack in detail.

Everything else in the comparison (cost, speed, privacy, reliability on hostile networks) follows from this single difference in topology.

One row deserves emphasis: neither API gives the receiver backpressure. Both push messages at the page as fast as they arrive, so a transfer of any real size needs an application-level “pause” message from the receiver whichever transport carries it.

“Encrypted” means different things on the two transports. With WebSockets over wss://, TLS protects the browser-to-server hop and the server-to-browser hop separately. The server terminates both, so it, its hosting provider, and anyone who compromises it can read the file. That is the ordinary model for most web uploads, and it is fine when the server is meant to have the data.

A WebRTC data channel is encrypted with DTLS keys negotiated by the two browsers themselves; a TURN relay in the middle cannot read it. There is a catch: the browsers authenticate each other only by certificate fingerprints carried in the SDP, which travels through the signaling server. A signaling server that rewrites those fingerprints can place itself in the middle. DTLS therefore protects against the network and the TURN operator, and against an honest signaling server, but not against a malicious one unless the application verifies fingerprints by another route.

A relay can reach a similar position with application-level encryption: each device generates a key pair, they agree a shared key with ECDH, and every chunk is sealed with an AEAD cipher such as AES-256-GCM before it goes onto the socket. The relay then forwards ciphertext. It still sees metadata (IP addresses, sizes, timing, and whatever the protocol sends in clear), which what a relay can see inventories. Public keys exchanged through the server have the same weakness as fingerprints in SDP: the server introduces them.

Claims that one transport is simply “faster” are not meaningful without the path. Some useful rules:

• Same network: a direct data channel can stay on the local network, while a relay sends the bytes to a data centre and back. This is where WebRTC has its clearest advantage.
• Different networks, both with good links: both are usually limited by the sender's upload. A well-provisioned relay close to both peers can be competitive with a direct path across a congested long route.
• Lossy links: TCP's single ordered stream stalls on every loss. SCTP has the same issue within one ordered channel, but control messages on another channel are not blocked behind file data.
• Hostile networks: blocked UDP, symmetric NATs or TLS-inspecting proxies may defeat WebRTC without a TURN server reachable on port 443. WebSockets fail only when the proxy breaks the HTTP upgrade, and even then an HTTPS long-polling stream can stand in.

The operator's cost differs sharply. A relay that forwards a 10 GB file moves 20 GB through its network interface. A direct data channel moves nothing through the operator, and TURN moves the same 20 GB only for the sessions that need it. The slow transfer guide covers how to tell which link is the bottleneck.

SRIFT's browser client (version 4.3.2) runs what its code calls relay-first with a WebRTC head start. The design accepts that direct connections are better when they work and that waiting for one that will never open is the worst outcome.

1. Capability check. A short probe asks public STUN servers for a server-reflexive candidate to learn whether UDP works, and the page fetches short-lived TURN credentials. If neither UDP nor TURN is available, WebRTC is skipped and the relay starts at once.
2. Head start. Otherwise the direct channel gets 3 seconds to open. No file bytes are sent before it opens, so abandoning it at the deadline cannot duplicate or corrupt anything. If it opens, it carries the whole file.
3. Relay fallback. If the channel misses the deadline or fails mid-transfer, the WebSocket relay takes over. Both transports write into one byte-addressed file on the receiver, which reports what it already holds, so the relay sends only the remainder. The transfer never switches back to WebRTC mid-stream, because changing transports twice is where ordering bugs live.

On the relay, each 256 KB chunk is sealed with AES-256-GCM under a key derived (HKDF-SHA256) from a fresh ECDH P-256 exchange made for that transfer. The chunk's file ID, index and total count are bound in as additional authenticated data, so the relay cannot reorder or splice chunks undetected. Up to 16 chunks are in flight, and unacknowledged ones are re-sent after 8 seconds. The CLI and its daemon use this sealed relay for session transfers rather than raw WebRTC. When WebSockets cannot open at all, the browser moves its whole session connection onto HTTPS requests instead.

WebSockets alone are enough when

• Files are small and the server should have them anyway (uploads into your own application).
• Your users are mostly on locked-down corporate networks and you cannot run TURN.
• You want the simplest correct implementation and can pay for the bandwidth.

WebRTC is worth the extra work when

• Files are large, and relaying them would dominate your hosting bill.
• Peers are often on the same network, where a direct path avoids the round trip to a data centre.
• You want the server out of the data path, and you will handle the signaling trust problem honestly.

Use both when

You need transfers to succeed for everyone. Time-box the direct attempt, relay with end-to-end sealing when it fails, and make the two transports resume from the same byte offset. That is more code than either alone, but it is the only arrangement that is both efficient on good networks and dependable on bad ones. SRIFT's browser P2P transfer is one working example.