Hohe Latenz im Firmennetz: Wie du RTT mit Wireshark präzise analysierst

„Das Netz ist langsam“ – dieser Satz landet regelmäßig auf dem Tisch von IT-Admins. Meistens ohne weitere Details, ohne Reproduzierbarkeit und fast immer ohne objektive Messwerte. Was bleibt, ist die Aufgabe, ein diffuses Gefühl in ein konkretes Problem zu verwandeln. Der entscheidende Einstiegspunkt dabei ist fast immer die Round-Trip-Time – kurz RTT.

In diesem Artikel zeige ich dir, wie du RTT mit Wireshark sauber misst, welche Messfallen dir dabei falsche Werte vorgaukeln, wie du typische Werte einordnest und wie du die häufigsten Ursachen hoher Latenz systematisch eingrenzt. Das ist genau der Ablauf, den ich selbst in Kundenprojekten nutze – inklusive der Stellen, an denen man sich bei der Messung leicht selbst austrickst.

Was ist RTT – und warum ist es die wichtigste Kennzahl bei Latenzklagen?

Die Round-Trip-Time beschreibt die Zeit, die ein Paket braucht, um von Punkt A zu Punkt B zu gelangen – und die Antwort wieder zurück. Es ist also immer eine bidirektionale Messung. Das klingt simpel, hat aber eine wichtige Konsequenz: RTT ist nicht dasselbe wie One-Way-Delay.

Der One-Way-Delay misst nur eine Richtung – zum Beispiel vom Client zum Server. Das Problem: Ohne synchronisierte Uhren auf beiden Seiten ist diese Messung in der Praxis kaum verlässlich. RTT hingegen lässt sich an einem einzigen Capture-Punkt berechnen, weil du Sendezeitpunkt und Antworteingang mit derselben Uhr siehst. Deshalb ist RTT im Troubleshooting so wertvoll.

Und warum klagen Nutzer über „Trägheit“, obwohl der Ping unauffällig aussieht? Weil subjektive Langsamkeit oft keine konstant hohe RTT hat, sondern sporadische Spitzen – sogenannte Latency Spikes. Ein einzelner Request mit 800 ms reicht, um eine Login-Seite gefühlt „einfrieren“ zu lassen. Ein Ping, der einmal pro Sekunde ein Paket schickt, rauscht an solchen Spitzen leicht vorbei. Dazu kommt: Pingst du einen Router oder eine Firewall direkt an, beantwortet das Gerät die Anfrage über seine eigene CPU – mit niedriger Priorität und oft mit Rate-Limit. Der Ping misst also nicht zwingend das, was deine Anwendung erlebt. Warum das so ist, erkläre ich ausführlich im Artikel Packet Loss messen – warum Pings oft lügen. Wireshark zeigt dir die RTT der echten Anwendungsverbindungen – inklusive der Spitzen.

Wie Wireshark RTT misst – und was du dabei beachten musst

Wireshark liefert dir für TCP zwei unterschiedliche RTT-Werte. Es lohnt sich, sie sauber auseinanderzuhalten:

• tcp.analysis.initial_rtt (iRTT) – die RTT aus dem TCP-Handshake. Wireshark berechnet sie als Zeit vom SYN bis zum ACK, das den Handshake abschließt. Sie wird einmal pro Verbindung ermittelt, ohne Einfluss der Applikation. Das ist die sauberste Messung der reinen Netzwerklatenz.
• tcp.analysis.ack_rtt – die Zeit zwischen einem Datensegment und dem ACK, das dieses Segment bestätigt. Diesen Wert gibt es laufend über die gesamte Verbindung.

tcp.analysis.ack_rtt = Zeitstempel(ACK) – Zeitstempel(bestätigtes Segment)

Wichtig: Die ack_rtt ist keine reine Netzwerkmessung. Der Wert enthält zusätzlich die Zeit, die sich der Empfänger mit seinem ACK lässt – und die kann durch Delayed ACK bis zu 200 ms betragen. Dazu gleich mehr. Für die Frage „Wie schnell ist das Netz?“ ist die iRTT deshalb deine Referenz. Die ack_rtt zeigt dir den Verlauf über die Zeit.

