TCP Retransmissions, Dup ACKs und Out-of-Order – Was die Unterschiede wirklich bedeuten

Wer zum ersten Mal eine Wireshark-Aufzeichnung öffnet und rote Einträge sieht, fragt sich sofort: Ist das ein Problem? Die Antwort ist: kommt drauf an. TCP Retransmissions, Duplicate ACKs und Out-of-Order Pakete sehen in der Paketliste ähnlich aus, haben aber völlig unterschiedliche Ursachen und Konsequenzen. Einsteiger verwechseln sie regelmäßig – mit dem Ergebnis, dass harmlose Ereignisse als Alarmsignal gewertet werden oder echte Probleme unentdeckt bleiben.

Dieser Artikel erklärt, was hinter den drei Ereignissen steckt, wann tatsächlich Handlungsbedarf besteht – und wie du mit den richtigen Wireshark-Filtern schnell den Überblick behältst. Wenn du dich außerdem fragst, warum manche Verbindungen immer wieder sporadisch abreißen, lohnt sich auch ein Blick in den Artikel über sporadische Verbindungsabbrüche analysieren.

Was Wireshark dir zeigt – und was es bedeutet

Wireshark färbt Pakete automatisch ein, sobald seine TCP-Analyse-Engine auffällige Muster erkennt. Schwarz hinterlegt sind meist Pakete mit TCP-Fehlern wie Retransmissions. Gelb steht häufig für weniger kritische Hinweise wie Dup ACKs. Rot kann auf ernstere Probleme wie TCP RST oder Paketverlust hinweisen.

Das Wichtigste vorab: Nicht jede Markierung bedeutet ein Problem. Wireshark markiert, was statistisch auffällig ist – nicht zwingend, was funktional gestört ist. Die Interpretation hängt immer vom Kontext ab: Wie viele solcher Ereignisse gibt es? Auf welchem Stream? In welchem zeitlichen Abstand? Erst diese Fragen führen zur richtigen Diagnose.

TCP Retransmission – das Paket wurde wirklich neu gesendet

Eine TCP Retransmission bedeutet: Der Sender hat ein Paket neu übertragen, weil er innerhalb des Retransmission Timeout (RTO) keine Bestätigung (ACK) erhalten hat. Der RTO-Mechanismus ist Teil des TCP-Congestion-Control-Mechanismus und passt sich dynamisch an die Netzwerkbedingungen an – er startet meist bei wenigen hundert Millisekunden und kann nach mehreren Timeouts exponentiell auf mehrere Sekunden anwachsen (Backoff).

Typische Ursachen für TCP Retransmissions:

• Echter Paketverlust – das Paket ist im Netz verloren gegangen
• Überlastete Leitungen – Bufferüberlauf an einem Switch oder Router
• Defekte Hardware – fehlerhafte Netzwerkkarte, schlechte SFP-Module, CRC-Fehler
• Firewalls oder Middleboxes – ACKs werden verzögert oder blockiert

Wireshark-Filter: tcp.analysis.retransmission. Wann wird es kritisch? Wenn wiederholte Retransmissions auf demselben Stream auftreten. Eine einzelne Retransmission ist in einem produktiven Netz keine Seltenheit. Zehn oder zwanzig innerhalb weniger Sekunden auf derselben Verbindung hingegen deuten auf ein strukturelles Problem hin.

Ein wichtiger Hinweis für die Praxis: Wireshark kann falsch-positive Retransmissions anzeigen, wenn der Mitschnitt an der falschen Stelle im Netzwerkpfad gemacht wurde – zum Beispiel auf einem Interface, das den Traffic erst nach dem eigentlichen Retransmit-Punkt sieht. Dann erscheint ein Paket doppelt, obwohl es im eigentlichen Übertragungsweg korrekt war. Capture-Punkt immer dokumentieren. Mehr dazu, wie sich Retransmissions auf die Gesamtperformance auswirken, findest du im Artikel über TCP Retransmissions und Performance.

Fast Retransmit – der schnelle Bruder

Der Fast Retransmit ist eine Optimierung innerhalb von TCP: Statt auf den RTO-Ablauf zu warten, löst der Empfang von drei aufeinanderfolgenden Duplicate ACKs sofort eine erneute Übertragung aus. Das klingt nach demselben Ergebnis – ein Paket wird neu gesendet –, aber der Unterschied liegt im Timing und in den Auswirkungen auf das Congestion Window.

Bei einem RTO-Retransmit bricht das Congestion Window stark ein – TCP muss annehmen, dass das Netz überlastet war, und startet den Slow-Start neu. Beim Fast Retransmit hingegen reduziert TCP das Congestion Window nur auf die Hälfte (Fast Recovery), ohne auf null zurückzufallen. Das bedeutet: Fast Retransmit ist deutlich weniger schädlich für den Durchsatz als ein klassischer RTO-Retransmit.

