TCP Retransmissions: Was sie bedeuten und wie man sie reduziert

TCP Retransmissions sind eines der wichtigsten Warnsignale im Netzwerk-Troubleshooting: Sie zeigen, dass ein TCP-Segment nicht (rechtzeitig) bestätigt wurde und deshalb erneut gesendet werden musste. In der Praxis äußert sich das als „langsame“ Anwendungen, zähe Downloads, ruckelnde Web-Apps, instabile VPNs oder sporadische Timeouts – häufig ohne offensichtlichen Komplettausfall. Gerade weil TCP Retransmissions in fast allen IP-Netzen vorkommen können, ist die richtige Interpretation entscheidend: Eine einzelne Retransmission ist nicht automatisch ein Drama, aber eine dauerhaft erhöhte Retransmission-Rate ist fast immer ein Hinweis auf Paketverlust, Congestion, MTU-/Fragmentierungsprobleme, Funkstörungen (WLAN), fehlerhafte Links (CRC), asymmetrisches Routing oder überlastete Endsysteme. Dieser Artikel erklärt verständlich und praxisorientiert, was Retransmissions bedeuten, wie TCP sie technisch auslöst (Timeout vs. Fast Retransmit), wie Sie sie mit Wireshark und Basis-Metriken korrekt einordnen und vor allem: welche Maßnahmen Retransmissions nachhaltig reduzieren – ohne blind Parameter zu drehen oder Symptome zu kaschieren.

Was sind TCP Retransmissions und warum gibt es sie überhaupt?

TCP ist ein zuverlässiges, verbindungsorientiertes Transportprotokoll. „Zuverlässig“ bedeutet: Daten sollen in der richtigen Reihenfolge ankommen – und zwar vollständig. Um das zu erreichen, nutzt TCP Sequenznummern und Bestätigungen (ACKs). Der Sender schickt Daten, der Empfänger bestätigt, welche Bytes angekommen sind. Bleibt die Bestätigung aus, geht TCP davon aus, dass ein Segment verloren gegangen ist oder unterwegs so stark verzögert wurde, dass es nicht mehr sinnvoll ist zu warten. Dann sendet TCP das Segment erneut: das ist eine Retransmission.

• Retransmission ≠ automatisch „Leitung kaputt“: Sie kann durch echten Paketverlust entstehen oder durch starke Verzögerung/Queueing.
• Retransmissions kosten Zeit: Sie erhöhen die effektive Latenz, reduzieren den Durchsatz und können Timeouts triggern.
• Retransmissions kosten Bandbreite: Daten werden erneut übertragen und belasten Links zusätzlich – ein Teufelskreis bei Congestion.

Die technischen Grundlagen von TCP (Sequenznummern, ACKs, Congestion Control) sind in RFC 9293 (TCP) beschrieben.

Wichtige Unterscheidung: Retransmission, Dup ACK, Fast Retransmit und RTO

In Tools wie Wireshark sehen Sie verschiedene „TCP Analysis“-Hinweise. Damit Sie die Ursache richtig einordnen, hilft ein kurzer Überblick über die wichtigsten Mechanismen:

• Duplicate ACKs: Der Empfänger bestätigt wiederholt den gleichen ACK-Wert, weil er eine Lücke in der Sequenz sieht (ein Segment fehlt).
• Fast Retransmit: Der Sender retransmittiert ein fehlendes Segment, nachdem er typischerweise drei Duplicate ACKs erhalten hat – ohne auf ein Timeout zu warten.
• RTO (Retransmission Timeout): Wenn keine ACKs kommen, läuft ein Timer ab und der Sender retransmittiert. Das ist meist „teurer“ als Fast Retransmit, weil es länger dauert.
• Spurious Retransmission: Das Segment war nicht wirklich verloren, sondern nur stark verzögert; TCP hat vorsorglich erneut gesendet.

Für Congestion-Control- und Retransmission-Mechanismen sind auch die Grundlagen zu TCP Congestion Control (RFC 5681) eine hilfreiche Vertiefung.

Warum Retransmissions den Durchsatz so stark drücken

