Direct P2P vs Encrypted Relay: What Is the Real Difference?

By ShareDrop.org Engineering · Published Jul 24, 2026 · Updated Sep 21, 2026

Peer-to-peer tools love the phrase “your files never touch a server.” It is true only some of the time. When two networks cannot reach each other directly, WebRTC falls back to a relay, and an honest tool should tell you when that happens and what it means. Here is the real difference between the two paths.

What actually differs

	Direct (LAN or internet)	Encrypted relay (TURN)
Path	Device ↔ device	Device ↔ relay server ↔ device
Encryption	End-to-end (DTLS)	Identical end-to-end encryption — the relay has no keys
Who can read content	Only the two devices	Only the two devices
Metadata exposure	Networks on the route see packet flow	Relay operator additionally sees both IPs, sizes, timing
Speed	LAN: often hundreds of Mbps; internet: bounded by both uplinks	Bounded by uplinks and the relay's bandwidth; one extra hop of latency

Measured: what each path can actually sustain

Speed differences between the paths come from where the bottleneck sits, not from the protocol. To separate the two, the ShareDrop.org transfer engine was benchmarked with both browsers on one machine (no network in the way), and that ceiling is set here against what typical networks allow:

Bar chart of sustained throughput by connection path: engine benchmark 200+ Mbps measured; LAN direct typically 100–400 Mbps, router-bound; internet direct and encrypted relay typically 20–50 Mbps, bounded by uplinks, with the relay adding one hop of latency — Sustained throughput by path. The engine figure is a measured benchmark (see method below); LAN and internet figures are typical home-network magnitudes — your router and uplinks set those ceilings, not the protocol.

Path	What sets the ceiling	Typical result
Engine benchmark	CPU only: DTLS encryption + SCTP framing + real-time SHA-256 on both ends	200+ Mbps (25 MB/s) sustained, measured
LAN direct	Wi-Fi link rate of the slower device and the router	100–400 Mbps on Wi-Fi 5/6 networks
Internet direct	The slower side's upload bandwidth	20–50 Mbps on typical home broadband
Encrypted relay	Slower uplink and relay bandwidth; one extra network hop	Similar to internet direct, with roughly 10–80 ms added round-trip time depending on relay distance

The practical reading: on a LAN the protocol is rarely the limit — the radio is. Across the internet, upload bandwidth dominates everything, which is why a relay usually costs you latency rather than throughput.

How the benchmark was measured

Throughput: two browser instances on one machine transfer a large file through the full production pipeline: encrypted data channel, 64 KiB chunking, and SHA-256 hashing running in real time on both ends. Same-machine loopback removes the network so the number isolates protocol and crypto overhead.
Path classification: the selected ICE candidate pair is read from the live getStats() connection statistics. If either candidate of the winning pair has type relay, the transfer is on TURN; host/server-reflexive pairs are direct. This is the same signal chrome://webrtc-internals shows, and the same logic that drives the path badge in the app.
Typical network figures: the LAN and uplink ranges above are stated as common magnitudes for home Wi-Fi 5/6 and home broadband plans, not as benchmark results: your numbers depend on your hardware and plan.

The key insight: encryption is unchanged

The common fear (“relay mode means the operator can read my files”) is wrong for WebRTC. The DTLS keys protecting a data channel are negotiated between the two browsers during connection setup; a TURN relay authenticates you, allocates a forwarding port, and shovels ciphertext. This is not a policy promise but an architectural property (how WebRTC encryption works). What a relay does see is traffic metadata: who talked to whom, when, and how much. That is the honest cost of relay mode.

When you get which

Same Wi-Fi: usually a LAN-direct connection — the fastest case.
Two home networks: usually direct via hole punching (STUN).
Office/campus/hotel networks, CGNAT, strict firewalls: often relay-only (why).
Both sides on VPNs: frequently relay, sometimes nothing at all (VPN effects).

How to tell which one you got