Einen Haken hat die iRTT allerdings: Sie entsteht nur beim Verbindungsaufbau. Viele Business-Anwendungen – SQL-Clients, ERP-Systeme, Citrix – halten ihre Verbindungen stunden- oder tagelang offen. Steigt die Latenz erst später, etwa zur Hauptarbeitszeit, siehst du das in der iRTT nicht. Dann ist die ack_rtt der Gegenstelle dein Werkzeug – sauber nach Richtung gefiltert und gegen Delayed ACK geprüft.

Der Capture-Punkt entscheidet

Jeder Messwert hängt davon ab, wo du capturest. Die ack_rtt misst immer vom Capture-Punkt bis zur Gegenstelle und zurück. Nimmst du den Trace auf dem Client auf, siehst du für die Daten, die der Client sendet, den kompletten Weg zum Server und zurück. Die ACKs, die der Client selbst verschickt, zeigen dagegen nur, wie schnell der Client reagiert – meist wenige Mikrosekunden oder eben die Delayed-ACK-Zeit.

Filtere deshalb immer nach Richtung, sonst vermischst du zwei völlig verschiedene Messungen in einer Spalte.

Das kannst du auch gezielt nutzen: Verschiebst du den Capture-Punkt entlang des Pfads – Client, Uplink des Filial-Routers, Rechenzentrum –, misst die ack_rtt an jedem Punkt die RTT des noch verbleibenden Weges. Die Differenz zwischen zwei Capture-Punkten ist der Latenzbeitrag des Segments dazwischen.

Eine Ausnahme ist die iRTT: Weil Wireshark sie vom SYN bis zum abschließenden ACK rechnet, zeigt sie an jedem Capture-Punkt die komplette Strecke zwischen Client und Server. Auch das ist nützlich. Liegt dein Capture-Punkt mitten im Pfad, entspricht die Zeit von SYN bis SYN/ACK dem Weg zum Server und zurück, die Zeit von SYN/ACK bis ACK dem Weg zum Client und zurück. Ein einziger Trace in der Mitte teilt den Pfad also schon in zwei Hälften.

Zur Genauigkeit der Zeitstempel: Wireshark nutzt die Uhr des Capture-Systems. Für RTT-Analysen im Millisekundenbereich reicht ein Capture auf dem Client in aller Regel aus – er zeigt genau die Perspektive des Nutzers. Geht es um Sub-Millisekunden-Werte im LAN oder um stark ausgelastete Systeme und VMs, ist ein TAP (ein passiver Abgriff, der den Traffic auf der Leitung 1:1 kopiert) oder ein dedizierter Capture-Rechner am Mirror-Port (auch SPAN-Port: ein Switch-Port, auf den der Switch den Traffic anderer Ports kopiert) die bessere Wahl. Beachte dabei: Ein Mirror-Port kann unter hoher Last selbst Pakete verwerfen. Fehlende Pakete im Trace sind dann ein Messartefakt, kein Netzwerkproblem.

Vorsicht, Messfalle: Delayed ACK

Wenn du in einem Trace auffällig viele ack_rtt-Werte um 40 ms oder um 200 ms siehst, ist das selten das Netz. Viel häufiger steckt Delayed ACK dahinter.

TCP-Stacks bestätigen nicht jedes Segment sofort. Sie warten kurz, ob noch ein zweites Segment kommt oder ob die Anwendung gleich eine Antwort schickt, auf der das ACK „huckepack“ mitfahren kann. Erst wenn ein Timer abläuft, geht das ACK allein raus. Unter Windows liegt dieser Timer standardmäßig bei bis zu 200 ms, unter Linux typischerweise ab 40 ms.

Richtig unangenehm wird das im Zusammenspiel mit dem Nagle-Algorithmus auf der Senderseite: Der Sender hält einen kleinen Datenrest zurück, bis das vorherige Segment bestätigt ist. Der Empfänger hält sein ACK zurück, weil er auf mehr Daten wartet. Beide warten aufeinander, bis der Delayed-ACK-Timer die Situation auflöst. Das Ergebnis: pro Request eine künstliche Pause von bis zu 200 ms – obwohl die Leitung völlig frei ist.

So erkennst du Delayed ACK im Trace:

• Die ack_rtt-Werte häufen sich auffällig nah an 40 oder 200 ms, statt zu streuen.
• Die iRTT der Verbindung ist niedrig – das Netz selbst ist also schnell.
• Im Umfeld gibt es keine Retransmissions.
• Das verzögerte ACK folgt oft auf ein einzelnes, kleines Segment am Ende eines Requests.

