LAN-Dateiübertragung

LAN File Transfer ermöglicht den Austausch von Dateien und Text zwischen zwei Geräten im selben lokalen Netzwerk über WebRTC-Peer-to-Peer-Verbindungen. Statt Daten zuerst auf einen externen Server hochzuladen, wird nach dem Verbindungsaufbau direkt zwischen den beteiligten Browsern übertragen. Das ist praktisch für Bürorechner, Testgeräte, Heimnetzwerke, Laborumgebungen oder Situationen, in denen USB-Sticks, Cloudspeicher und Chat-Anhänge unnötig umständlich wären. Die Geschwindigkeit hängt vom lokalen Netzwerk, den Browsern und den Geräteleistungen ab. Für vertrauliche Daten bleibt wichtig, nur mit dem richtigen Gegenüber zu verbinden und temporäre Sitzungen nach der Übertragung zu schließen. In Unternehmensnetzen können Firewall-Regeln, Gast-WLANs oder getrennte VLANs die Verbindung blockieren; bei Problemen hilft es, beide Geräte im selben Segment und mit freigegebenem Browserzugriff zu prüfen.

Die LAN-Dateiübertragung basiert auf WebRTC (Web Real-Time Communication), dem W3C/IETF-Standard definiert in RFC 8825-8835, der ursprünglich für browserbasierte Echtzeit-Audio- und -Videoübertragung entwickelt wurde. Dieselbe Peer-to-Peer-Technik unterstützt die RTCDataChannel-API, die beliebige binäre Nutzdaten zwischen zwei Browsern überträgt, ohne dass ein Relay-Server im Datenpfad liegt. Die Signalisierung, die den Kanal öffnet, übernimmt der QR-Code-Handshake: Der Initiator erzeugt ein SDP- (Session Description Protocol, RFC 8866) Blob, das seine Medien- und Datenfähigkeiten beschreibt, kodiert es in einer URL oder einem QR-Code, und der Antwortende gibt ein Gegen-SDP zurück. Sobald beide Seiten die entfernte Beschreibung angewendet haben, sammelt ICE (Interactive Connectivity Establishment, RFC 8445) Kandidaten-Transportadressen. Jeder Kandidat ist ein (IP, Port, Protokoll)-Tupel plus einer Priorität: Host-Kandidaten (die eigene LAN-IP des Geräts) gewinnen im selben Netzwerk in der Regel, aber srflx (server-reflexive, ermittelt über eine STUN-Binding-Anfrage) und Relay- (TURN-relayed, RFC 8656) Kandidaten werden in Prioritätsreihenfolge ausprobiert. Konnektivitätsprüfungen senden STUN-Binding-Anfragen zwischen Kandidaten; das erste erfolgreiche Paar wird zum ausgewählten Kandidatenpaar. Sobald ICE den Zustand „connected" erreicht hat, authentifiziert DTLS (Datagram Transport Layer Security, RFC 6347, der UDP-freundliche Verwandte von TLS 1.2/1.3 in RFC 5246/8446) beide Peers anhand der Zertifikat-Hashes im SDP und führt einen One-RTT-Handshake durch. Die DTLS-Sitzungsschlüssel schützen dann jedes SCTP- (Stream Control Transmission Protocol, RFC 4960/RFC 9260) Paket darüber, und jeder DataChannel ist ein Paar von SCTP-Streams über dieser einzelnen DTLS-Assoziation. Große Dateien werden in Chunks über den DataChannel gesendet. Die SCTP-Schicht des Browsers fragmentiert jede Nachricht in etwa 16 KB große Records (die Standard-SCTP-Minus die DTLS- + SCTP- + Chunk-Header-Overhead, und pro Implementierung anpassbar, oft 16 KB oder 64 KB je nach Engine), und der Empfänger setzt sie in der Reihenfolge wieder zusammen. Fluss- und Staukontrolle (RFC 4960 §6) verhindern, dass der Sender den Empfänger überflutet: cwnd wächst additiv bei ACK und schrumpft multiplikativ bei Verlust – dieselbe Form wie TCPs AIMD, aber angewendet pro SCTP-Assoziation. In einem Gigabit-LAN liegt der End-to-End-Durchsatz in der Regel bei 200–400 MB/s, begrenzt durch die Encoding-Kosten des Browser-Main-Threads (jeden Chunk in eine ArrayBuffer-Ansicht umwandeln und in den SCTP-Stack einspeisen), nicht durch die Leitungsgeschwindigkeit. Die Seite setzt eingehende Chunks zu einem einzelnen Blob zusammen und bietet es als Download an, sodass der Nutzer entscheiden kann, wohin die Bytes landen – das verhindert, dass der Empfänger im Spitzenfall Gigabyte im Speicher hält. Da die Daten Peer-to-Peer über DTLS-SRTP-artige Verschlüsselung fließen, sehen Zwischenrouter und Relay-Server nur Chiffretext; der Betreiber der Seite sieht nie den Klartext, und es gibt keinen Upload-Schritt. Der Kompromiss ist der Signalisierungsserver, der für den SDP-Austausch benötigt wird – diese Seite verwendet QR-Codes und Kopier-Einfüge-Links als manuellen, serverlosen Signalisierungskanal, weshalb zwei Scans erforderlich sind.

• WebRTC ist ein W3C/IETF-Standard (RFC 8825-8835), der drei Engines bündelt: SDP für die Aushandlung, ICE für die Kandidatensammlung und DTLS-SRTP / DTLS-SCTP für die Transportsicherheit.
• Der QR-Code-Handshake ist serverlose Signalisierung: Der Initiator veröffentlicht ein SDP-Offer, der Antwortende gibt ein SDP-Answer zurück, und kein zentraler Server sieht jemals den Datenpfad.
• ICE (RFC 8445) sammelt Host-, srflx- (STUN-reflexive), prflx- (peer-reflexive) und Relay- (TURN, RFC 8656) Kandidaten; das prioritätshöchste Paar, das die Konnektivitätsprüfungen besteht, wird zum ausgewählten Transport.
• DTLS (RFC 6347) führt einen One-RTT-Fingerprint-verifizierten Handshake durch, indem es die im SDP verankerten Zertifikat-Hashes verwendet, und verschlüsselt dann jedes Byte auf der Leitung – kein HTTP- oder WebSocket-Fallback.
• DataChannel läuft auf SCTP-over-DTLS, nicht auf rohem UDP: SCTP bietet geordnete, zuverlässige, nachrichtenorientierte Streams mit Staukontrolle (RFC 4960 §6) auf einem UDP-Socket.
• Die Chunk-Größe beträgt standardmäßig etwa 16 KB (browserabhängig, manchmal 64 KB): Der Empfänger setzt die Chunks zu einem einzelnen Blob zusammen und löst einen Download aus, um zu vermeiden, dass die gesamte Datei im Speicher gehalten wird.
• Der Browser-Speicher ist die eigentliche Grenze: Eine 1-GB-Datei bedeutet etwa 1 GB ArrayBuffer-Umschlag, daher liegt die praktische Grenze auf Mobilgeräten in der Regel bei 200–500 MB pro Übertragung, nicht bei der Netzwerkgeschwindigkeit.
• Die WebRTC-NAT-Traversal benötigt einen STUN/TURN-Server für peers in verschiedenen Netzwerken; diese Seite geht von einer gleichen-LAN-Topologie aus, sodass Host-Kandidaten (LAN-IPs) in der Regel gewinnen und kein STUN-Server abgefragt wird.