1 GBit/s = 125 MB/s. So steht es in jedem Schulbuch. Und so steht es auf der Rechnung deines Internetproviders. Die Wahrheit: Von 125 MB/s siehst du im echten Leben vielleicht 95 — und das auch nur bei HTTP-Downloads großer Dateien. Bei SMB-Transfers über VPN schrumpft das auf 25. Bei rsync über einen transatlantischen Link auf 5.

Dieser Artikel erklärt, wo die fehlenden 90% deiner Bandbreite bleiben. Mit dem bitcalc Downloadzeit-Rechner als Werkzeug, der dir realistische Zeiten für deine spezifische Situation berechnet.

Layer 1 vs. Layer 7: Warum 1 GBit/s nicht 1 GBit/s sind

Dein Provider verkauft dir Layer-1-Bandbreite: die rohe Bitrate auf dem Kabel. Was du nutzen kannst, ist Layer-4/7-Durchsatz: das, was nach all den Protokoll-Headern übrig bleibt. Dazwischen liegen mehrere Ebenen, die sich alle ihr Stück vom Kuchen nehmen:

Protokoll-Overhead: Vom Kabel bis zur Anwendung
Der Weg von 1 GBit/s auf dem Kabel zu dem, was deine Anwendung tatsächlich nutzen kann.
ProtokollOverheadEffektiver FaktorVon 1 GBit/s bleiben
HTTP/2 (TLS 1.3)~5%0,95×~119 MB/s
SMB3 (LAN)~20%0,80×~100 MB/s
SMB3 (VPN, 50ms)~75%0,25×~31 MB/s
rsync (transatlantisch, 120ms)~95%0,05×~6 MB/s

TCP-Windowing: Der stille Killer

TCP ist kein Feuerwehrschlauch, sondern ein Ping-Pong-Spiel. Der Sender schickt Daten, der Empfänger bestätigt (ACK). Wie viel der Sender schicken darf, bevor er auf ein ACK warten muss, bestimmt das TCP-Window.

Das Problem: Max-Throughput = Window-Size / RTT. Bei einem 64K-Window (Standard vor Window Scaling) und 10 ms Latenz sind das maximal 52 Mbit/s — egal ob du eine 1-GBit-Leitung hast. Mit Window Scaling (heute Standard) geht das Window bis 1 GB, was bei 10 ms RTT theoretisch 800 GBit/s erlaubt.

Aber: Window Scaling hilft nur bei langen, ununterbrochenen Streams. Sobald die Applikation synchrone I/Os macht („lies diesen 4K-Block, dann den nächsten"), kollabiert der Durchsatz. Und dann hilft kein Window Scaling der Welt.

Praxisbeispiel SMB über VPN mit 50 ms Latenz: Selbst mit perfektem Window Scaling bremst die Latenz den Durchsatz massiv aus. Jede SMB-Operation (Datei öffnen, lesen, schließen) braucht mehrere Round-Trips. Bei 50 ms sind 20 Round-Trips eine ganze Sekunde — für eine einzige Datei. Deshalb ist SMB über WAN eine Zumutung und rsync mit SSH ein Geduldsspiel.

Der bitcalc Downloadzeit-Rechner

Der Downloadzeit-Rechner ist bewusst einfach: Dateigröße und Bandbreite rein, Zeit in Stunden/Minuten/Sekunden raus. Kein Overhead-Rechner, keine Protokoll-Auswahl — nur die rohe Kalkulation. Weil die Overhead-Faktoren sich je nach Umgebung so stark unterscheiden, dass jeder pauschale Faktor falsch wäre.

Was du stattdessen machst: Bandbreite × Overhead-Faktor (aus der Tabelle oben) als Eingabe. Für einen SMB-Transfer im LAN: 1 GBit/s × 0,8 = 800 Mbit/s. Im Rechner eintippen, und du bekommst eine realistische Zeit.

Peering: Wenn das Internet selbst zum Flaschenhals wird

Dein Provider verkauft dir 1 GBit/s — zu seinem eigenen Netz. Sobald deine Daten das Netz deines Providers verlassen, betreten sie das Peering. Und da wird's politisch: Provider A peered mit Provider B nur über einen 10-GBit-Link, den sich 50.000 Kunden teilen. Dein 1 GBit/s wird zu 200 MBit/s, weil der Peering-Link überlastet ist.

Das ist kein theoretisches Problem. Netflix hat jahrelang mit Comcast und der Telekom um Peering-Kapazitäten gestritten. Als Endkunde siehst du nur: „Speedtest sagt 900 Mbit/s, aber Netflix buffert." Der Speedtest-Server steht im Netz deines Providers. Netflix nicht.

Die wichtigste Faustformel

LAN, HTTP, große Dateien: 90-95% der Nennbandbreite.
LAN, SMB: 75-85%.
WAN/VPN, SMB: 20-40% (Latenz dominiert).
WAN, rsync/SCP: 5-20% (single-threaded, Latenz dominiert massiv).
WAN, HTTP/3 (QUIC): 80-90% (multiplexed, kein Head-of-Line-Blocking).