Netzwerklatenz erklärt: Wo die Millisekunden bleiben

Netzwerklatenz ist die Zeit, die ein Paket bis zu seinem Ziel und zurück braucht, die Round-Trip-Zeit (RTT), in Millisekunden. Sie setzt sich aus vier Teilen zusammen: der Strecke, die das Signal zurücklegt, der Route, die die Netze wählen, den Warteschlangen, in denen es wartet, und den RTTs, die die darüberliegenden Protokolle hinzufügen. Nur der erste Teil ist physikalisch festgelegt. Dieser Leitfaden geht sie der Reihe nach durch, mit echten Messungen von unseren Servern in Falkenstein (Deutschland) und Gravelines (Frankreich) vom 7. Oktober 2026.

Woraus eine RTT besteht

Komponente	Was dahintersteckt	Typische Größenordnung
Ausbreitung	Licht bewegt sich in Glasfaser mit etwa 200.000 km/s, zwei Dritteln seiner Geschwindigkeit im Vakuum: 1 ms RTT pro 100 km Kabel	Unter 1 ms innerhalb einer Stadt, 60 bis 90 ms über den Atlantik, 160 ms oder mehr bis auf die andere Seite der Welt
Serialisierung	Die Bits eines Pakets auf die Leitung bringen: 1.500 Byte brauchen bei 1 Gbit/s 12 µs	Vernachlässigbar, außer auf langsamen Leitungen: 1,2 ms pro volles Paket bei 10 Mbit/s
Warteschlangen	Warten im Puffer eines Routers oder Modems, wenn eine Leitung ausgelastet ist	Null auf einem unbelasteten Pfad, Hunderte Millisekunden, wenn sich ein Puffer füllt
Verarbeitung	Der Router entscheidet, wohin er das Paket schickt	Mikrosekunden auf aktueller Hardware

Weit verbreitet ist die Annahme, „jeder Hop kostet ein paar Millisekunden“. Das stimmt nicht: Die Weiterleitung dauert Mikrosekunden. Wenn die Zeiten in einem Traceroute von einem Hop zum nächsten wachsen, liegt das an der Entfernung, an einer Warteschlange oder daran, dass der Router das Testpaket nur langsam beantwortet, während er alles andere mit voller Geschwindigkeit weiterleitet.

Die Entfernung setzt eine Untergrenze

Die kürzestmögliche RTT ergibt sich aus der Großkreisentfernung bei Lichtgeschwindigkeit in Glasfaser. Echte Kabel folgen nie dem Großkreis, und echte Routen nehmen selten das kürzeste Kabel. So weit lagen unsere Messungen von dieser Untergrenze entfernt (Mittelwert aus 60 bis 100 Testpaketen pro Ziel, mit mtr):

Von → nach	Entfernung	Untergrenze in Glasfaser	Gemessen	Verhältnis
Gravelines → Cloudflare 1.1.1.1 (Paris)	237 km	2,4 ms	4,9 ms	2,0×
Falkenstein → Cloudflare 1.1.1.1 (Frankfurt)	265 km	2,6 ms	5,9 ms	2,3×
Gravelines → New Jersey	5.779 km	57,8 ms	71,7 ms	1,2×
Falkenstein → New Jersey	6.462 km	64,6 ms	86,4 ms	1,3×
Falkenstein → Singapur	9.994 km	99,9 ms	165,5 ms	1,7×
Falkenstein → Tokio	9.134 km	91,3 ms	273,6 ms	3,0×
Falkenstein → Sydney	16.220 km	162,2 ms	341,2 ms	2,1×

Auf kurzen Strecken dominieren die Fixkosten (Geräte, die letzten Meter Verkabelung, die Zeit, die das Ziel zum Antworten braucht), und das Verhältnis sieht schlecht aus, obwohl die absoluten Werte winzig sind. Auf langen Strecken kommt es auf die Route an. Tokio liegt beim Dreifachen seiner Untergrenze, weil die Pakete nicht direkt dorthin laufen: Der Trace verlässt Europa über das Netz von Arelion, erreicht Singapur bei 169 ms und dann Tokio bei 246 ms. In unserer Studie zur Cloud-Latenz aus 33 Städten brauchten die Pakete von Johannesburg nach São Paulo im besten Fall 351 ms, bei einer Untergrenze von 74 ms: Sie liefen über Europa.

Gleiches Ziel, zwei Routen

Derselbe Vultr-Host in New Jersey, in derselben Minute von unseren beiden Servern aus gemessen:

Von Falkenstein aus (Hetzner, AS24940)
  5. AS201011 ae12-499.nbg40.core-backbone.com      0.0%   100    3.2   3.0   2.7   3.3   0.1
  6. AS201011 ae7-2093.nyk10.core-backbone.com      0.0%   100   86.6  86.7  86.5  87.0   0.1
 11. AS20473  108.61.149.182.vultrusercontent.com   0.0%   100   86.2  86.4  85.9 107.1   2.1