Um die typischen 200-ms-Häufungen schnell zu finden, filterst du auf ein schmales Fenster rund um den Timer:

Das ist kein Netzwerkfehler, sondern Verhalten des TCP-Stacks oder der Applikation. Genau deshalb landet es so gern im falschen Team. Die saubere Lösung liegt meist auf Applikationsseite: Setzt die Software für kleine, zeitkritische Nachrichten die Socket-Option TCP_NODELAY, ist Nagle für diese Verbindung abgeschaltet und die gegenseitige Warterei entfällt. Eingriffe in das ACK-Verhalten des Betriebssystems, etwa über TcpAckFrequency in der Windows-Registry, sind eher ein Workaround und gehören gezielt getestet.

Typische RTT-Werte im LAN, WAN und VPN – was ist noch normal?

Bevor du anfängst, Ausreißer zu jagen, brauchst du ein Gefühl dafür, was in deiner Umgebung überhaupt normal ist. Die folgenden Richtwerte verwende ich in der Praxis als Orientierung. Sie beziehen sich auf die reine Netzwerk-RTT (iRTT bzw. Ping) – nicht auf die ack_rtt:

Diese Werte sind keine harten Grenzwerte – sie helfen dir, den Kontext einzuschätzen. Eine RTT von 18 ms im LAN ist alarmierend. Dieselbe RTT auf einer WAN-Strecke zwischen München und Hamburg ist völlig normal.

Schritt-für-Schritt: RTT-Analyse in Wireshark

Hier ist mein typischer Workflow, wenn ich ein Latenzproblem untersuche:

1. Capture starten und einschränken

Starte den Capture auf dem betroffenen Client oder an einem TAP bzw. Mirror-Port. Für eine gezielte Analyse reicht oft ein kurzer Capture während des problematischen Vorgangs. Mit einem Capture-Filter (BPF-Syntax, nicht zu verwechseln mit Display-Filtern) reduzierst du die Datenmenge von Anfang an:

In den folgenden Beispielen ist 192.168.10.50 der Server. Tritt das Problem nur sporadisch auf, lass den Capture mit einem Ringpuffer mitlaufen, statt auf den richtigen Moment zu hoffen. Mit dumpcap, das mit Wireshark mitinstalliert wird, geht das zum Beispiel so – 20 Dateien à rund 100 MB, die älteste wird jeweils überschrieben. Die Interface-Nummer ermittelst du vorher mit dumpcap -D:

Ein kleiner, aber wertvoller Tipp: Lass dir von den Nutzern die Uhrzeit notieren, wann es hakt. Damit findest du die relevante Stelle im Ringpuffer in Minuten statt in Stunden.

2. iRTT und ack_rtt als Spalten hinzufügen

Wähle in der Paketliste ein ACK aus, das Daten bestätigt. Im Detailbereich klappst du Transmission Control Protocol → [SEQ/ACK analysis] auf. Dort findest du den Eintrag „The RTT to ACK the segment was …“ (das ist die ack_rtt) und die iRTT. Rechtsklick auf den jeweiligen Eintrag → Apply as Column (deutsche Oberfläche: „Als Spalte anwenden“). Sortierst du die ack_rtt-Spalte absteigend, springen die schlimmsten Ausreißer sofort ins Auge.

Für eine schnelle Filterung auf auffällige Werte – alles über 100 ms, und nur die ACKs vom Server, also die Messung über den kompletten Pfad:

Und um Verbindungen mit langsamem Handshake zu finden:

Da Wireshark die iRTT an jedes Paket der Verbindung hängt, zeigt dir dieser Filter alle Pakete der betroffenen Streams. Mit tcp.stream als zusätzlicher Spalte siehst du sofort, welche Verbindungen es sind.

Achtung: Wireshark rechnet hier in Sekunden. 0.1 sind 100 ms, 0.05 sind 50 ms. Einen umfassenden Überblick über nützliche Filter für die Performance-Analyse findest du in meinem Artikel Wireshark Display-Filter für die Netzwerkanalyse.

3. TCP Stream Graph – Round Trip Time