Viele wundern sich: „Wir haben doch 1 Gbit/s – warum ist der Download langsam?“ Der Punkt ist, dass TCP-Durchsatz nicht nur von Bandbreite abhängt, sondern stark von RTT (Round Trip Time) und Verlust/Verzögerung. Je höher die RTT, desto mehr Daten müssen „in flight“ sein, um den Link zu füllen. Verlust oder Retransmissions zwingen TCP typischerweise dazu, das Congestion Window zu reduzieren. Das ist Absicht: TCP schützt das Netz, indem es bei Verlust weniger aggressiv sendet.

• Loss/Verlust interpretiert TCP als Congestion: Congestion Window sinkt → Durchsatz sinkt.
• Hohe RTT + Loss ist besonders schlecht: Jede Retransmission kostet mehr Zeit; Wiederanlauf dauert länger.
• Bei WLAN und WAN besonders sichtbar: Dort sind Latenzspitzen und sporadischer Verlust häufiger als im LAN.

Woher kommen TCP Retransmissions in der Praxis?

Retransmissions sind ein Symptom – die Ursachen liegen meist in wenigen Kategorien. Wenn Sie diese Kategorien sauber prüfen, finden Sie Root Causes deutlich schneller.

• Congestion/Queueing: Link überlastet, große Puffer (Bufferbloat), Shaper/Policer falsch dimensioniert.
• Physische Linkfehler: CRC/FCS-Errors, schlechte Kabel/Transceiver, Duplex/Speed-Mismatch.
• WLAN-Probleme: Interferenzen, Airtime-Überlastung, niedrige SNR, Retries auf 802.11-Ebene.
• MTU/PMTUD-Probleme: Große Pakete „hängen“, ICMP blockiert, MSS passt nicht.
• Asymmetrisches Routing: Rückweg anders als Hinweg, stateful Devices droppen, Capture sieht nur die Hälfte.
• Endsystemüberlastung: Server/Client CPU am Limit, NIC-Queues, Treiberprobleme, Storage langsam (Window Zero/Stalls).
• Middleboxes: Firewalls/Proxies/Load Balancer mit Inspection, die verzögert oder dropt.

Retransmissions messen und richtig bewerten

Ein häufiger Fehler ist, Retransmissions isoliert zu betrachten. Aussagekräftig werden sie erst im Kontext: Welche Rate, welche Richtung, welche Zeitfenster, welche betroffenen Anwendungen?

Pragmatische Kennzahlen

• Retransmission-Rate pro Flow: Einzelne Flows mit vielen Retransmissions sind oft leichter zu debuggen als ein globaler Wert.
• Retransmissions vs. Duplicate ACKs: Viele Dup ACKs deuten auf Lücken (echter Verlust oder Reordering) hin.
• RTT unter Last: Steigt RTT stark, ist Queueing/Congestion wahrscheinlich.
• Bytes vs. Packets: Viele kleine Pakete können PPS-Limits triggern, auch wenn Mbit/s moderat sind.

Was „normal“ ist

In der Realität sind 0 Retransmissions selten. Kurze Retransmissions bei WLAN, WAN oder stark dynamischen Pfaden können vorkommen. Kritisch wird es, wenn Retransmissions dauerhaft auftreten, anwenderrelevant sind (Timeouts, schlechte Performance) und mit anderen Indikatoren korrelieren (hohe RTT, Drops, CRC, WLAN Retries). Entscheidend ist nicht die Existenz, sondern das Muster.

Wireshark in der Praxis: Retransmissions sauber identifizieren

Wireshark ist das Standardwerkzeug, weil es TCP-Muster automatisch markiert. Damit Sie nicht im Mitschnitt versinken, arbeiten Sie mit klaren Filtern und einem reproduzierbaren Test (z. B. definierter Download, API-Call, Dateiübertragung).

• Nur einen Flow isolieren: z. B. über „Follow TCP Stream“ und dann „Conversation Filter“.
• Nur Retransmissions anzeigen: Display-Filter tcp.analysis.retransmission (Wireshark-Analysehinweis).
• Duplicate ACKs anzeigen: tcp.analysis.duplicate_ack.
• RTO/Timeout-Indikatoren: tcp.analysis.rto (je nach Wireshark-Version).
• Reset/Abbruch erkennen: tcp.flags.reset == 1.

Für einen praxisnahen Einstieg in Filter und Analyse eignet sich die Wireshark Dokumentation.

Typische Muster im Mitschnitt und ihre Interpretation

