Peer-to-peer versleutelde bestandsoverdracht: technische gids
Bouw peer-to-peer versleutelde bestandsoverdrachtsystemen. NAT-traversal, signaleringsservers en end-to-end versleutelingsimplementatie in detail.
Peer-to-peer bestandsoverdracht stuurt bytes rechtstreeks tussen twee browsers of apparaten zonder dat het bestand ooit een server raakt. WebRTC, gestandaardiseerd in RFC's 8825 tot 8837, levert het transport: versleutelde datakanalen over UDP met DTLS 1.3, NAT-traversal via ICE, STUN en TURN, en signalering via WebSocket of HTTP. De AVG en het NCSC benadrukken dat gegevensminimalisatie en privacy by design wettelijke vereisten zijn — P2P-architecturen waarbij geen kopie op een server verblijft, zijn een directe uitdrukking van die principes. Tools zoals Snapdrop, Wormhole.app en Magic Wormhole bewijzen dat het model werkt. Hieronder de opbouw: de signaleringshandshake, NAT-traversal-valkuilen, versleutelingslagen en wat je wint of verliest ten opzichte van cloudgebaseerde overdrachtsservices.
Waarom P2P voor bestandsoverdracht
De aantrekkingskracht is eenvoudig: geen server slaat je bestand op, geen bandbreedterekening voor de overdrachtsservice, en de upload van de afzender IS de download van de ontvanger zonder tussenliggende kopie. Voor een overdracht van 10 GB tussen twee gebruikers op hetzelfde gigabit-LAN kan P2P in 80 seconden klaar zijn, terwijl een cloudrelay uploadt naar een verre server en vervolgens opnieuw downloadt, het bandbreedtegebruik verdubbelt en de latentie vergroot. Privacy is ook een voordeel — de bestandsbytes bestaan alleen op de apparaten van afzender en ontvanger. De afwegingen: beide partijen moeten tegelijkertijd online zijn, NAT-traversal mislukt soms en de verbinding is zo snel als de langzamere uploadverbinding van de deelnemers.
WebRTC-datakanalen als transport
WebRTC begon als een video/audio-protocol, maar RTCDataChannel biedt willekeurig binair bericht-transport met ofwel betrouwbare geordende (zoals TCP) ofwel onbetrouwbare ongeordende (zoals UDP) levering. Onder de motorkap draaien datakanalen over SCTP over DTLS 1.3 over UDP. De DTLS-laag biedt vertrouwelijkheid en geauthenticeerde integriteit via AES-128-GCM of ChaCha20-Poly1305, onderhandeld tijdens de handshake. Maak voor bestandsoverdracht een betrouwbaar geordend kanaal, splits het bestand in berichten van 16 KB of 64 KB (Chrome heeft historisch berichtgroottes beperkt tot 256 KB), en stuur ze sequentieel met flow control via de gebufferde-hoeveelheidsdrempel.
De rol van de signaleringsserver
WebRTC heeft een signaleringsserver nodig om verbindingsinfo — SDP-aanbiedingen en antwoorden, ICE-kandidaten — tussen peers uit te wisselen. De signaleringsserver geeft geen bestandsbytes door, slechts ~5 KB aan verbindingsmetadata. Een WebSocket-gebaseerde signaleringsservice in Node.js, Python of Go regelt dit in een paar honderd regels code. Firebase Realtime Database, Supabase Realtime en Pusher werken allemaal als signaleringsbackend. De signaleringsserver ziet wie met wie communiceert en wanneer, maar nooit de bestandsinhoud. De meeste P2P-bestandsoverdrachtsservices draaien hun signalering gratis omdat de bandbreedte verwaarloosbaar is.
NAT-traversal: STUN, TURN en ICE
De meeste apparaten zitten achter NAT, waardoor directe IP-verbindingen onmogelijk zijn. ICE (Interactive Connectivity Establishment, RFC 8445) probeert meerdere verbindingspaden. STUN (RFC 8489) laat een peer zijn publieke IP en poort ontdekken via een publieke STUN-server; Google draait stun.l.google.com gratis. Als beide peers redelijke NAT's hebben (full-cone of restricted-cone), werkt een directe UDP-verbinding — misschien 70 procent van de pogingen. Voor symmetrische NAT's, bedrijfsfirewalls en CGNAT stuurt TURN (RFC 8656) verkeer via een server. TURN-servers zijn duur omdat ze de daadwerkelijke bestandsbytes vervoeren. Zelf-gehoste coturn, twilio.com/stun of Cloudflare Calls bieden opties. Verwacht dat 10 tot 30 procent van P2P-overdrachten in de praktijk terugvalt op TURN.
Versleuteling gelaagd bovenop DTLS
DTLS versleutelt WebRTC-data al, dus extra versleuteling op applicatieniveau is riem-én-bretels. De DTLS-handshake authenticeert peer-certificaten, maar WebRTC gebruikt doorgaans zelf-ondertekende certificaten die geen identiteit verifiëren — ze verifiëren dat de verbinding met dezelfde peer is als die het SDP heeft ondertekend. Versleuteling op applicatieniveau met AES-256-GCM en een gedeeld geheim afgeleid van het signaleringsrendez-vous voegt identiteitsborging toe. Magic Wormhole's SPAKE2 PAKE (Password-Authenticated Key Exchange) leidt een sterke sleutel af uit een kort, voor mensen leesbare zin, zodat zelfs een gecompromitteerde signaleringsserver niet kan ontsleutelen.
Chunkingstrategie voor P2P-bestandsoverdracht
WebRTC-datakanalen hebben een berichtgroottebegrenzing (256 KB in de meeste browsers, met fragmentatie van grotere berichten die werkt maar onbetrouwbaar is). Split bestanden bij 16 KB tot 64 KB per bericht voor compatibiliteit. Volg de gebufferde hoeveelheid via bufferedAmount en bufferedAmountLowThreshold om tegendruk te implementeren — pauzeer het verzenden wanneer de buffer 1 MB overschrijdt, hervat wanneer hij daalt onder 256 KB. Voor integriteit: hash elke chunk met SHA-256 en voeg de hash toe aan een manifest dat eerst wordt verstuurd. De ontvanger stelt samen, verifieert hashes en schrijft naar schijf via de File System Access API of een Blob-download.
Mobiele en cross-device overwegingen
Desktop-naar-desktop P2P werkt goed. Mobiel-naar-desktop introduceert complicaties: mobiele browsers hanteren agressieve tabbladonderbreking, zodat de afzender het browsertabblad op de voorgrond moet houden. De datakanaalimplementatie van iOS Safari is historisch gezien minder betrouwbaar dan Chromium. Achtergrond-uploads op mobiel vereisen app-backed implementaties. Batterij-impact telt ook — aanhoudende WebRTC-sessies ontladen batterijen sneller dan HTTPS-downloads. Voor mobiel-naar-mobiel overdrachten op hetzelfde Wi-Fi overtreffen AirDrop (iOS/macOS) en Nearby Share (Android) browser-P2P door directe apparaatprotocollen te gebruiken.
Peer-ontdekking zonder centrale accounts
Hoe verbinden twee vreemden zonder een op accounts gebaseerd systeem? Verschillende patronen werken. Een korte code zoals Magic Wormhole's "4-vrachtwagen-roger" dient als zowel rendez-vous-adres als wachtwoord; de signaleringsserver koppelt codes aan sessies. QR-codes die een sessie-URL coderen werken voor persoonlijke overdrachten. NFC tap-to-connect op Android verbindt via nabijheid. Voor grotere netwerken kan een DHT zoals BitTorrent's Mainline DHT peer-ontdekking bootstrappen zonder een centrale server, maar DHT-opzoekingen duren seconden en passen niet goed bij toevallige bestandsdeling.
Beveiligingsbedreigingen specifiek voor P2P
P2P introduceert bedreigingen die cloudrelays niet hebben. IP-adresonthulling: directe verbindingen onthullen het publieke IP van elke peer aan de ander, wat gebruikers kan deanonimiseren in privacygevoelige contexten — klokkenluiders, activisten. Sommige P2P-services dwingen TURN-relay af om IP's te verbergen ten koste van prestaties. Malware-distributie is moeilijker te modereren omdat de servicebeheerder de bestandsinhoud nooit ziet. Denial-of-service via verbindingsuitputting op de signaleringsserver vereist tariefbeperking. Voor extra-gevoelige overdrachten kan een Tor-onion-service de signalering afschermen om beide IP's te verbergen tegen zware latentiekosten.
Realiteitscheck van prestaties
P2P-snelheid is begrensd door de uploadbandbreedte van de langzamere peer en de round-trip-latentie. Op woningaansluitingen zijn uploadplafonds vaak 20 tot 50 Mbps, ook al is de download gigabit. Een P2P-overdracht van 10 GB van een thuisupload van 20 Mbps naar een gigabit-ontvanger duurt minimaal 68 minuten. Cloudrelay met een snelle uplink en CDN-backed download kan dat verslaan door eenmalig te uploaden naar een goed verbonden server. P2P wint voor overdrachten op hetzelfde LAN (gigabit of sneller), gevoelige data waarbij geen server-side kopie acceptabel is, en kostenoptimalisatie wanneer bandbreedte-rekeningen pijnlijk zouden zijn.
Wanneer cloudrelay nog steeds wint
Voor asynchrone overdrachten waarbij afzender en ontvanger niet tegelijkertijd online zijn, faalt P2P volledig — er is geen peer om te ontvangen. Voor grote overdrachten die de sessievenster overschrijden — mobiele browsertabbladen sluiten, laptops slapen — is het "upload en deel een link"-model van cloudrelay simpelweg praktischer. Voor één-naar-velen-distributie verslaat een enkele upload plus CDN-fanout het uitvoeren van N gelijktijdige P2P-sessies. HexaTransfer gebruikt het cloudrelaymodel met client-side AES-256-GCM-versleuteling, waardoor het grootste deel van het privacyvoordeel van P2P wordt bereikt met veel betere asynchrone en multi-ontvanger-ondersteuning.
Probeer het op https://hexatransfer.com — gratis, geen account, maximaal 10 GB.
Verstuur grote bestanden veilig met end-to-end-versleuteling
Draag bestanden tot 10 GB gratis over met end-to-end-versleuteling. Geen account nodig. Uw bestanden worden in uw browser versleuteld voordat ze worden geüpload — niemand anders kan ze lezen.
Een bestand verzenden