Für eine visuelle Übersicht wählst du ein Paket aus dem relevanten Stream und öffnest Statistics → TCP Stream Graphs → Round Trip Time. Der Graph zeigt die RTT über die Zeit – allerdings immer nur für eine Richtung. Wähle ein Datenpaket in der Richtung, die dich interessiert, oder nutze im Dialog „Switch Direction“. Ein leerer Graph bedeutet meist nur, dass du die Richtung ohne Nutzdaten erwischt hast.

Beim Lesen gilt: Ein gleichmäßiges Plateau deutet auf eine strukturelle Ursache hin – WAN-Strecke, VPN, Distanz. Sporadische Spitzen deuten auf dynamische Effekte wie Queuing, Retransmissions oder VM-Scheduling. Wie du einen Stream insgesamt liest, zeige ich im Artikel Wie lese ich einen TCP Stream richtig?

4. Ausreißer kontextualisieren

Ein einzelner hoher Wert ist erst der Anfang. Schau dir die Pakete davor und danach an:

• Retransmissions in der Nähe? Dann wurde vermutlich ein Paket verworfen, und der Sender hat auf Duplicate ACKs oder den Retransmission Timeout gewartet. Der hohe Wert ist dann eine Folge von Paketverlust, nicht von einer langsamen Leitung.
• Werte auffällig nah an 40 oder 200 ms? Prüfe auf Delayed ACK.
• Weder noch, aber Spitzen, die mit Last oder Tageszeit zusammenfallen? Dann ist Queuing Delay der wahrscheinlichste Kandidat.

Zum Zusammenhang zwischen TCP Retransmissions und Performance-Problemen habe ich einen eigenen Artikel geschrieben. Wie sich Retransmissions, Duplicate ACKs und Out-of-Order-Pakete unterscheiden, erkläre ich in TCP Retransmissions, Dup ACKs & Out-of-Order.

Ursachen hoher RTT – was steckt wirklich dahinter?

RTT ist ein Symptom, keine Ursache. Die eigentliche Arbeit liegt darin, herauszufinden, warum die RTT erhöht ist. Hier sind die häufigsten Ursachen aus der Praxis:

WAN-Strecke und physikalische Distanz

Licht bewegt sich in der Glasfaser mit rund 200.000 km/s – etwa zwei Drittel der Lichtgeschwindigkeit im Vakuum. Zwischen München und New York liegen Luftlinie rund 6.500 km. Das allein ergibt schon gut 30 ms One-Way, also rund 65 ms RTT als physikalisches Minimum. Da Glasfaserstrecken nie Luftlinie verlaufen und unterwegs Netzwerkgeräte passiert werden, landest du in der Praxis bei 80–100 ms. Physikalische Distanz ist eine harte Grenze, die du nicht wegtunen kannst. Steht dein ERP-Server in den USA und arbeiten die Mitarbeiter in Deutschland, ist eine RTT von 80–120 ms strukturell bedingt – kein Fehler, sondern Geografie.

Überlastete Router oder Switches – Queuing Delay

Das ist die häufigste Ursache hoher RTT in Unternehmensnetzen. Wenn ein Interface nicht schnell genug weiterleiten kann, was hineinkommt, warten Pakete in der Queue. Diese Wartezeit addiert sich zur RTT. Sind die Puffer groß, entstehen so Wartezeiten von mehreren hundert Millisekunden – man spricht dann von Bufferbloat.

Erkennbar ist Queuing im Trace an RTT-Spitzen, die mit hohem Durchsatz oder bestimmten Tageszeiten zusammenfallen. Oft hilft ein Blick auf die Interface-Counter des Routers oder eine SNMP-Auswertung parallel zum Wireshark-Trace.

Retransmissions als Verzögerungstreiber

Packet Loss erzwingt Retransmissions. Genau genommen verlängern sie nicht die Laufzeit der Leitung, sondern die Zeit, bis Daten tatsächlich beim Empfänger ankommen. Im günstigen Fall reagiert der Sender per Fast Retransmit nach drei Duplicate ACKs, also nach etwa einer RTT. Im ungünstigen Fall wartet er auf den Retransmission Timeout (RTO). Der liegt je nach Betriebssystem bei mindestens 200–300 ms und verdoppelt sich bei wiederholtem Verlust.

Deshalb kann schon geringer Paketverlust Verzögerungen von mehreren hundert Millisekunden erzeugen. Die Artikel zu Packet Loss mit Wireshark messen und TCP Retransmissions gehen darauf im Detail ein.

