# Hoe bestandsoverdracht via WebRTC werkt

Source: https://help.strongfolder.com/nl/guides/how-webrtc-file-transfer-works/
Updated: 2026-11-05

> Bestandsoverdracht via WebRTC verloopt in drie fasen. Een signaleringsserver stelt twee browsers aan elkaar voor; STUN en ICE zoeken een netwerkpad door thuisrouters (NAT), met een TURN-relay als terugvaloptie als er geen direct pad is; daarna openen de browsers een met DTLS versleuteld datakanaal en streamen het bestand in stukken, direct of via de relay, zonder het op te slaan.

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.

**Key facts**

- **WebRTC** is een browserstandaard voor directe, versleutelde verbindingen tussen twee apparaten; tools voor bestanden delen gebruiken de **datakanalen** ervan.
- **Signalering** stelt de browsers aan elkaar voor; **STUN** en **ICE** zoeken een pad door routers (**NAT**); een **TURN-relay** stuurt verkeer door als er geen direct pad is.
- **Versleuteling:** elk datakanaal gebruikt **DTLS** — WebRTC heeft geen onversleutelde modus.
- StrongFolder gebruikt PeerJS bovenop WebRTC, een eigen signaleringsserver van StrongFolder, openbare STUN-servers (waaronder die van Google) en eigen TURN-relays. Bestanden worden nooit naar een server van StrongFolder geüpload of daar opgeslagen.
- Het bestand stroomt in stukken van de schijf van de afzender naar de schijf van de ontvanger; de afzender blijft online.

## Wat is WebRTC?

[WebRTC](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/guides/p2p-file-transfer/) 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](https://help.strongfolder.com/en/glossary/#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:

1. Ze weten niet **hoe ze elkaar kunnen bereiken** — geen van beide weet dat de ander bestaat.
2. Ze kennen **hun eigen openbare adres** niet — alleen het privéadres, zoals 192.168.1.20.
3. 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](https://help.strongfolder.com/en/glossary/#signaling). 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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/).

## 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.

[Nu bestanden versturen](https://strongfolder.com)
## 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](https://help.strongfolder.com/en/guides/secure-file-sharing/) en [Beveiliging & privacy](https://help.strongfolder.com/en/security/).

## 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](https://help.strongfolder.com/en/guides/why-sender-stays-online/).

## Hoe snel is bestandsoverdracht via WebRTC?

Er is geen vaste snelheid. Het plafond is de traagste schakel op het pad: meestal de
**upload**snelheid 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](https://help.strongfolder.com/en/guides/p2p-file-transfer/) en
[Hoe StrongFolder werkt](https://help.strongfolder.com/en/how-it-works/).

## FAQ

### Wat is een WebRTC-datakanaal?

Een datakanaal is het deel van WebRTC dat willekeurige bytes tussen twee browsers vervoert in plaats van audio of video. Het draait SCTP over DTLS over UDP, dus het is versleuteld en kan worden ingesteld als betrouwbaar en geordend — precies wat bestandsoverdracht nodig heeft.

### Wat is het verschil tussen STUN en TURN?

Een STUN-server vertelt een browser alleen hoe zijn openbare adres eruitziet, zodat de twee browsers een directe verbinding kunnen proberen; er gaan geen bestandsgegevens doorheen. Een TURN-server is een relay: als geen direct pad werkt, gaat de versleutelde stroom erdoorheen. StrongFolder draait eigen TURN-relays, die gegevens doorsturen en niet opslaan.

### Ziet de signaleringsserver mijn bestanden?

Nee. De signaleringsserver geeft alleen verbindingsberichten door — sessiebeschrijvingen en netwerkkandidaten — tussen de browsers. Bestandsgegevens gaan via het datakanaal, direct of via een TURN-relay.

### Is bestandsoverdracht via WebRTC versleuteld?

WebRTC versleutelt elk datakanaal met DTLS, dus de bestandsstroom is bij elke verbinding versleuteld tijdens de overdracht. WebRTC staat geen onversleutelde datakanalen toe. De sleutels worden door de twee browsers onderhandeld; hun vingerafdrukken gaan via de signalering, en daarom is dit versleuteling tijdens de overdracht en geen end-to-end-versleuteling met sleutels die je zelf beheert.

### Waarom mislukt een WebRTC-overdracht soms of blijft hij traag?

Meestal door het netwerkpad: een strenge firewall of VPN blokkeert direct UDP-verkeer, zodat de verbinding terugvalt op een TURN-relay via TCP, of helemaal geen verbinding kan maken. Probeer een ander netwerk (bijvoorbeeld een hotspot op je telefoon), zet de VPN uit of vraag IT om WebRTC toe te staan.

### Kan een TURN-relay mijn bestanden lezen?

De relay stuurt met DTLS versleutelde pakketten tussen de twee browsers door. Hij ziet versleuteld verkeer, groottes en tijdstippen, niet de inhoud van het bestand, en de relay van StrongFolder slaat niet op wat hij doorstuurt.