Latenz ist nicht gleich Bandbreite – und Lichtgeschwindigkeit lässt sich nicht verhandeln
Die Zahl der Menschen, die Bandbreite mit Latenz verwechseln – und dabei die physikalischen Grenzen der Lichtgeschwindigkeit ignorieren – scheint nicht kleiner zu werden. Besonders im Unternehmensumfeld sorgt dieses Missverständnis immer wieder für Frustration, wenn Datenübertragungen zwischen entfernten Standorten unerwartet langsam sind.
Typischerweise heißt es:
„Wir haben doch eine Gigabit-Strecke zwischen Hamburg und München – das Kopieren von ein paar Gigabyte sollte doch kein Problem sein!“
Doch in der Praxis zeigt sich schnell: Die Übertragung ist zäh, die Verbindung fühlt sich langsam an, und am Ende gehen nur ein paar Hundert Megabit oder weniger durch die Leitung.
Wer ist schuld?
Der erste Verdacht fällt meist auf den Leitungsanbieter – der soll bitte die (teure) Glasfaserleitung prüfen. Nach Tagen oder Wochen und vielen Mails und Telefonaten lautet die ernüchternde Antwort: „Die Leitung funktioniert einwandfrei, alle Parameter sind in Ordnung.“
Der nächste Weg führt dann zur internen IT oder zum Softwareanbieter. Doch auch dort ist das Problem kaum zu greifen – die Infrastruktur ist technisch korrekt, die Systeme sind gesund.
Und trotzdem ist das Netz „langsam“. Was passiert hier?
Der wahre Schuldige: Latenz
Sobald größere Entfernungen ins Spiel kommen, verschiebt sich der Engpass oft weg von der Bandbreite – hin zur Latenz.
Bandbreite ist die maximale Datenmenge, die pro Zeiteinheit übertragen werden kann.
Latenz ist die Verzögerung, bis ein Datenpaket sein Ziel erreicht (One-Way) oder hin und zurück übertragen wurde (Round Trip Time, RTT).
In lokalen Netzwerken ist die RTT oft kleiner als 1 Millisekunde. Doch bei Weitverkehrsverbindungen (WAN) sind 10–30 Millisekunden völlig normal – auch auf Glasfaser.
Warum ist Latenz unvermeidlich?
Hier kommen die Naturgesetze ins Spiel:
- Lichtgeschwindigkeit im Vakuum: 299.792.458 m/s
- Lichtgeschwindigkeit in Glasfaser: ca. 200.000 km/s (wegen des Brechungsindex)
- Strecke Hamburg – München (Luftlinie): ca. 750 km
- Tatsächliche Leitungslänge: meist 900–1.100 km wegen Trassenführung
Berechnung der theoretischen Mindest-Latenz:
1.000 km Leitung / 200.000 km/s = 5 ms (one-way)
→ Round Trip Time (RTT) = 10 ms – unter Idealbedingungen!
Hinzu kommen:
- Router- und Switch-Verzögerungen
- Pufferung, TCP Congestion Control, QoS-Mechanismen
- Protokoll-Overhead
Ergebnis: 10–20 ms RTT zwischen zwei deutschen Standorten sind realistisch, bei internationalen Verbindungen deutlich mehr.
Warum Bandbreite nicht hilft, wenn Latenz das Problem ist
Hier kommt ein oft übersehenes Phänomen zum Tragen: Die Limitierung durch sequentielle Kommunikation.
Ein klassisches Beispiel ist das SMB-Protokoll (v.2 oder v.3), das weit verbreitet ist, aber bei WAN-Verbindungen nur mäßig performant arbeitet. Grund: Es arbeitet blockweise und sequentiell, d. h. jeder Datenblock muss bestätigt werden, bevor der nächste übertragen wird.
Beispiel: Übertragung einer Datei mit SMBv2
- Protokoll liest in 4 KB-Blöcken
- 1 MB Datei = 256 Blöcke
- Jeder Block erfordert eine Anfrage → Antwort → nächste Anfrage
- Bei 10 ms RTT:
256 Anfragen → 256 × 10 ms = 2.560 ms (2,56 Sekunden)
Und das bei perfekter Bandbreite!
In der Realität kommen Retransmissions, TCP Windows und Latenzspitzen hinzu – aus Sekunden werden schnell spürbare Wartezeiten.
Die Wahrnehmung des Nutzers
Selbst Latenzen ab 200 ms werden vom Menschen als Verzögerung wahrgenommen – besonders bei interaktiven Anwendungen wie Dateizugriff, Datenbanken oder RDP.
Das Resultat:
„Das Netzwerk ist langsam!“
Dabei liegt das Problem nicht in der Leitung, sondern im Protokollverhalten über lange Distanzen.
Was tun? Technische Lösungsansätze
✅ Protokollwechsel
- Statt SMB über WAN:
- SFTP, rsync, HTTPS (REST APIs)
- oder WAN-optimierte Protokolle wie CIFS mit SMBv3 + Multichannel + SMB Direct
- Bei RDP: aktivieren Sie UDP-Beschleunigung (RDP über TCP ist latenzempfindlich)
✅ Caching / Replikation
- Lokale Kopien per DFS / Robocopy
- Dateiserver-Replikation mit Zeitsteuerung
✅ WAN Optimization Tools
- Appliances von Riverbed, Cisco oder Softwarelösungen, die Latenz kaschieren
- TCP Window Scaling, Data Deduplication, Kompression
✅ Parallele Anfragen (wo möglich)
- Protokolle wie HTTP/2 oder neuere SMB-Implementierungen nutzen parallele Streams
Fazit: Es liegt nicht immer an der Bandbreite
Moderne Netzwerke verfügen häufig über ausreichende Bandbreite – aber die Latenz bleibt. Wer über große Distanzen performant arbeiten will, muss:
- die Latenz als limitierenden Faktor erkennen
- die richtigen Protokolle und Tools einsetzen
- und die Naturgesetze respektieren – Lichtgeschwindigkeit lässt sich nicht beschleunigen.
Oder in einem Satz:
Eine Gigabit-Leitung nützt wenig, wenn die Daten blockweise mit 10 ms Pause dazwischen ankommen.