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, typische Werte einordnest und die häufigsten Ursachen hoher Latenzen systematisch eingrenzt. Kein Marketing, keine Theorie ohne Praxis – nur das, was ich selbst in Kundenprojekten täglich anwende.

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 aus einem einzigen Capture-Punkt berechnen, weil du Sendezeitpunkt und Antworteingang auf derselben Maschine siehst. Deshalb ist RTT im Troubleshooting so wertvoll.

Und warum klagen Nutzer über „Trägheit”, obwohl der Ping noch akzeptabel aussieht? Weil subjektive Langsamkeit oft keine konstant hohe RTT hat, sondern sporadische Spitzen – sogenannte Latency Spikes. Ein einzelner Request mit 800 ms RTT reicht, um eine Login-Seite gefühlt „einzufrieren”. Wireshark zeigt dir diese Spitzen – ein einfacher Ping im Schnitt nicht.

Wie Wireshark RTT misst – und was du dabei beachten musst

Wireshark berechnet die RTT anhand des TCP-Handshakes und der ACK-Antworten. Der relevante Wert heißt tcp.analysis.ack_rtt – er gibt an, wie lange es gedauert hat, bis ein ACK für ein bestimmtes Segment eingetroffen ist.

tcp.analysis.ack_rtt = Zeitstempel(ACK) – Zeitstempel(Segment)

Das klingt eindeutig, ist aber an eine wichtige Bedingung geknüpft: Der Messwert hängt immer davon ab, wo du den Capture durchführst. Nimmst du den Trace auf dem Client, misst du die RTT aus Client-Sicht – inklusive aller Verzögerungen auf dem Weg zum Server und zurück. Nimmst du den Trace auf einem Switch im Rechenzentrum, bekommst du einen völlig anderen Wert.

Das ist kein Fehler, sondern eine Eigenschaft, die du bewusst nutzen kannst: Durch das Vergleichen von Traces an verschiedenen Punkten im Netz lässt sich der Latenzbeitrag einzelner Segmente isolieren. Mehr dazu im praktischen Beispiel weiter unten.

Außerdem gilt: Wireshark nutzt die Systemuhr des Capture-Rechners. Auf stark ausgelasteten Maschinen oder in VMs kann die Zeitstempelgenauigkeit leiden. Für präzise Messungen immer auf einem dedizierten Capture-Punkt oder einem TAP arbeiten – nicht auf dem Rechner, der gleichzeitig Produktivlast fährt.

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. Hier sind Richtwerte, die ich in der Praxis als Orientierung verwende:

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 eine Latenzkompanie untersuche:

1. Capture starten und einschränken

Starte den Capture auf dem Client-Rechner oder einem Netzwerk-TAP. Für eine gezielte RTT-Analyse reicht ein kurzer Capture während des problematischen Vorgangs. Filtere den Capture von Anfang an auf den relevanten Host oder Port, um die Datenmenge zu reduzieren:

host 192.168.10.50 and tcp port 443

2. tcp.analysis.ack_rtt als Spalte hinzufügen

Rechtsklick auf ein beliebiges TCP-Paket → Protocol Preferences oder direkt: Expand TCP Analysis Flags im Detail-Bereich, Rechtsklick auf tcp.analysis.ack_rtt → Apply as Column. Jetzt siehst du die RTT für jedes ACK direkt in der Paketliste. Sortiere die Spalte absteigend – die schlimmsten Ausreißer springen sofort ins Auge.

Für eine schnelle Filterung auf auffällige Werte – zum Beispiel alles über 100 ms:

tcp.analysis.ack_rtt > 0.1

Einen umfassenden Überblick über nützliche Wireshark-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ähle ein TCP-Paket aus dem relevanten Stream → Statistics → TCP Stream Graphs → Round-Trip-Time. Der Graph zeigt dir RTT über die Zeit. Plateaus sind harmlos, steile Spitzen sind interessant. Eine gleichmäßig hohe RTT deutet auf eine strukturelle Ursache hin (WAN-Strecke, VPN). Sporadische Spitzen deuten auf Queuing, Retransmissions oder VM-Scheduling-Effekte hin.