SYN wird gesendet, aber es kommt kein SYN/ACK

• Deutung: Kein TCP-Aufbau möglich; das ist noch keine klassische Retransmission im Datentransfer, sondern ein Reachability-/Firewall-/Routing-Thema.
• Ursachen: Firewall droppt, Ziel nicht erreichbar, falsches Routing, DNAT fehlt, Server down.

Viele Retransmissions direkt nach großen Datenblöcken

• Deutung: Häufig MTU/MSS/PMTUD – große Segmente kommen nicht durch, werden wiederholt.
• Ursachen: MTU kleiner als erwartet (VPN/Overlay), ICMP „Fragmentation Needed“ blockiert.

Hintergrundwissen liefert RFC 1191 (Path MTU Discovery).

Retransmissions + steigende RTT + Queue-Drops

• Deutung: Congestion/Bufferbloat. TCP bekommt ACKs später, interpretiert Verzögerung teils als Verlust, Window schrumpft.
• Ursachen: Uplink voll (Upload), fehlendes Shaping, Policer droppen, ISP-Link überlastet.

Duplicate ACKs, aber kaum Retransmissions

• Deutung: Kann auf Reordering hinweisen (Pakete kommen aus der Reihenfolge), z. B. durch Multipath/ECMP/SD-WAN.
• Ursachen: Asymmetrie, Load Balancing über mehrere Pfade, Tunneling/Overlay-Mechanismen.

Window Zero / Zero Window Probes

• Deutung: Der Empfänger kann nicht mehr annehmen. Das ist eher ein Endsystem-/Applikationsproblem als ein Netzproblem.
• Ursachen: Server überlastet, Storage langsam, Anwendung liest nicht, NIC/Kernel-Buffers voll.

Die schnellsten Checks außerhalb von Wireshark

Ein Mitschnitt ist stark, aber nicht immer der erste Schritt. Oft liefern einfache Counter die Ursache schneller – besonders bei physischen Linkproblemen oder überlasteten Interfaces.

• Interface-Counter: CRC/FCS-Errors, Input/Output Errors, Drops/Discards
• Duplex/Speed: Mismatch erzeugt oft viele Errors und Retransmissions
• WAN-Queueing: Latenz unter Last testen (Ping im Idle vs. bei Upload)
• WLAN-Health: SNR, Retries, Channel Utilization, Roaming-Events
• Servergesundheit: CPU/Load, NIC drops, TCP stack stats

Retransmissions reduzieren: Maßnahmen nach Ursache

Die beste Reduktion entsteht nicht durch „TCP-Tuning“, sondern durch das Beseitigen der zugrundeliegenden Ursache. Die folgenden Maßnahmen sind in der Praxis am wirkungsvollsten.

Congestion und Bufferbloat

• Shaping am Engpass: Uplink auf realistische Rate shapen (leicht unter ISP-Rate), damit Queues kontrolliert im eigenen Gerät entstehen.
• QoS sinnvoll einsetzen: Echtzeittraffic priorisieren, Bulk drosseln, nicht alles als „High“ markieren.
• Traffic-Fenster planen: Backups/Updates außerhalb der Kernzeit, CDN/Cache nutzen.

Physische Linkfehler (Layer 1/2)

• Kabel/Transceiver tauschen: CRC-Fehler sind häufig physisch.
• Speed/Duplex sauber verhandeln: Autonegotiation konsistent oder manuell konsistent auf beiden Seiten.
• Portstatistiken beobachten: Wenn Errors steigen, ist das Root Cause, nicht TCP.

WLAN als Verlustquelle

• 5 GHz/6 GHz bevorzugen: 2,4 GHz entlasten, Band-Steering moderat.
• Interferenzen reduzieren: Kanalplanung, Kanalbreite (20/40 MHz in dichten Umgebungen), Sendeleistung harmonisieren.
• Airtime entlasten: mehr AP-Kapazität, Mindestdatenraten sinnvoll, „laute“ Clients identifizieren.

MTU/MSS/PMTUD

• MTU entlang des Pfades prüfen: besonders bei VPN/SD-WAN/PPPoE/Overlays.
• ICMP nicht pauschal blocken: PMTUD braucht ICMP-Feedback.
• MSS-Clamping: in Firewalls/VPN-Gateways sinnvoll, wenn Pfade kleineren MTU haben.