VPN-Verschlüsselung und Tunnel-Overhead

Jeder VPN-Tunnel fügt Overhead hinzu: Verschlüsselung, Entschlüsselung, Kapselung und das Routing über den VPN-Concentrator. Dazu kommt bei vielen Unternehmens-VPNs das sogenannte Hairpinning: Traffic zu einem Cloud-Dienst geht erst zum VPN-Concentrator in der Zentrale und von dort ins Internet – obwohl der Client direkt einen Internetzugang hätte. Das verlängert den Weg erheblich, im ungünstigen Fall verdoppelt es ihn. Split-Tunneling ist hier oft die richtige Antwort.

Ein zweiter VPN-Klassiker ist die MTU: Durch die zusätzlichen Header bleibt im Tunnel weniger Platz für Nutzdaten. Passt die MSS nicht dazu und blockiert zusätzlich eine Firewall die ICMP-Meldungen für Path MTU Discovery, werden große Pakete stillschweigend verworfen. Das typische Bild: Handshake und kleine Requests funktionieren, aber sobald große Antworten kommen, hängt die Verbindung oder es folgen Retransmissions in Serie.

WLAN

Im WLAN teilen sich alle Clients das Medium. Funkstörungen, schwache Signale und Roaming führen zu Wiederholungen auf Funkebene, die TCP gar nicht als Retransmission sieht. Sie zeigen sich aber als stark schwankende RTT. Tritt ein Problem nur bei WLAN-Nutzern auf, vergleiche gezielt mit einem kabelgebundenen Client am selben Standort.

Virtualisierung und VM-Scheduling

In virtualisierten Umgebungen kann der Hypervisor eine VM für Millisekunden pausieren, um einem anderen Gast CPU-Zeit zu geben. Für den Netzwerktraffic bedeutet das: Pakete warten in der virtuellen Queue, bis die VM wieder an der Reihe ist. Das erzeugt ein charakteristisches Muster: kurze Spitzen, die nicht mit der Netzwerklast korrelieren, wohl aber mit der CPU-Auslastung des Hosts. In VMware-Umgebungen lohnt sich dann ein Blick auf den CPU-Ready-Wert (%RDY in esxtop). Als Faustregel solltest du ab etwa 5 % pro vCPU genauer hinschauen; bei VMs mit vielen vCPUs zusätzlich auf Co-Stop (%CSTP).

Warum schon 20 ms RTT zum Problem werden können

Ein Punkt, der in Latenzdiskussionen fast immer untergeht: RTT wirkt nicht einmal, sondern bei jedem Roundtrip. Viele Business-Anwendungen arbeiten „chatty“. Sie schicken viele kleine Anfragen nacheinander und warten jeweils auf die Antwort, bevor die nächste Anfrage rausgeht.

Wartezeit ≈ Anzahl sequentieller Roundtrips × RTT

Ein Beispiel: Eine Maske im ERP löst beim Öffnen 400 einzelne SQL-Abfragen aus. Im LAN mit 0,5 ms RTT sind das 0,2 Sekunden – niemand merkt etwas. Über eine WAN-Strecke mit 20 ms RTT werden daraus 8 Sekunden. Die Leitung ist weder kaputt noch voll, die RTT ist völlig normal – und trotzdem ist die Anwendung kaum benutzbar. Wie genau dieses Muster in einem echten Trace aussieht, zeige ich im Praxisfall: SQL über eine WAN-Strecke.

In so einem Fall hilft keine Bandbreitenerweiterung. Die Lösung liegt im Applikationsdesign (Abfragen bündeln), in der Architektur (zum Beispiel Terminalserver oder VDI nah am Datenbankserver) oder in der Platzierung der Server. Weitere Beispiele findest du im Praxisfall zu sequentiellen Datenbank-Requests und N+1 Queries und im Artikel Single-Threading als Performance-Killer.

RTT vs. Serverantwortzeit – den Unterschied im Trace erkennen

Das ist eine der wichtigsten – und am häufigsten übersehenen – Unterscheidungen im Performance-Troubleshooting. 200 ms RTT und 200 ms Serverantwortzeit fühlen sich für den Nutzer identisch an – er wartet in beiden Fällen. Aber die Lösung ist eine völlig andere.

