Warum deine Gigabit-Leitung langsam wirkt – und warum das völlig normal ist
„Wir haben doch 1 Gbit/s – warum ist das so langsam?“
Diese Frage taucht in Unternehmen regelmäßig auf, sobald Daten über größere Entfernungen übertragen werden.
Besonders häufig passiert das bei Verbindungen zwischen Standorten – etwa zwischen Hamburg und München.
Die Erwartung ist klar: Viel Bandbreite = schnelle Übertragung.
Die Realität ist komplizierter.
Bandbreite ist nicht gleich Geschwindigkeit
Zwei Begriffe werden im Alltag oft verwechselt:
- Bandbreite: Wie viele Daten pro Sekunde maximal übertragen werden können
- Latenz: Wie lange ein Datenpaket von A nach B (und zurück) braucht
In lokalen Netzwerken ist die Latenz extrem gering (unter 1 ms).
Bei Verbindungen über größere Entfernungen liegt sie jedoch typischerweise bei 10–20 ms innerhalb Deutschlands.
Und genau hier beginnt das Problem.
Die Grenze setzt die Physik
Daten bewegen sich nicht instantan – sie sind an physikalische Grenzen gebunden:
- Lichtgeschwindigkeit im Vakuum: ~300.000 km/s
- In Glasfaser: ~200.000 km/s
Eine Verbindung von Hamburg nach München ist in der Praxis etwa 1.000 km lang.
Das bedeutet:
→ mindestens ~5 ms in eine Richtung
→ mindestens ~10 ms für Hin- und Rückweg (RTT)
Und das ist der absolute Best Case – ohne Router, ohne Warteschlangen, ohne Protokoll-Overhead.
Warum deine Gigabit-Leitung nicht ausgelastet wird
Jetzt wird es spannend: Selbst wenn deine Leitung 1 Gbit/s kann, heißt das nicht, dass du diese Geschwindigkeit erreichst.
Der Grund liegt in einem oft übersehenen Zusammenhang:
Bandwidth-Delay-Product (BDP)
Das BDP beschreibt, wie viele Daten gleichzeitig „im Netz unterwegs“ sein müssen, um die verfügbare Bandbreite auszunutzen.
Beispiel:
- 1 Gbit/s = 125 MB/s
- RTT = 10 ms
→ 125 MB/s × 0,01 s = 1,25 MB
Das bedeutet:
Es müssen mindestens 1,25 MB gleichzeitig übertragen werden, sonst bleibt Bandbreite ungenutzt.
TCP: Der eigentliche Flaschenhals
Die meisten Anwendungen nutzen TCP – und genau hier liegt oft die Ursache für „langsame“ Verbindungen.
TCP arbeitet bestätigungsbasiert:
- Daten werden gesendet
- Empfang wird bestätigt (ACK)
- Erst dann wird weiter gesendet (vereinfacht)
Entscheidend ist das sogenannte TCP Window:
Maximaler Durchsatz ≈ TCP Window / RTT
Beispiel:
- TCP Window: 64 KB
- RTT: 10 ms
→ ~52 Mbit/s maximal
Und das – obwohl eine 1 Gbit-Leitung vorhanden ist.
Warum kleine Dateien besonders langsam sind
TCP startet jede Verbindung mit Slow Start:
- Übertragung beginnt langsam
- Steigert sich pro RTT
- Erreicht erst nach mehreren RTT die maximale Geschwindigkeit
Bei kleinen Transfers ist der Vorgang oft schon beendet, bevor die Verbindung „auf Touren kommt“.
Schon minimaler Paketverlust kostet massiv Leistung
Ein weiterer kritischer Faktor ist Paketverlust:
- TCP interpretiert Verluste als Überlastung
- Sendefenster wird reduziert
Bereits 0,1 % Paketverlust können den Durchsatz deutlich reduzieren – besonders bei hoher Latenz.
Warum sich das für Nutzer „langsam“ anfühlt
Besonders betroffen sind sogenannte „chatty“ Protokolle:
- SMB / Netzlaufwerke
- Datenbankzugriffe
- Remote Desktop
Diese erzeugen viele kleine Anfragen hintereinander – und jede einzelne ist von der Latenz abhängig.
Das Ergebnis:
„Das Netzwerk ist langsam.“
Tatsächlich ist es aber oft das Zusammenspiel aus Latenz + Protokollverhalten.
Was wirklich hilft
✅ Protokolle optimieren
- HTTP/2 oder HTTP/3 (Multiplexing)
- rsync / SFTP für Transfers
✅ Daten näher zum Nutzer bringen
- Replikation
- Edge-Systeme
✅ Parallelisierung nutzen
- Mehrere Streams
- Moderne Protokolle
✅ WAN optimieren
- TCP Window Scaling
- Kompression / Deduplizierung
Fazit
Die wichtigste Erkenntnis ist simpel:
Bandbreite ist selten das Problem – Latenz fast immer ein Teil davon.
Und diese lässt sich nicht „wegkonfigurieren“, weil sie durch Physik begrenzt ist.
Oder anders gesagt:
Eine Gigabit-Leitung nützt wenig, wenn die Daten nicht schnell genug hin- und herbestätigt werden können.