4. Ausreißer kontextualisieren

Wenn du einen RTT-Ausreißer findest: Schau dir die Pakete kurz davor an. Gibt es TCP Retransmissions? Dann liegt die erhöhte RTT wahrscheinlich daran, dass das Original-Paket verworfen wurde und der Stack auf den Timeout gewartet hat. Gibt es keine Retransmissions, aber trotzdem hohe RTT? Dann ist Queuing Delay oder Serverantwortzeit die wahrscheinlichere Ursache.

Zum Zusammenhang zwischen TCP Retransmissions und Performance-Problemen habe ich einen eigenen Artikel geschrieben – empfehlenswert, wenn du tiefer einsteigen willst.

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 im Glasfaserkabel legt etwa 200.000 km/s zurück – das klingt schnell, aber auf einer Strecke München–New York sind das schon rund 35–40 ms One-Way. Physikalische Distanz ist eine harte Grenze, die du nicht wegtunnen kannst. Wenn dein ERP-Server in den USA steht und die Mitarbeiter in Deutschland arbeiten, ist eine RTT von 80–120 ms strukturell – kein Fehler, sondern Geografie.

Überlastete Router oder Switches – Queuing Delay

Das ist die häufigste Ursache hoher RTT in internen Netzen. Wenn ein Interface nicht schnell genug leert, was hineinkommt, warten Pakete in der Queue. Diese Wartezeit addiert sich zur RTT. Erkennbar im Trace: RTT-Spitzen, die mit hohem Durchsatz oder bestimmten Tageszeiten korrelieren. Oft hilft ein Blick auf die Interface-Counters des Routers oder eine SNMP-Auswertung parallel zum Wireshark-Trace.

Retransmissions als RTT-Treiber

Packet Loss erzwingt Retransmissions. Retransmissions erhöhen die RTT – weil der Sender auf den Timeout wartet, bevor er neu sendet. Das ist ein Multiplikationseffekt: Schon 0,1 % Packet Loss kann RTT-Spitzen von mehreren Hundert Millisekunden erzeugen. Die beiden 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, 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, dann weiter ins Internet – obwohl der Client direkt einen Internetzugang hätte. Das verdoppelt effektiv den Weg. Split-Tunneling ist hier oft die richtige Antwort.

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 Netzwerk-Traffic bedeutet das: Pakete warten in der virtuellen Queue, bis die VM wieder gescheduled wird. Das erzeugt charakteristische RTT-Muster: kurze Spitzen, die sich nicht mit Netzwerklast korrelieren lassen, aber mit CPU-Auslastung des Hosts.

RTT vs. Serverantwortzeit – den Unterschied im Trace erkennen

Das ist eine der wichtigsten – und am häufigsten übersehenen – Differenzierungen im Performance-Troubleshooting. 200 ms RTT und 200 ms Serverantwortzeit sehen im Endeffekt identisch aus – der Nutzer wartet in beiden Fällen. Aber die Lösung ist eine völlig andere.

Netzwerklatenz ist das Netz. Serverantwortzeit ist die Applikation. Ein Netzwerkingenieur kann ersteres lösen, bei letzterem muss der Entwickler oder Datenbankadministrator ran.

So trennst du es im Trace

Nutze die delta_time zwischen Paketen. Konkret:

• Client sendet einen Request (z. B. HTTP GET oder SQL-Query)
• Server empfängt und ACK-t das Paket sofort → das ACK trifft nach ~1x RTT ein
• Server schickt die Antwort erst nach einer Verzögerung

Wenn zwischen dem letzten Client-Paket und der ersten Server-Antwort deutlich mehr Zeit vergeht als die reine Netzwerk-RTT, ist die Differenz die Serververarbeitungszeit – nicht Netzwerklatenz.

Praktisch gesehen: Messe die RTT aus dem TCP-Handshake (SYN → SYN-ACK). Das ist eine saubere Netzwerkmessung ohne Applikations-Overhead. Vergleiche sie dann mit der Zeit zwischen dem letzten Request-Paket und dem ersten Response-Paket. Liegt diese Zeit deutlich über der Handshake-RTT, ist die Applikation das Problem.