Netzwerklatenz ist das Netz. Serverantwortzeit ist die Applikation. Das eine löst das Netzwerkteam, beim anderen müssen Entwickler oder Datenbankadministratoren ran. Genau an dieser Stelle entstehen die meisten Schuldzuweisungen zwischen den Teams.

So trennst du es im Trace

So läuft ein typischer Request-Response-Austausch aus Sicht des Clients ab:

• Der Client sendet einen Request, zum Beispiel ein HTTP GET oder eine SQL-Query.
• Der Request erreicht den Server nach etwa einer halben RTT.
• Der Server verarbeitet die Anfrage – das ist die Serverantwortzeit.
• Die Antwort braucht wieder etwa eine halbe RTT zurück zum Client.

Die Zeit zwischen dem letzten Request-Paket und dem ersten Response-Paket ist im Client-Trace also RTT plus Serververarbeitungszeit. Ziehst du die Netzwerk-RTT ab, bleibt die Zeit übrig, die der Server zum Arbeiten gebraucht hat.

Die Netzwerk-RTT holst du dir am saubersten aus dem Handshake, also aus der iRTT. Im Client-Trace entspricht sie praktisch der Zeit von SYN bis SYN/ACK, weil das abschließende ACK des Clients sofort folgt. Details dazu findest du im Artikel TCP Handshake analysieren: SYN, SYN/ACK, ACK. Verlass dich für diese Trennung nicht auf die ack_rtt: Der Server schickt sein ACK für einen Request oft nicht sofort, sondern per Delayed ACK zusammen mit der Antwort. Dann steckt ein Teil der Serverzeit bereits in der ack_rtt.

Für die Zeit zwischen Request und Response helfen dir diese Felder:

• tcp.time_delta – die Zeit seit dem vorherigen Paket im selben TCP-Stream. Dafür in den TCP-Protokolleinstellungen „Calculate conversation timestamps“ aktivieren.
• http.time, dns.time, smb2.time – direkte Antwortzeiten für Protokolle, die Wireshark im Klartext dekodieren kann.

Mit diesem Filter findest du Antworten des Servers, denen eine Pause von mehr als 200 ms vorausging:

Bei HTTPS – wie im Capture-Filter-Beispiel oben mit Port 443 – sieht Wireshark nur verschlüsselte Daten. http.time funktioniert dann nur, wenn du den TLS-Traffic entschlüsselst, etwa über eine Schlüsseldatei des Browsers (SSLKEYLOGFILE). Das ist für die Trennung aber gar nicht nötig: Die Pause vor der Antwort ist auch im verschlüsselten Trace sichtbar, und genau die zeigt dir der Filter oben.

Ist die Zeit zwischen Request und Response deutlich größer als die iRTT, liegt der Engpass in der Applikation oder dahinter – Datenbank, Storage, Backend-Systeme. Mehr zur allgemeinen Performance-Diagnose findest du in meinem Überblicksartikel zur Netzwerkanalyse mit Wireshark.

Praktisches Beispiel: Latenzproblem in einem Filialnetz eingrenzen

Ein Kunde – mittelständisches Unternehmen, rund 300 Mitarbeiter, fünf Standorte über MPLS verbunden – meldete, dass die ERP-Applikation an zwei Filialstandorten „seit Wochen langsam“ sei. In der Zentrale, wo auch der ERP-Server steht, gab es keine Probleme. Erste interne Diagnose: Das Netzwerk ist schuld.

Vorgehen

Ich habe an zwei Punkten gleichzeitig gecaptured: auf einem Client in der betroffenen Filiale und am Server in der Zentrale. Die Idee dahinter: Mit beiden Perspektiven lässt sich sauber trennen, ob die Zeit im Netz oder im Server verloren geht.

Im Client-Trace: Außerhalb der Stoßzeiten lag die RTT bei 15–20 ms – normal für die MPLS-Strecke. Zur Hauptarbeitszeit (9–11 Uhr und 13–15 Uhr) stieg die ack_rtt der Server-ACKs auf 80–140 ms, mit Spitzen von 300–400 ms. Die iRTT der morgens aufgebauten ERP-Verbindungen blieb dabei unauffällig – ein gutes Beispiel dafür, warum sie bei langlebigen Verbindungen allein nicht reicht. Keine Retransmissions, keine Hinweise auf Paketverlust.