Asymmetrisches Routing und Middleboxes

• Pfadsymmetrie herstellen: stateful Firewalls brauchen Hin- und Rückweg konsistent.
• ECMP/Load Balancing prüfen: Session-Affinität, Hashing, SD-WAN-Policy.
• Middlebox-Inspection bewerten: TLS-Inspection/Proxy kann Verzögerung/Drops verursachen; Kapazität prüfen.

Endsystem/Server

• Window-Zero ernst nehmen: Wenn der Empfänger bremst, ist das kein Leitungsproblem.
• NIC/Driver/Offload prüfen: Treiberbugs oder Offload-Einstellungen können Symptome erzeugen.
• Applikationsprofil: Viele parallele Sessions, kleine Writes, ineffiziente Patterns erzeugen mehr Stress im TCP-Stack.

TCP-Tuning: Wann es sinnvoll ist und wann nicht

TCP-Parameter (RTO-Min, Congestion Control Algorithm, Receive Window Auto-Tuning) können in Spezialfällen sinnvoll sein – etwa bei sehr langen RTTs oder bestimmten WAN-Optimierungen. In den meisten Unternehmensnetzen ist TCP-Tuning jedoch nicht die erste Wahl. Wenn Sie Retransmissions haben, ist fast immer ein Layer-1/2-Problem, Congestion/Queueing oder MTU die eigentliche Ursache. TCP-Tuning kann Symptome verschieben, aber selten die Ursache lösen.

Beweisführung: Was Sie für Tickets und interne Eskalationen dokumentieren sollten

Retransmissions sind ein hervorragender „Beweis“, wenn Sie ihn sauber belegen. Für Provider-Tickets oder die Zusammenarbeit zwischen Netzwerk- und Serverteam sind diese Punkte besonders wertvoll:

• Zeitfenster, betroffene Standorte/Links, Richtung (Upload/Download)
• Wireshark-Indikatoren: Retransmissions, Duplicate ACKs, RTOs, Window Zero
• Interface-Counter: Errors/Drops/Discards am Engpass
• RTT im Idle vs. unter Last (Bufferbloat-Nachweis)
• Pfad-/Top-Talker-Kontext (NetFlow/sFlow), wenn Congestion vermutet wird
• Nachweis „vor/nach“ einer Änderung (Kabeltausch, Shaping, MTU-Anpassung)

Outbound-Links zur Vertiefung

• RFC 9293: TCP – Spezifikation und Mechanismen
• RFC 5681: TCP Congestion Control – Fast Retransmit und Congestion Window
• RFC 1191: Path MTU Discovery – MTU-Probleme und Fragmentierung
• Wireshark Dokumentation – Display-Filter und TCP-Analyse
• RFC 2474: DiffServ/DSCP – QoS-Kontext bei Congestion

Checkliste: TCP Retransmissions verstehen und reduzieren

• Problem präzisieren: Welche Anwendung/Flows? Wann tritt es auf (Stoßzeiten, nur WLAN, nur WAN)?
• Engpass lokalisieren: Interface-Auslastung, Drops/Discards, RTT im Idle vs. unter Last.
• Wireshark-Flow isolieren: Conversation Filter, dann Retransmissions/Duplicate ACKs/RTOs prüfen.
• Muster interpretieren: Retransmissions nach großen Payloads (MTU), steigende RTT (Queueing), Window Zero (Endsystem).
• Layer 1/2 prüfen: CRC/FCS, Duplex/Speed, Kabel/Transceiver, Switchport-Errors.
• WLAN prüfen: SNR, Retries, Airtime/Channel Utilization, Band (5/6 GHz bevorzugen).
• MTU/PMTUD prüfen: ICMP-Handling, MSS-Clamping, Tunnel-Overhead, „klein geht, groß hängt“.
• Asymmetrie/Middleboxes prüfen: Pfadsymmetrie, stateful Drops, ECMP/SD-WAN, Proxy/Inspection-Kapazität.
• Maßnahme umsetzen: Shaping/QoS, physische Fehler beheben, WLAN optimieren, MTU korrigieren.
• Vorher/Nachher verifizieren: gleiche Tests, gleiche Zeitfenster, Retransmissions/RTT/Drops erneut messen und dokumentieren.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.