In ShareDrop.org, look at the badge next to the title: LAN direct, Internet direct, or Encrypted relay. It is computed from the selected ICE candidate pair in the live connection statistics: if either side of the winning pair is a relay candidate, you are on TURN. When the browser exposes too little statistics to decide, the app shows “encrypted, mode unknown” rather than guessing. Developers can verify the same thing in chrome://webrtc-internals: find the active candidate pair and check the local and remote candidate types.

Relay in numbers

Every relayed byte enters the relay server and leaves it, so a 1 GB relayed transfer is 2 GB of server traffic, which is the single largest running cost of a peer-to-peer service and the reason many tools quietly have no relay at all. Estimates commonly cited by WebRTC operators put the relayed share of sessions somewhere between one in ten and one in five, and the sessions that need it are mostly phone-to-phone transfers on mobile data, where both sides sit behind carrier-grade NAT. ShareDrop.org runs its own relay (coturn) rather than renting one, which keeps the logging policy in the service's own hands: addresses for at most 24 hours, nothing else, and nothing the relay could log about the file in any case (how the relay works and what running one involves).

Can you force one or the other?

There is no switch, on purpose. ICE already picks the best available path (direct when it can, relay when it must), and a switch could only make things worse: forcing direct would fail on networks that need the relay, and forcing relay would waste bandwidth and add latency for no benefit. What you can control is the network. Two devices on one phone hotspot will always go LAN direct; a VPN on one device will almost always push the connection to a relay, which is the one legitimate reason to want that: hiding your address from the peer (the VPN trade-offs).

When the badge changes mid-transfer

A phone walking out of Wi-Fi range onto cellular changes its address. The browser performs an ICE restart (a fresh round of candidates and checks on the live connection), and the winning pair can change type: a transfer that began LAN direct continues as Internet direct or Encrypted relay without stopping, and the badge follows. The reverse happens when a phone reaches home Wi-Fi. Encryption is unaffected by any of this, because the DTLS session survives the restart; the safety code does not change either, since the certificates are the same.

When the badge says “mode unknown”

The badge is read from the connection statistics, and some browsers expose less of those than others: older Safari versions in particular did not always report which candidate pair was selected. In that case ShareDrop.org shows “encrypted, mode unknown” rather than guessing from what it configured. The connection is exactly as encrypted as any other; the only thing missing is the label.

Frequently asked

Is relay mode slower?

Usually not in throughput (the bottleneck across the internet is the sender's uplink either way), but it adds one hop of latency, typically tens of milliseconds. On the same Wi-Fi, a relay is dramatically slower, because a local transfer is being sent out to the internet and back; that case means the network is isolating clients.

Does the relay see file names?

No. Names travel inside the encrypted channel with everything else. The relay sees addresses, packet sizes and timing.

Can both sides be “on the relay” at once?

A relayed connection is one path with the relay in the middle; both devices talk to it. Occasionally ICE selects a pair where only one side's candidate is a relay and the other is direct — the packets still pass through the relay, and the badge still says so.

The words, briefly

Term	Meaning here
Host candidate	A device's own address on its local network; wins when both devices share a network
Reflexive candidate	The public address a STUN server reports; wins when hole punching through both routers succeeds
Relay candidate	An address on the TURN server allocated for this device; wins when nothing direct works
STUN	The mirror that tells a device its public address
TURN	The relay that forwards encrypted packets between two devices that cannot reach each other
ICE	The procedure that gathers all of the above, tests the pairs, and picks the best one
DTLS	The encryption between the two browsers, negotiated end to end regardless of path

Should you avoid relay mode?

For most transfers, no: it exists precisely so the transfer succeeds where direct paths cannot. Avoid it only if your threat model includes traffic-metadata collection by the relay operator, in which case the alternative is moving both devices onto the same trusted network and getting a LAN-direct link.

Standards referenced

RFC 8445: Interactive Connectivity Establishment (ICE): how the candidate pairs above are gathered and selected.
RFC 8656: Traversal Using Relays around NAT (TURN): the relay protocol, including why the relay only forwards and never terminates encryption.
RFC 8831: WebRTC Data Channels: the SCTP-over-DTLS stack every ShareDrop.org transfer runs on.
RFC 8827: WebRTC Security Architecture: the mandate that keys are negotiated end-to-end between browsers.