Im Server-Trace: Dieselben Verbindungen zeigten aus Server-Sicht dieselbe erhöhte RTT. Das ist logisch, denn die RTT umfasst immer den kompletten Hin- und Rückweg. Entscheidend war etwas anderes: Zwischen eingehendem Request und ausgehender Antwort vergingen am Server konstant 8–12 ms – auch in den Stoßzeiten.

Ergebnis: Der Server war nicht das Problem, die zusätzliche Zeit entstand auf dem Weg zwischen Filiale und Zentrale. Die Interface-Statistiken des Filial-Routers zeigten in genau diesen Zeitfenstern eine Auslastung von über 90 %. Damit war das WAN-Segment eingegrenzt – kein Defekt im klassischen Sinne, aber eine klare Korrelation mit den Lastzeiten.

Ursache

Die Filiale war mit 10 Mbit/s angebunden. Ausgerechnet zur Hauptarbeitszeit lief ein Backup-Job der Filiale in Richtung Rechenzentrum über dieselbe Leitung und trieb die Auslastung auf über 90 %. Das erzeugte Queuing Delay am WAN-Ausgang des CE-Routers – des Routers am Kundenstandort (Customer Edge), der bei MPLS-Anschlüssen oft vom Provider gemanagt wird. Die ERP-Requests standen in derselben Warteschlange wie die Backup-Daten.

Die Lösung: eine QoS-Konfiguration auf dem CE-Router, die ERP-Traffic priorisiert – umgesetzt gemeinsam mit dem Provider –, und mittelfristig eine Erweiterung des Links auf 50 Mbit/s. Nach der QoS-Umsetzung lag die RTT auch zur Hauptarbeitszeit stabil bei 15–20 ms, die Spitzen waren verschwunden. Ergänzend gilt: Backup-Jobs über schmale WAN-Strecken gehören in die Randzeiten oder sollten in der Bandbreite begrenzt werden.

Dieses Szenario ist kein Einzelfall. Queuing-bedingte Latenz ist einer der häufigsten Gründe für WAN-Performance-Beschwerden – und ohne Trace bleibt es oft bei Schuldzuweisungen zwischen Admin und Provider. Wie ich bei solchen Fällen grundsätzlich vorgehe, beschreibe ich in Netzwerkprobleme systematisch eingrenzen – die 5-Schritte-Methodik.

Falls du in ähnlichen Szenarien auch mit Verbindungsabbrüchen zu kämpfen hast: Verbindungsabbrüche analysieren zeigt, wie dauerhaft hohe Latenz Timeouts und TCP-Session-Resets auslösen kann.

TCP Window Size – der unterschätzte Faktor

Noch ein Punkt, der bei Latenzanalysen gern übersehen wird: Die TCP Window Size bestimmt, wie viele Daten ein Sender verschicken darf, bevor er auf ein ACK warten muss. Ein zu kleines Window erhöht nicht die RTT selbst – aber der Sender verbringt einen Großteil der Zeit mit Warten. Für den Nutzer fühlt sich das genauso an wie hohe Latenz.

Maximaler Durchsatz = TCP Window Size / RTT

Ein Beispiel: Mit 64 KB Window und 20 ms RTT kommst du auf maximal rund 26 Mbit/s – egal, ob die Leitung 100 Mbit/s oder 1 Gbit/s hat. Relevant wird das vor allem auf Strecken mit hohem Bandwidth-Delay-Product (Bandbreite × RTT, also die Datenmenge, die gleichzeitig „in der Leitung“ unterwegs sein muss, um sie auszulasten). Moderne Betriebssysteme vergrößern das Window per Window Scaling weit über 64 KB hinaus. Bleibt eine Verbindung trotzdem bei 64 KB hängen, ist Window Scaling oft deaktiviert, wird von einer Middlebox entfernt, oder die Anwendung setzt zu kleine Socket-Puffer. Ob die Option ausgehandelt wurde, siehst du im Handshake am Feld tcp.options.wscale – SYN und SYN/ACK müssen sie beide tragen.

Im Trace erkennst du Window-Engpässe an Expert-Hinweisen. TCP Window Full heißt: Der Sender hat das Empfangsfenster ausgeschöpft und muss warten. Davon zu unterscheiden ist TCP ZeroWindow: Hier meldet der Empfänger, dass sein Puffer voll ist, weil die Anwendung die Daten nicht schnell genug abholt – ein Problem auf dem Empfängersystem, nicht im Netz.