Von Gravelines aus (OVHcloud, AS16276)
 10. AS16276  be102.lon-drch-sbb1-nc5.uk.eu         1.0%   100    3.8   3.7   3.5   4.1   0.1
 11. AS16276  nyc-ny1-sbb2-8k.nj.us                 0.0%   100   73.0  73.4  71.6  76.0   0.8
 13. AS???    nyiix.gi3-6.cr1.nyc1.choopa.net       0.0%   100   72.7  72.5  72.3  73.0   0.1
 17. AS20473  108.61.149.182.vultrusercontent.com   0.0%   100   71.7  71.7  71.5  73.0   0.2

Der Unterschied von 14,7 ms ist nur zur Hälfte Entfernung (die Untergrenzen liegen 6,8 ms auseinander). Der Rest ist die Route: Von Gravelines aus transportiert OVH den Verkehr im eigenen Netz über London nach New York und übergibt ihn am NYIIX, einem Internet-Knoten (IXP) in New York, an Vultr; von Falkenstein aus übergibt Hetzner ihn in Nürnberg an Core-Backbone, das den Atlantik überquert. Wer einen Hoster oder einen Provider wählt, wählt auch dessen Routen.

Warteschlangen: die Latenz, die kommt und geht

Die Ausbreitung ändert sich nicht, Warteschlangen schon. Auf den unbelasteten Pfaden oben blieb die Streuung an den Zielen über 100 Testpakete zwischen 0,1 und 2,1 ms. An einem Heimanschluss kann ein einziger großer Upload den Puffer des Modems füllen und allem anderen Hunderte Millisekunden hinzufügen: Das ist Bufferbloat.

Zum Testen starten Sie ping 1.1.1.1 und, während er läuft, einen großen Upload und danach einen großen Download. Springen die Zeiten von 15 ms auf 200 ms oder mehr und fallen sie nach dem Ende der Übertragung wieder, ist der Puffer das Problem. Die Abhilfe liegt im Router: Smart Queue Management (fq_codel oder CAKE, verfügbar unter OpenWrt und auf vielen neueren Routern) oder Traffic Shaping knapp unter der Nenngeschwindigkeit der Leitung.

Protokolle vervielfachen die RTTs

Eine neue HTTPS-Verbindung kostet mehrere RTTs, bevor das erste Byte der Seite ankommt: eine DNS-Abfrage, wenn der Name nicht im Cache liegt, eine für den TCP-Handshake, eine für TLS 1.3 (zwei für TLS 1.2) und eine für die eigentliche Anfrage. Bei vier RTTs:

RTT	4 RTTs
6 ms (ein Server in der Nähe)	24 ms
86 ms (von Deutschland nach New Jersey)	344 ms
341 ms (von Deutschland nach Sydney)	1,4 s

Dieselbe Rechnung gilt für alles, was nacheinander abläuft: Eine Anwendung, die 20 Datenbankabfragen hintereinander an eine 80 ms entfernte Datenbank stellt, wartet 1,6 Sekunden. HTTP/2 und HTTP/3 verwenden Verbindungen wieder, TLS 1.3 und QUIC verkürzen die Handshakes, und weniger aufeinanderfolgende Anfragen sparen den Rest ein.

Wie viel ist zu viel?

Anwendung	Angenehm	Spürbar
Sprach- und Videoanrufe	Unter 150 ms in eine Richtung, die Empfehlung ITU-T G.114	Darüber fallen sich die Gesprächspartner ins Wort
Schnelle Online-Spiele	Unter etwa 50 ms RTT	Über 100 ms spüren es die meisten Spieler
Webseiten und APIs	Hängt von der Zahl aufeinanderfolgender RTTs ab	Jede zusätzliche RTT verlängert die Zeit bis zum ersten Byte

Selbst messen

• ping -c 20 host: Das Minimum ist Ihre Untergrenze auf diesem Pfad, der Mittelwert Ihre übliche Latenz und mdev der Jitter.
• mtr -rwz -c 100 host: wo auf dem Pfad die Zeit hinzukommt (siehe wie Sie einen mtr-Bericht lesen).
• Von mehreren Orten aus: Unser Cloud-Latenztest misst die Latenz Ihres Browsers zu 36 Regionen von AWS, OVHcloud, Vultr und Akamai, und TraceMapper verfolgt dieselbe Route von mehr als 30 Standorten aus.

Was Sie ändern können und was nicht

• Entfernung: nur, indem Sie den Server näher an die Nutzer bringen oder eine Region oder ein CDN hinzunehmen. In unserer Studie mit 33 Städten bediente Frankfurt allein 14 Städte in unter 100 ms, Frankfurt und Singapur zusammen 27.
• Route: durch die Wahl eines Providers, dessen Netz und Peering zu Ihren Nutzern passen. Die Routing-Policy eines anderen Netzes können Sie nicht ändern.
• Warteschlangen: Smart Queue Management zu Hause; im Rechenzentrum keine Leitungen mit 100 % Auslastung betreiben.
• RTTs: Wiederverwendung von Verbindungen, TLS 1.3, DNS-Caching, weniger aufeinanderfolgende Aufrufe.

Für die Praxis siehe Netzwerklatenz verringern.