Diese Methode ist auch für allgemeine Performance-Diagnosen nützlich – mehr dazu 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. Die Zentrale mit dem ERP-Server hatte keine Probleme. Erste interne Diagnose: Netzwerk schuld.

Vorgehen

Ich habe an zwei Punkten gleichzeitig gecaptured: einmal auf dem Client in der betroffenen Filiale, einmal auf dem Server in der Zentrale. Wichtig dabei: Nur durch den Vergleich beider Captures lässt sich der Latenzbeitrag des WAN-Segments isolieren.

Im Client-seitigen Trace: RTT zwischen 80 und 140 ms, mit regelmäßigen Spitzen auf 300–400 ms zur Hauptarbeitszeit (9–11 Uhr, 13–15 Uhr). Keine Retransmissions, keine Packet-Loss-Indikatoren.

Im Server-seitigen Trace: Dieselben Verbindungen mit einer RTT von 8–12 ms – konsistent, ohne Spitzen.

Ergebnis: Die Latenz entstand vollständig auf dem WAN-Segment zwischen Filiale und Zentrale. Kein Netzwerkfehler im klassischen Sinne – aber eine klare Korrelation mit Hauptlastzeiten.

Ursache

Der MPLS-Provider-Link der Filiale war mit 10 Mbit/s dimensioniert. Zur Hauptarbeitszeit lief gleichzeitig ein Backup-Job, der den Link auf über 90 % Auslastung trieb. Das erzeugte Queuing Delay auf dem CE-Router des Providers – erkennbar an den zeitlich korrelierten RTT-Spitzen.

Die Lösung: QoS-Konfiguration auf dem CE-Router, um ERP-Traffic zu priorisieren, sowie mittelfristig eine Link-Erweiterung auf 50 Mbit/s. Nach der QoS-Implementierung: RTT stabil bei 15–20 ms, keine Spitzen mehr.

Dieses Szenario ist kein Einzelfall. Queuing-bedingte Latenz ist einer der häufigsten Gründe für WAN-Performance-Beschwerden – und ohne Wireshark-Trace bleibt es oft bei Schuldzuweisungen zwischen Admin und Provider.

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

TCP Window Size – der unterschätzte Faktor

Noch ein Punkt, der bei RTT-Analysen gerne übersehen wird: Die TCP Window Size bestimmt, wie viele Daten ein Sender in einem Zug schicken darf, bevor er auf ein ACK warten muss. Ist die Window Size zu klein, erzeugt das künstliche Wartezeiten – die sich im Trace wie hohe RTT anfühlen, aber eigentlich ein Durchsatzproblem sind.

Gerade auf WAN-Strecken mit hohem Bandwidth-Delay-Product ist das relevant. Wenn RTT hoch und Durchsatz trotzdem niedrig ist, lohnt sich ein Blick auf die Window Size. Mehr dazu erkläre ich im Artikel zu TCP Window Size und Window Scaling.

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 extrahieren. Entscheidend ist nicht nur der Wert selbst, sondern seine Einordnung in den Kontext: Wo wurde gecaptured? Welche Technologie liegt vor? Gibt es Spitzen oder konstant hohe Werte?

Die häufigsten Ursachen in der Praxis sind Queuing Delay auf überlasteten Links, Retransmissions durch Packet Loss, VPN-Overhead und – das wird oft unterschätzt – Serverantwortzeiten, die fälschlicherweise dem Netz zugeschrieben werden.

Mein Tipp für den Einstieg: Füge tcp.analysis.ack_rtt als Spalte in Wireshark ein, aktiviere den RTT Stream Graph und schau dir die nächste Latenzkompanie mit diesen Werkzeugen an. Du wirst schnell ein Gefühl dafür entwickeln, was normal ist – und was nicht.

Wenn du bei einer konkreten Analyse nicht weiterkommst oder einen zweiten Blick auf einen Trace brauchst, helfe ich gerne. Einfach melden.