Mit der Dateiübertragung per WebRTC können sich zwei Browser eine Datei schicken, ohne sie in einen Cloud-Speicher hochzuladen. Das klingt einfach, aber das Internet wurde nicht dafür gebaut, dass sich zwei Heimcomputer direkt anrufen. Diese Anleitung erklärt verständlich, was tatsächlich passiert – Signaling, NAT, STUN, ICE, TURN, DTLS und Datenkanäle –, am Beispiel von StrongFolder.
Was ist WebRTC?
WebRTC (Web Real-Time Communication) ist eine Sammlung von Browser-APIs und Netzwerkprotokollen, standardisiert von W3C und IETF, für Echtzeitverbindungen zwischen Browsern. Chrome, Edge, Firefox, Safari und Opera unterstützen es alle. Gebaut wurde es für Video- und Sprachanrufe, aber es hat auch Datenkanäle, die beliebige Binärdaten transportieren – und genau das ist eine Datei.
Die entscheidende Eigenschaft: Steht eine WebRTC-Verbindung einmal, fließen die Daten zwischen den beiden Endpunkten und nicht in den Speicher eines Servers. Das macht P2P-Dateiübertragung im Browser möglich.
Warum können sich zwei Browser nicht einfach direkt verbinden?
Weil fast kein Gerät eine eigene öffentliche Adresse hat. Ihr Laptop sitzt hinter einem Heimrouter, einer Firmen-Firewall oder dem Netz eines Mobilfunkanbieters. Der Router führt NAT (Network Address Translation) durch: Viele private Geräte teilen sich eine öffentliche IP-Adresse, und der Router lässt nur Verkehr herein, der auf etwas antwortet, das von innen gesendet wurde.
Zwei Browser stehen also vor drei Problemen, bevor Dateidaten fließen können:
- Sie wissen nicht, wie sie einander erreichen – keiner weiß, dass der andere existiert.
- Sie kennen ihre eigene öffentliche Adresse nicht – nur die private, etwa 192.168.1.20.
- Ihre Router blockieren unaufgeforderten eingehenden Verkehr möglicherweise.
WebRTC löst jedes Problem mit einem eigenen Mechanismus.
Wie läuft eine WebRTC-Dateiübertragung Schritt für Schritt ab?
Hier der vollständige Ablauf, vom Klick auf „Teilen“ bis zum letzten 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
Schritt 1–2 – Signaling. Der Absender wählt Dateien; der Dienst speichert die für den Link nötigen Metadaten. Öffnet der Empfänger den Link, sind beide Browser mit einem Signaling-Server verbunden. WebRTC legt nicht fest, wie Signaling funktioniert; StrongFolder nutzt PeerJS mit einem eigenen Signaling-Server.
Schritt 3 – Angebot und Antwort. Ein Browser erstellt ein Angebot (Offer) in SDP (Session Description Protocol): „Ich möchte einen Datenkanal, hier sind mein Verschlüsselungs-Fingerabdruck und meine Fähigkeiten.“ Der andere antwortet mit einer Antwort (Answer). Beide laufen über den Signaling-Server.
Schritt 4 – STUN. Jeder Browser fragt einen STUN-Server: „Von welcher Adresse und welchem Port komme ich bei dir an?“ Die Antwort ist seine öffentliche Adresse, wie der Router sie zuordnet. STUN-Server bearbeiten eine winzige Anfrage und keine Dateidaten; StrongFolder nutzt öffentliche STUN-Server, darunter die von Google, und eigene.
Schritt 5 – ICE-Kandidaten. Jeder Browser sammelt Kandidaten – mögliche Wege, ihn zu erreichen: seine lokale Netzwerkadresse (host), seine öffentliche Adresse laut STUN (server-reflexive) und eine Adresse auf einem TURN-Relay (relayed). Sie tauschen die Kandidaten über das Signaling aus.
Schritt 6 – Verbindungsprüfungen. ICE (Interactive Connectivity Establishment) testet Kandidatenpaare und wählt das beste funktionierende. Sind beide Geräte im selben WLAN, gewinnt ein lokaler Weg. Erlauben es die Router, gewinnt ein direkter Internetweg („Hole Punching“). Funktioniert nichts Direktes, wird der Weg über das Relay genutzt.
Schritt 7 – DTLS. Bevor Daten fließen, führen die Browser einen DTLS-Handshake durch (TLS, angepasst für UDP) und prüfen, ob die Fingerabdrücke der Zertifikate mit denen in Angebot und Antwort übereinstimmen. Ab jetzt ist alles verschlüsselt.
Schritt 8 – Datenkanal. Über DTLS läuft SCTP, das dem Datenkanal eine zuverlässige, geordnete Zustellung gibt. Bei StrongFolder fordert der Browser des Empfängers eine Datei an, der Browser des Absenders liest sie stückweise von der Festplatte und sendet die Stücke, und der Empfänger schreibt jedes Stück auf die Festplatte, sobald es ankommt – so müssen selbst sehr große Dateien nie in den Arbeitsspeicher passen.
Was bedeuten STUN, TURN, ICE und die anderen Begriffe?
| Begriff | Was er tut | Sieht Dateidaten? | Standard |
|---|---|---|---|
| Signaling | Reicht Angebote, Antworten und Kandidaten zwischen Browsern weiter | Nein | Nicht standardisiert (anwendungsspezifisch) |
| NAT | Routerfunktion, die eine öffentliche IP auf viele Geräte aufteilt | — | — |
| STUN | Sagt einem Browser seine öffentliche Adresse und seinen Port | Nein | IETF RFC 8489 |
| ICE | Sammelt Kandidaten und wählt einen funktionierenden Weg | Nein | IETF RFC 8445 |
| TURN | Leitet Verkehr weiter, wenn kein direkter Weg funktioniert | Nur verschlüsselte Pakete | IETF RFC 8656 |
| DTLS | Verschlüsselt die Verbindung (TLS für UDP) | Verschlüsselt sie | IETF RFC 9147 (1.3), RFC 6347 (1.2) |
| SCTP-Datenkanal | Zuverlässige, geordnete Zustellung der Stücke | Transportiert sie (verschlüsselt) | IETF RFC 8831 |
Alle diese Begriffe werden im Glossar kurz erklärt.
Wann wird ein TURN-Relay genutzt, und was sieht es?
Ein Relay ist der Ausweichweg, nicht der Normalfall. ICE nutzt es nur, wenn sich kein direktes Kandidatenpaar verbindet – typischerweise in Netzwerken mit symmetrischem NAT (manche Mobilfunkanbieter), Firmen-Firewalls, die ausgehendes UDP blockieren, oder bestimmten VPNs.
Ist keine direkte Verbindung möglich (strenge Firmen-Firewall, manche Mobilfunknetze), läuft der verschlüsselte Datenstrom über einen Relay-Server (TURN) von StrongFolder. Das Relay leitet die Daten nur weiter und speichert sie nicht.
Das Relay empfängt DTLS-verschlüsselte Pakete und reicht sie weiter. Es kann sehen, dass Daten fließen, wie viele und wann – nicht, was darin steckt. Eine Übertragung über das Relay kann langsamer sein als eine direkte, weil jedes Byte einen zusätzlichen Weg über das Relay nimmt. Ist eine Übertragung ungewöhnlich langsam, versuchen Sie ein anderes Netzwerk: Ein Handy-Hotspot oder das Heim-WLAN verbindet sich oft direkt, wo ein Büronetz es nicht tut.
Kostenlos · im Browser · ohne Anmeldung
Wie sicher ist die Verschlüsselung von WebRTC?
WebRTC macht Verschlüsselung zur Pflicht: Es gibt keine Möglichkeit, einen unverschlüsselten Datenkanal zu öffnen. DTLS nutzt moderne Verschlüsselungsverfahren, die die beiden Browser aushandeln, und für jede Verbindung werden neue Schlüssel erzeugt.
Es gibt einen ehrlichen Vorbehalt, der für jeden WebRTC-Dienst gilt. Die beiden Browser prüfen einander über Zertifikats-Fingerabdrücke, die über den Signaling-Server ausgetauscht werden. Sie vertrauen also darauf, dass das Signaling des Dienstes sie nicht manipuliert. Deshalb beschreibt StrongFolder seinen Schutz als Verschlüsselung während der Übertragung – nicht als Ende-zu-Ende-Verschlüsselung mit Schlüsseln in Ihrer Hand und nicht als „Zero-Knowledge“. Einen breiteren Blick darauf, was „sicher“ bedeutet, bieten Dateien sicher teilen und Sicherheit & Datenschutz.
Warum muss der Browser des Absenders geöffnet bleiben?
Weil der Browser des Absenders die Quelle ist. Es gibt keine Server-Kopie als Rückfallebene: Der Datenkanal liest Stücke von der Festplatte des Absenders nur, solange der Tab geöffnet und das Gerät wach ist. Der Browser-Tab des Absenders muss geöffnet und online bleiben, bis der Empfänger den Download abgeschlossen hat – die Dateien kommen vom Gerät des Absenders, nicht von einem Server. Wie Sie das einplanen, steht unter Warum der Absender online bleiben muss.
Wie schnell ist eine Dateiübertragung per WebRTC?
Eine feste Geschwindigkeit gibt es nicht. Die Obergrenze ist die langsamste Verbindung auf dem Weg: meist die Upload-Geschwindigkeit des Absenders. Als Faustregel dauert 1 GB bei 50 Mbit/s etwa 2,7 Minuten, bei 100 Mbit/s etwa 80 Sekunden und in einem schnellen lokalen Netzwerk deutlich unter einer Minute. Echte Übertragungen liegen etwas darunter – wegen Protokoll-Overhead, Festplattengeschwindigkeit und, bei einem Relay, des zusätzlichen Wegs. Ein Link kann von mehreren Empfängern geöffnet werden; jeder lädt direkt vom Absender herunter. Mehrere gleichzeitige Downloads teilen sich den Upload des Absenders.
Zusammenfassung
Eine WebRTC-Dateiübertragung ist eine kurze Verhandlung, gefolgt von einem langen, verschlüsselten Datenstrom: Signaling macht die Browser bekannt, STUN und ICE finden einen Weg durch NAT, TURN leitet als letzte Möglichkeit weiter, und DTLS-verschlüsselte Datenkanäle tragen die Datei von Festplatte zu Festplatte. Für die praktische Seite – was das für Sie als Absender bedeutet – beginnen Sie mit P2P-Dateiübertragung im Browser und So funktioniert StrongFolder.