Met bestandsoverdracht via WebRTC sturen twee browsers elkaar een bestand zonder het naar cloudopslag te uploaden. Dat klinkt eenvoudig, maar internet is er niet voor gebouwd dat twee thuiscomputers elkaar rechtstreeks bellen. Deze handleiding loopt door wat er echt gebeurt — signalering, NAT, STUN, ICE, TURN, DTLS en datakanalen — in gewone taal, met StrongFolder als voorbeeld.
Wat is WebRTC?
WebRTC (Web Real-Time Communication) is een verzameling browser-API's en netwerkprotocollen, gestandaardiseerd door het W3C en de IETF, voor realtime verbindingen tussen browsers. Chrome, Edge, Firefox, Safari en Opera ondersteunen het allemaal. Het is gebouwd voor video- en spraakgesprekken, maar heeft ook datakanalen die willekeurige binaire gegevens vervoeren — en dat is precies wat een bestand is.
De belangrijkste eigenschap: zodra een WebRTC-verbinding is opgezet, gaan gegevens tussen de twee eindpunten, niet naar de opslag van een server. Dat maakt P2P-bestandsoverdracht in de browser mogelijk.
Waarom kunnen twee browsers niet gewoon met elkaar verbinden?
Omdat bijna geen enkel apparaat een eigen openbaar adres heeft. Je laptop zit achter een thuisrouter, een bedrijfsfirewall of het netwerk van een mobiele provider. De router doet aan NAT (Network Address Translation): veel privéapparaten delen één openbaar IP-adres, en de router laat alleen verkeer binnen dat antwoordt op iets wat van binnenuit is verstuurd.
Twee browsers hebben dus drie problemen voordat er bestandsgegevens kunnen stromen:
- Ze weten niet hoe ze elkaar kunnen bereiken — geen van beide weet dat de ander bestaat.
- Ze kennen hun eigen openbare adres niet — alleen het privéadres, zoals 192.168.1.20.
- Hun routers kunnen ongevraagd inkomend verkeer blokkeren.
WebRTC lost elk probleem op met een apart mechanisme.
Hoe werkt een bestandsoverdracht via WebRTC, stap voor stap?
Hier is het volledige verloop, van het klikken op "delen" tot de laatste byte:
Sender browser Servers Recipient browser
────────────── ─────── ─────────────────
1. Choose files ──── metadata ──▶ Signaling server
◀──────── 2. Open link ────────
3. Offer (SDP) ─────────────────▶ Signaling ──────────────────▶ Answer (SDP)
4. Ask STUN "how do I look?" ─▶ STUN servers ◀─ Ask STUN "how do I look?"
5. ICE candidates ◀─────────────▶ Signaling ◀──────────────────▶ ICE candidates
6. ICE checks: try LAN → direct internet → TURN relay
7. DTLS handshake ◀════════════ encrypted ═════════════════▶ DTLS handshake
8. Data channel: file chunks ═══(direct or via TURN relay)══▶ written to disk
Stap 1–2 — Signalering. De afzender kiest bestanden; de dienst legt de metadata vast die voor de link nodig is. Als de ontvanger de link opent, zijn beide browsers verbonden met een signaleringsserver. WebRTC legt niet vast hoe signalering werkt; StrongFolder gebruikt PeerJS met een eigen signaleringsserver.
Stap 3 — Offer en answer. De ene browser maakt een offer in SDP (Session Description Protocol): "Ik wil een datakanaal, hier zijn mijn vingerafdruk voor versleuteling en mijn mogelijkheden." De andere antwoordt met een answer. Beide gaan via de signaleringsserver.
Stap 4 — STUN. Elke browser vraagt een STUN-server: "vanaf welk adres en welke poort zie je me binnenkomen?" Het antwoord is zijn openbare adres zoals de router het vertaalt. STUN-servers verwerken een piepklein verzoek en geen bestandsgegevens; StrongFolder gebruikt openbare STUN-servers, waaronder die van Google, en eigen servers.
Stap 5 — ICE-kandidaten. Elke browser verzamelt kandidaten — mogelijke manieren om hem te bereiken: zijn adres op het lokale netwerk (host), zijn openbare adres via STUN (server-reflexive) en een adres op een TURN-relay (relayed). Ze wisselen de kandidaten uit via signalering.
Stap 6 — Connectiviteitscontroles. ICE (Interactive Connectivity Establishment) test paren van kandidaten en kiest het beste paar dat werkt. Zitten beide apparaten op hetzelfde wifi-netwerk, dan wint een lokaal pad. Laten routers het toe, dan wint een direct pad via internet ("hole punching"). Werkt niets direct, dan wordt het pad via de relay gebruikt.
Stap 7 — DTLS. Voordat er gegevens stromen, doen de browsers een DTLS-handshake (TLS aangepast voor UDP) en controleren ze of de vingerafdrukken van de certificaten overeenkomen met die in de offer en answer. Vanaf nu is alles versleuteld.
Stap 8 — Datakanaal. Over DTLS draait SCTP, dat het datakanaal betrouwbare, geordende levering geeft. Bij StrongFolder vraagt de browser van de ontvanger een bestand op, leest de browser van de afzender het in stukken van de schijf en verstuurt ze, en schrijft de ontvanger elk stuk naar de schijf zodra het binnenkomt — dus zelfs zeer grote bestanden hoeven nooit in het geheugen te passen.
Wat betekenen STUN, TURN, ICE en de andere termen?
| Term | Wat het doet | Ziet bestandsgegevens? | Standaard |
|---|---|---|---|
| Signalering | Geeft offers, answers en kandidaten door tussen browsers | Nee | Niet gestandaardiseerd (per app) |
| NAT | Routerfunctie die één openbaar IP-adres deelt tussen veel apparaten | — | — |
| STUN | Vertelt een browser zijn openbare adres en poort | Nee | IETF RFC 8489 |
| ICE | Verzamelt kandidaten en kiest een werkend pad | Nee | IETF RFC 8445 |
| TURN | Stuurt verkeer door als geen direct pad werkt | Alleen versleutelde pakketten | IETF RFC 8656 |
| DTLS | Versleutelt de verbinding (TLS voor UDP) | Versleutelt ze | IETF RFC 9147 (1.3), RFC 6347 (1.2) |
| SCTP-datakanaal | Betrouwbare, geordende levering van stukken | Vervoert ze (versleuteld) | IETF RFC 8831 |
Ze worden allemaal kort uitgelegd in de woordenlijst.
Wanneer wordt een TURN-relay gebruikt, en wat ziet hij?
Een relay is de terugvaloptie, niet de standaard. ICE gebruikt hem alleen als geen enkel direct kandidatenpaar verbinding maakt — meestal op netwerken met symmetrische NAT (sommige mobiele providers), bedrijfsfirewalls die uitgaand UDP-verkeer blokkeren, of bepaalde VPN's.
Als een directe verbinding niet mogelijk is (strenge bedrijfsfirewall, sommige mobiele netwerken), loopt de versleutelde stroom via een relayserver (TURN) van StrongFolder. De relay stuurt de gegevens alleen door en slaat ze niet op.
De relay ontvangt met DTLS versleutelde pakketten en geeft ze door. Hij kan zien dat er verkeer stroomt, hoeveel en wanneer — niet wat erin zit. Een overdracht via de relay kan trager zijn dan een directe, omdat elke byte een extra omweg via de relay maakt. Is een overdracht ongewoon traag, probeer dan een ander netwerk: een hotspot op je telefoon of wifi thuis maakt vaak wel direct verbinding waar een kantoornetwerk dat niet doet.
Gratis · in je browser · zonder aanmelden
Hoe veilig is de versleuteling van WebRTC?
WebRTC maakt versleuteling verplicht: je kunt op geen enkele manier een onversleuteld datakanaal openen. DTLS gebruikt moderne cijfers die de twee browsers onderling afspreken, en voor elke verbinding worden nieuwe sleutels gemaakt.
Er is één eerlijke kanttekening die voor elke WebRTC-dienst geldt. De twee browsers controleren elkaar via vingerafdrukken van certificaten die via de signaleringsserver worden uitgewisseld. Je vertrouwt er dus op dat de signalering van de dienst daar niet mee knoeit. Daarom omschrijft StrongFolder zijn bescherming als versleuteling tijdens de overdracht — niet als end-to-end-versleuteling met sleutels die jij beheert, en niet als "zero-knowledge". Voor een breder beeld van wat "veilig" betekent, lees Veilig bestanden delen en Beveiliging & privacy.
Waarom moet de browser van de afzender open blijven?
Omdat de browser van de afzender de bron is. Er is geen kopie op een server om op terug te vallen: het datakanaal leest alleen stukken van de schijf van de afzender zolang het tabblad open is en het apparaat wakker is. Het browsertabblad van de afzender moet open en online blijven tot de ontvanger klaar is met downloaden — de bestanden komen van het apparaat van de afzender, niet van een server. Hoe je daar rekening mee houdt, lees je in Waarom de afzender online blijft.
Hoe snel is bestandsoverdracht via WebRTC?
Er is geen vaste snelheid. Het plafond is de traagste schakel op het pad: meestal de uploadsnelheid van de afzender. Als vuistregel duurt 1 GB ongeveer 2,7 minuten bij 50 Mbit/s, ongeveer 80 seconden bij 100 Mbit/s en ruim minder dan een minuut op een snel lokaal netwerk. Echte overdrachten blijven wat onder deze cijfers door protocoloverhead, schijfsnelheid en, bij een relay, de extra tussenstap. Eén link kan door meerdere ontvangers worden geopend; elke ontvanger downloadt rechtstreeks van de afzender. Meerdere downloads tegelijk delen de upload van de afzender.
Samenvatting
Een bestandsoverdracht via WebRTC is een korte onderhandeling gevolgd door een lange, versleutelde stroom: signalering stelt de browsers aan elkaar voor, STUN en ICE zoeken een pad door NAT, TURN stuurt door als laatste redmiddel, en met DTLS versleutelde datakanalen brengen het bestand van schijf naar schijf. Voor de praktische kant — wat dit voor jou als afzender betekent — begin je met P2P-bestandsoverdracht in de browser en Hoe StrongFolder werkt.