Mehr dazu erkläre ich im Artikel zu TCP Window Size und Window Scaling. Wie TCP sein Sendetempo zusätzlich über Congestion Control regelt, zeigt der Vergleich der TCP-Algorithmen Reno, CUBIC und BBR.

Spickzettel: Welches Muster gehört zu welchem Team?

Wenn du deine Ergebnisse an Kollegen, Dienstleister oder die IT-Leitung weitergibst, hilft eine klare Zuordnung. Die folgende Übersicht fasst zusammen, welche Muster ich im Trace typischerweise sehe – und wer dann gefragt ist:

Häufige Fragen zur RTT-Analyse

Was ist ein guter RTT-Wert?

Im LAN unter 1 ms, auf innerdeutschen WAN-Strecken 5–20 ms, über VPN meist 10–40 ms. Entscheidend ist weniger der absolute Wert als die Abweichung von der Baseline deiner Umgebung.

Warum unterscheidet sich die RTT in Wireshark vom Ping?

Ping misst mit ICMP, das Router und Firewalls oft anders behandeln als Anwendungstraffic, und liefert nur einzelne Stichproben. Wireshark misst die RTT der echten TCP-Verbindungen – inklusive aller Spitzen. Die ack_rtt enthält zusätzlich die ACK-Verzögerung des Empfängers.

Warum zeigt Wireshark immer wieder ziemlich genau 200 ms?

Fast immer steckt Delayed ACK dahinter, oft in Kombination mit dem Nagle-Algorithmus. Prüfe die iRTT der Verbindung: Ist sie niedrig, ist das Netz nicht der Engpass.

Warum ist die iRTT unauffällig, obwohl Nutzer über Langsamkeit klagen?

Weil die iRTT nur beim Verbindungsaufbau gemessen wird. Bei langlebigen Verbindungen – typisch für SQL, ERP oder Citrix – liegt der Handshake oft Stunden zurück. Schau dir dann die ack_rtt der Gegenstelle über die Zeit an und prüfe parallel die Pausen vor den Serverantworten.

Ist hohe RTT immer ein Netzwerkproblem?

Nein. Hohe ack_rtt-Werte können durch Delayed ACK entstehen, und lange Pausen zwischen Request und Response sind oft Serverantwortzeit. Erst der Vergleich von iRTT und Antwortzeit zeigt, welches Team zuständig ist.

Fazit und nächste Schritte

RTT ist die zentrale Kennzahl, wenn Nutzer über ein „langsames Netz“ klagen. Sie ist messbar, reproduzierbar und mit Wireshark ohne großen Aufwand aus einem Capture zu gewinnen. Entscheidend ist nicht nur der Wert selbst, sondern seine Einordnung in den Kontext: Wo wurde gecaptured? In welche Richtung misst du? Welche Technologie liegt vor? Gibt es Spitzen oder ein konstant hohes Plateau?

Die häufigsten Ursachen in der Praxis sind Queuing Delay auf überlasteten Links, Retransmissions durch Packet Loss und VPN-Umwege. Mindestens genauso oft liegt das Problem aber gar nicht in der Leitung: Delayed ACK, chatty Anwendungen und Serverantwortzeiten werden regelmäßig fälschlicherweise dem Netz zugeschrieben.

Mein Tipp für den Einstieg: Füge iRTT und ack_rtt als Spalten in Wireshark ein, filtere konsequent nach Richtung und öffne den Round-Trip-Time-Graphen. Wenn du das bei den nächsten Latenzbeschwerden durchziehst, entwickelst du schnell ein Gefühl dafür, was in deinem Netz normal ist – und was nicht.

Und wenn bei euch gerade Netzwerk-, Applikations- und Serverteam die Verantwortung hin- und herschieben: Genau dafür gibt es objektive Paketdaten. Ob du als Admin einen zweiten Blick auf einen konkreten Trace brauchst, als Applikationsverantwortlicher wissen willst, ob das Netz wirklich schuld ist, oder als IT-Leitung eine belastbare Ursachenanalyse brauchst – das Erstgespräch ist kostenlos. Melde dich einfach.