Peer-to-Peer-Dateiübertragung mit Verschlüsselung: Technik-Guide
Bauen Sie verschlüsselte Peer-to-Peer-Systeme zur Dateiübertragung: NAT-Traversal, Signaling-Server und Ende-zu-Ende-Verschlüsselung umsetzen.
Peer-to-Peer-Dateiübertragung sendet Bytes direkt zwischen zwei Browsern oder Geräten, ohne dass die Datei je einen Server berührt. WebRTC, standardisiert in RFCs 8825 bis 8837, liefert den Transport: verschlüsselte Datenkanäle über UDP mit DTLS 1.3, NAT-Traversal via ICE, STUN und TURN, und Signaling über WebSocket oder HTTP. Das TTDSG und die DSGVO stellen klar, dass Dienste, die keine Nutzerdaten speichern, weniger Compliance-Aufwand bedeuten — P2P-Transfer ohne Server-Speicherung ist hier strukturell überlegen. Tools wie Snapdrop, Wormhole.app und Magic Wormhole beweisen, dass das Modell funktioniert. Hier ist der Aufbau: Signaling-Handshake, NAT-Traversal-Fallen, Verschlüsselungs-Layering und was man gegenüber Cloud-Relay-Diensten gewinnt oder verliert.
Warum P2P für Dateiübertragung
Die Attraktivität ist einfach: kein Server speichert die Datei, keine Bandbreitenrechnung für den Transferdienst, und der Upload des Senders IST der Download des Empfängers ohne Zwischenkopie. Für eine 10-GB-Übertragung zwischen zwei Nutzern im selben Gigabit-LAN kann P2P in 80 Sekunden fertig sein, während ein Cloud-Relay auf einen entfernten Server hochladen und wieder herunterladen würde, was Bandbreitennutzung und Latenz verdoppelt. Die Tradeoffs: beide Parteien müssen gleichzeitig online sein, NAT-Traversal schlägt gelegentlich fehl, und die Verbindung ist so schnell wie der Upload des langsameren Teilnehmers.
WebRTC-Datenkanäle als Transport
WebRTC begann als Video/Audio-Protokoll, aber RTCDataChannel bietet beliebigen binären Nachrichtentransport mit entweder zuverlässiger geordneter (wie TCP) oder unzuverlässiger ungeordneter (wie UDP) Lieferung. Unter der Haube laufen Datenkanäle über SCTP über DTLS 1.3 über UDP. Die DTLS-Schicht bietet Vertraulichkeit und authentifizierte Integrität via AES-128-GCM oder ChaCha20-Poly1305, ausgehandelt während des Handshakes. Für Dateiübertragung: einen zuverlässigen geordneten Kanal erstellen, die Datei in 16-KB- oder 64-KB-Nachrichten chunken (Chrome hat historisch die Nachrichtengröße auf 256 KB begrenzt) und sie sequenziell mit Flusskontrolle via bufferedAmount-Schwellenwert senden.
Die Rolle des Signaling-Servers
WebRTC benötigt einen Signaling-Server, um Verbindungsinformationen (SDP-Offers und -Answers, ICE-Kandidaten) zwischen Peers auszutauschen. Der Signaling-Server leitet keine Datei-Bytes weiter, nur ~5 KB Verbindungsmetadaten. Ein WebSocket-basierter Signaling-Service in Node.js, Python oder Go bewältigt dies in einigen Hundert Codezeilen. Firebase Realtime Database, Supabase Realtime und Pusher funktionieren alle als Signaling-Backends. Der Signaling-Server sieht, wer wann mit wem kommuniziert, aber nie den Dateiinhalt. Die meisten P2P-Dateiübertragungsdienste betreiben ihr Signaling kostenlos, da die Bandbreite trivial ist.
NAT-Traversal: STUN, TURN und ICE
Die meisten Geräte sitzen hinter NAT, was direkte IP-Verbindungen unmöglich macht. ICE (Interactive Connectivity Establishment, RFC 8445) versucht mehrere Verbindungspfade. STUN (RFC 8489) lässt einen Peer seine öffentliche IP und seinen Port via einem öffentlichen STUN-Server entdecken; Google betreibt stun.l.google.com kostenlos. Bei vernünftigen NATs (Full-Cone oder Restricted-Cone) funktioniert direkte UDP-Verbindung vielleicht in 70 Prozent der Versuche. Für symmetrische NATs, Unternehmens-Firewalls und CGNAT leitet TURN (RFC 8656) den Traffic über einen Server. TURN-Server sind teuer, da sie die eigentlichen Datei-Bytes tragen. Selbst gehostetes coturn, Twilio Stun oder Cloudflare Calls bieten Optionen. Im Feld erwarten: 10 bis 30 Prozent der P2P-Transfers fallen auf TURN zurück.
Verschlüsselungs-Layering auf DTLS
DTLS verschlüsselt WebRTC-Daten bereits, sodass zusätzliche Application-Layer-Verschlüsselung Gürtel-und-Hosenträger ist. Der DTLS-Handshake authentifiziert Peer-Zertifikate, aber WebRTC nutzt typischerweise selbst-signierte Zertifikate, die keine Identität verifizieren — sie verifizieren, dass die Verbindung zum selben Peer ist, der das SDP signiert hat. Application-Layer-Verschlüsselung mit AES-256-GCM und einem geteilten Geheimnis aus dem Signaling-Rendezvous fügt Identitätssicherheit hinzu. Magic Wormholes SPAKE2 PAKE (Password-Authenticated Key Exchange) leitet einen starken Schlüssel aus einer kurzen menschenlesbaren Phrase ab, sodass selbst ein kompromittierter Signaling-Server nicht entschlüsseln kann.
Chunking-Strategie für P2P-Dateiübertragung
WebRTC-Datenkanäle haben eine Nachrichtengrößenbeschränkung (256 KB in den meisten Browsern, mit Fragmentierung größerer Nachrichten, die aber unzuverlässig funktioniert). Dateien bei 16 KB bis 64 KB pro Nachricht chunken für Kompatibilität. bufferedAmount via bufferedAmountLowThreshold tracken, um Backpressure umzusetzen: Senden pausieren, wenn Buffer 1 MB überschreitet, fortsetzen, wenn er unter 256 KB fällt. Für Integrität jeden Chunk mit SHA-256 hashen und den Hash in einem zuerst gesendeten Manifest einschließen. Der Empfänger reassembliert, verifiziert Hashes und schreibt auf Disk via File System Access API oder Blob-Download.
Mobile und geräteübergreifende Überlegungen
Desktop-zu-Desktop P2P funktioniert gut. Mobile-zu-Desktop bringt Komplikationen: Mobile Browser erzwingen aggressives Tab-Suspendieren, sodass der Sender den Browser-Tab im Vordergrund halten muss. iOS Safaris Datenkanal-Implementierung war historisch weniger zuverlässig als Chromium. Hintergrund-Uploads auf Mobile erfordern App-gestützte Implementierungen. Batterie-Impact ist relevant: anhaltende WebRTC-Sessions entleeren Batterien schneller als HTTPS-Downloads. Für Mobile-zu-Mobile-Transfers im selben WLAN übertreffen AirDrop (iOS/macOS) und Nearby Share (Android) Browser-P2P durch direkte Geräteprotokolle.
Peer-Discovery ohne zentrale Accounts
Wie verbinden sich zwei Fremde ohne kontobasiertes System? Mehrere Patterns funktionieren. Ein Kurzcode wie Magic Wormholes „4-truck-roger" dient als Rendezvous-Adresse und Passwort; der Signaling-Server mappt Codes auf Sessions. QR-Codes, die eine Session-URL codieren, funktionieren für In-Person-Transfers. NFC-Tap-to-Connect auf Android verbindet via Nähe. Für größere Netzwerke kann eine DHT wie BitTorrents Mainline DHT die Peer-Discovery ohne zentralen Server bootstrappen, aber DHT-Lookups dauern Sekunden und eignen sich nicht für gelegentliches Datei-Sharing.
Sicherheitsbedrohungen spezifisch für P2P
P2P führt Bedrohungen ein, die Cloud-Relays nicht haben. IP-Adressen-Offenlegung: direkte Verbindungen enthüllen die öffentliche IP jedes Peers dem anderen, was in datenschutzsensiblen Kontexten (Whistleblowing, Aktivismus) problematisch ist. Einige P2P-Dienste erzwingen TURN-Relay, um IPs zu verbergen, auf Kosten der Performance. Malware-Verteilung ist schwerer zu moderieren, da der Dienstbetreiber nie Dateiinhalte sieht. DoS via Verbindungserschöpfung am Signaling-Server erfordert Rate-Limiting.
Wann Cloud-Relay trotzdem gewinnt
Für asynchrone Transfers, bei denen Sender und Empfänger nicht gleichzeitig online sind, versagt P2P völlig. Für große Transfers, die das Session-Fenster überschreiten (Mobile-Browser-Tabs schließen, Laptops schlafen), ist das Cloud-Relay-Modell „hochladen und Link teilen" einfach praktischer. Für Eins-zu-viele-Verteilung schlägt ein einziger Upload plus CDN-Fanout N gleichzeitige P2P-Sessions. HexaTransfer nutzt das Cloud-Relay-Modell mit clientseitiger AES-256-GCM-Verschlüsselung — Ende-zu-Ende-Verschlüsselung ist so gewährleistet, während asynchrone Transfers und Multi-Empfänger-Unterstützung erhalten bleiben.
Jetzt ausprobieren: https://hexatransfer.com — kostenlos, kein Account, bis zu 10 GB.
Große Dateien sicher mit Ende-zu-Ende-Verschlüsselung senden
Übertragen Sie Dateien bis zu 10 GB kostenlos mit Ende-zu-Ende-Verschlüsselung. Kein Konto erforderlich. Ihre Dateien werden in Ihrem Browser verschlüsselt, bevor sie hochgeladen werden — niemand sonst kann sie lesen.
Datei senden