Wireshark-Filter: tcp.analysis.fast_retransmission. Das Ereignis zeigt trotzdem, dass ein Paket verloren gegangen ist – es ist also kein Freifahrtschein. Aber wenn du zwischen den beiden Arten unterscheidest, kannst du besser einschätzen, wie stark der Durchsatz tatsächlich beeinträchtigt wird. Details zum Zusammenhang mit dem Congestion Window und Window Scaling findest du im verlinkten Artikel.

Duplicate ACK – der Hinweis, nicht das Problem

Ein Duplicate ACK (Dup ACK) ist keine Fehlermeldung – es ist ein Signal. Der Empfänger teilt dem Sender mit: „Ich habe die Pakete bis Sequenznummer X erhalten, aber das nächste erwartete Paket fehlt noch.” Dazu bestätigt er erneut dieselbe Sequenznummer.

Dup ACKs entstehen, wenn Pakete außer der Reihe ankommen: Paket 1 und 3 sind da, Paket 2 fehlt noch. Der Empfänger quittiert weiterhin Paket 1 – und jede neue Quittung von Paket 1 ist ein Dup ACK.

Wichtig: Dup ACKs allein sind kein Alarmsignal. Der häufigste Einsteigerfehler ist, Dup ACKs zu zählen und daraus eine Paketverlustrate zu berechnen. Das ist falsch. Ein einziges verlorenes Paket kann Dutzende von Dup ACKs erzeugen. Die Anzahl der Dup ACKs sagt nichts über die Anzahl verlorener Pakete aus.

Wireshark-Filter: tcp.analysis.duplicate_ack. Wann solltest du trotzdem genauer hinschauen? Wenn viele Dup ACKs auftreten, ohne dass ein darauffolgendes Fast Retransmit oder eine Retransmission sichtbar ist. Das kann ein Hinweis sein, dass die Kette unterbrochen ist – oder dass der Mitschnitt unvollständig ist.

Out-of-Order – Pakete kommen in falscher Reihenfolge an

Out-of-Order Pakete entstehen, wenn TCP-Segmente verschiedene Pfade durch das Netz nehmen und deshalb in einer anderen Reihenfolge ankommen, als sie gesendet wurden. TCP ist ein sequenzielles Protokoll – es erwartet Pakete in der Reihenfolge ihrer Sequenznummern. Wenn Paket 3 vor Paket 2 ankommt, ist das für TCP zunächst ein Problem, das behoben werden muss.

In vielen Netzwerken ist Out-of-Order absolut normal. Besonders bei LACP/Bonding-Konfigurationen – also gebündelten Netzwerkverbindungen – ist Reordering fast unvermeidlich, weil der Traffic über mehrere physische Links verteilt wird, die leicht unterschiedliche Latenzen haben können. Wer dort Out-of-Order sieht und daraus auf ein Netzwerkproblem schließt, liegt meistens falsch.

Das Problem: Out-of-Order kann Dup ACKs auslösen, die dann wiederum einen Fast Retransmit triggern – auch wenn eigentlich kein Paket verloren gegangen ist. Diese Kette Out-of-Order → Dup ACK → Fast Retransmit sieht man im realen Trace regelmäßig. Der Fast Retransmit ist dann technisch gesehen unnötig, aber TCP weiß das nicht – es reagiert auf die ACKs, nicht auf die „wahre” Ursache.

Wireshark-Filter: tcp.analysis.out_of_order. Praxistipp: Wenn du in einer LACP- oder Bonding-Umgebung arbeitest und dort Out-of-Order siehst, ist das mit hoher Wahrscheinlichkeit kein Netzwerkfehler, sondern ein Designmerkmal. Anders sieht es aus bei asymmetrischem Routing oder wenn Out-of-Order plötzlich auftritt, obwohl die Konfiguration unverändert ist.

Die drei im Vergleich – eine Entscheidungshilfe

Die folgende Tabelle gibt einen schnellen Überblick über die wichtigsten Unterschiede:

Was bedeutet es, wenn alle drei gleichzeitig auftreten?

Das ist die klassische Kette, die auf echten Paketverlust oder schwere Netzwerkprobleme hinweist: Out-of-Order führt zu Dup ACKs, Dup ACKs lösen Fast Retransmit aus. Wenn dann zusätzlich noch RTO-Retransmissions erscheinen, also reguläre Retransmissions nach Timeout-Ablauf, deutet das auf einen anhaltenden oder starken Paketverlust hin. In solchen Situationen lohnt es sich, den Stream gezielt zu isolieren und den Zeitverlauf der Ereignisse zu analysieren.

Praktisches Vorgehen in Wireshark

Der schnellste Einstieg in eine neue Trace-Datei führt über Analyze → Expert Information. Dort fasst Wireshark alle erkannten TCP-Ereignisse zusammen, kategorisiert nach Schweregrad. Du siehst auf einen Blick, ob die Probleme systemisch (viele betroffene Streams) oder sporadisch (ein einzelner Stream, einmalig) sind.

So gehst du in der Praxis vor:

• Expert Information checken – wie viele Retransmissions, Dup ACKs, OOO-Pakete gibt es insgesamt?
• Stream isolieren – Rechtsklick auf ein auffälliges Paket → Follow → TCP Stream
• Zeitachse prüfen – treten die Ereignisse regelmäßig auf oder in Burst-Phasen?
• Kombination bewerten – RTO-Retransmissions allein sind kritischer als Fast Retransmits allein
• Capture-Punkt beachten – falsch-positive Retransmissions entstehen oft durch ungeeignetes Capture-Interface

Wann tiefer einsteigen? Wenn RTT (Round Trip Time) und Retransmission-Rate gemeinsam steigen, wenn die Performance-Klagen der Anwender mit den Ereignissen im Trace zeitlich korrelieren, oder wenn RTO-Retransmissions auf mehreren Streams gleichzeitig auftreten. Wann ignorieren? Bei vereinzelten Dup ACKs ohne Folgereaktion und bei Out-of-Order in bekannten LACP-Umgebungen. Eine vollständige Referenz der nützlichsten Filter findest du im Artikel über die 10 wichtigsten Wireshark Display-Filter.

Fazit und Handlungsempfehlung

TCP Retransmission, Duplicate ACK und Out-of-Order sind keine gleichwertigen Signale. Wer sie auseinanderhält, spart bei der Fehlersuche enorm viel Zeit – und vermeidet falsche Schlüsse.

Die wichtigsten Takeaways:

• RTO-Retransmissions sind das ernsthafteste Signal: echter Timeout, hartes Congestion-Window-Einbruch, strukturelles Problem wahrscheinlich.
• Fast Retransmit zeigt Paketverlust, aber mit deutlich geringerem Throughput-Impact als der RTO-Weg.
• Dup ACKs allein sind kein Problem – die Häufung und der Kontext zählen, nicht die absolute Anzahl.
• Out-of-Order ist in LACP/Bonding-Umgebungen normal und in der Regel kein Handlungsbedarf.
• Die Kette Out-of-Order → Dup ACK → Fast Retransmit ist ein häufiges Muster und muss nicht zwingend kritisch sein.

Für eine fundierte TCP Fehleranalyse empfiehlt sich der Einsatz von Expert Information als Einstieg, gefolgt von gezielter Stream-Analyse. Wer regelmäßig Netzwerkprobleme analysiert, sollte die Wireshark-Filter für alle vier Ereignistypen kennen und anwenden können.

Du arbeitest an einem konkreten Netzwerkproblem und kommst bei der Analyse nicht weiter? Oder du möchtest einen Trace professionell auswerten lassen? Ich unterstütze Unternehmen bei der strukturierten Netzwerkanalyse und Fehlerdiagnose – von der initialen Wireshark-Aufzeichnung bis zur abgesicherten Root-Cause-Analyse.

FAQ

Was ist der Unterschied zwischen TCP Retransmission und Fast Retransmit?

Bei einer regulären TCP Retransmission ist der Retransmission Timeout (RTO) abgelaufen, ohne dass eine Bestätigung eingegangen ist. Das führt zu einem starken Einbruch des Congestion Windows. Ein Fast Retransmit hingegen wird durch drei Duplicate ACKs ausgelöst – noch bevor der Timeout abläuft. Das Congestion Window sinkt nur auf die Hälfte, der Durchsatz erholt sich schneller.

Sind Duplicate ACKs ein Zeichen für Paketverlust?

Nicht zwingend. Duplicate ACKs entstehen, sobald der Empfänger eine Lücke in der Sequenznummer erkennt – das kann auch durch Out-of-Order-Pakete passieren, ohne dass tatsächlich ein Paket verloren gegangen ist. Erst wenn drei Dup ACKs aufeinanderfolgen und ein Fast Retransmit ausgelöst wird, ist Paketverlust sehr wahrscheinlich.

Warum zeigt Wireshark Retransmissions, obwohl das Netz in Ordnung ist?

Das ist ein typischer Fall von falsch-positiven Retransmissions. Sie entstehen, wenn der Mitschnitt nicht am richtigen Punkt im Netzwerkpfad gemacht wurde. Wird ein Paket z.B. auf einem Interface aufgezeichnet, das den Traffic nach dem Retransmit-Punkt sieht, erscheint dasselbe Paket zweimal – Wireshark markiert es als Retransmission, obwohl es kein echtes Problem war. Immer den Capture-Punkt dokumentieren und in die Analyse einbeziehen.

Wie erkenne ich, ob Out-of-Order Pakete in meiner Umgebung normal sind?

Prüfe zunächst, ob im Netzwerk LACP, Link Aggregation oder Bonding eingesetzt werden. Falls ja, ist Out-of-Order nahezu unvermeidlich und in aller Regel unkritisch. Wenn Out-of-Order hingegen in einer Umgebung ohne Bonding plötzlich auftaucht oder mit Performanceproblemen korreliert, ist eine tiefere Analyse angebracht – zum Beispiel auf asymmetrisches Routing oder Konfigurationsänderungen an Switches und Routern.

Tags: TCP Retransmission · Duplicate ACK · Out-of-Order Pakete · Wireshark · Fast Retransmit · TCP Überlastverhalten · Paketverlust erkennen · TCP Fehleranalyse · Congestion Control