TCP Retransmissions: Netzwerkproblem oder Server/Stack?

TCP Retransmissions (TCP-Neuübertragungen) sind eines der häufigsten „Warnsignale“ im Netzwerkmonitoring – und zugleich eines der am häufigsten missinterpretierten. In vielen Tickets steht dann nur: „Retransmits steigen, Netzwerkproblem?“ Doch TCP Retransmissions sind kein eindeutiger Beweis für einen defekten Link oder einen schlechten Provider. Sie sind ein Symptom dafür, dass ein Sender ein Segment erneut sendet, weil es nicht rechtzeitig bestätigt (ACK) wurde oder weil der Empfänger signalisiert, dass Daten fehlen. Die Ursache kann im LAN/WAN liegen (Paketverlust, Queueing, Microbursts, MTU-Probleme, asymmetrische Pfade), aber ebenso im Server oder im TCP/IP-Stack (CPU-Pressure, Receive-Window-Limitierung, NIC-Ring-Overflow, Offloading-Bugs, aggressive Firewalls, Load Balancer). Wer Retransmissions sauber diagnostizieren will, muss end-to-end denken: Welche Art von Retransmission liegt vor? Wo im Pfad kippt das Signal? Und welche Evidenz belegt, ob das Netzwerk oder der Server/Stack limitiert? Dieser Artikel zeigt ein professionelles Vorgehen, um TCP Retransmissions eindeutig einzuordnen – mit praxistauglicher Methodik, typischen Mustern und High-Signal-Messpunkten, die On-Call-Teams wirklich weiterbringen.

Grundlagen: Was TCP Retransmissions sind und warum sie auftreten

TCP ist ein zuverlässiges Transportprotokoll: Es nummeriert Daten (Sequenznummern), bestätigt Empfang (ACKs) und steuert die Senderate (Congestion Control). Retransmissions passieren, wenn der Sender glaubt, dass Daten nicht angekommen sind oder wenn er durch Feedback erkennt, dass Segmente fehlen. Wichtig: TCP „weiß“ nicht, warum etwas fehlt – es sieht nur „ACK kommt nicht“ oder „Empfänger meldet Lücke“. Genau deshalb sind Retransmissions ein Symptom, keine Diagnose.

• RTO Retransmission: Retransmission nach Ablauf eines Retransmission Timeout (ACK blieb aus).
• Fast Retransmit: Retransmission, weil mehrere Duplicate ACKs auf eine Lücke hinweisen.
• Spurious Retransmission: Retransmission, obwohl das Paket doch ankam (z. B. durch starkes Delay/Reordering).
• Tail Loss: Verlust am Ende eines Transfers, oft sichtbar als kurze Hänger/Timeouts.

Für eine belastbare, standardnahe Einordnung von TCP-Mechanismen ist RFC 9293 (Transmission Control Protocol) die zentrale Referenz.

Retransmission ist nicht gleich Paketverlust: Die häufigsten Fehlannahmen

In der Praxis sind Retransmissions oft der Auslöser für Eskalationen – und genau hier passieren typische Denkfehler.

• Fehlannahme: „Retransmits = Loss im Netzwerk.“ Realität: Retransmits können auch durch Delay, Reordering oder Receiver-Backpressure entstehen.
• Fehlannahme: „Ping ist ok, also kein Netzwerkproblem.“ Realität: ICMP kann priorisiert/gedrosselt werden; TCP-Datenpfad kann anders behandelt werden.
• Fehlannahme: „Link ist nicht ausgelastet, also keine Congestion.“ Realität: Microbursts erzeugen Queueing/Drops trotz moderater Durchschnittsauslastung.
• Fehlannahme: „Server antwortet langsam, also Serverproblem.“ Realität: Retransmits können Serverantworten verlangsamen, obwohl der Server selbst gesund ist.

Symptome in messbare Signale übersetzen

Bevor Sie in PCAPs und Counters abtauchen, übersetzen Sie die Beschwerden in Signale. So vermeiden Sie, dass Sie Retransmissions „jagen“, ohne den Impact zu verstehen.

• „Downloads langsam“ → Goodput sinkt, Retransmits steigen, RTT/Jitter können steigen
• „API Timeouts“ → Tail Loss, RTOs, späte ACKs, eventuell MTU/PMTUD
• „Nur manche Nutzer“ → ECMP/Member-Problem, Load Balancer Node, Pfadabhängigkeit
• „Nur große Transfers“ → MTU/MSS/PMTUD, Fragmentation/ICMP-Block

Die entscheidende Trennfrage: Netzwerkproblem oder Server/Stack?

Um Retransmissions korrekt zuzuordnen, brauchen Sie eine klare, evidenzbasierte Trennung. Dafür sind drei Achsen besonders wirksam:

• Ort: Wo sehen Sie die Retransmissions? (Client, Server, Middlebox, beidseitig?)
• Muster: Sind es Fast Retransmits (Duplicate ACKs) oder RTOs (Timeouts)?
• Korrelation: Korrelieren Retransmissions mit Queue Drops/Errors/Policers (Netz) oder mit CPU/I/O/Socket-Queues (Server)?

High-Signal Diagnostik: Welche Daten wirklich helfen

Retransmissions lassen sich am schnellsten einordnen, wenn Sie wenige, aber aussagekräftige Datenquellen kombinieren.

• PCAP (gezielt): Sequenz-/ACK-Verlauf, Duplicate ACKs, RTO, SACK, Windowing
• End-to-End Telemetrie: RTT (P95/P99), Loss, Jitter, insbesondere zu Peak-Zeiten
• Interface/Queue Counters: Errors (CRC/FCS), Discards, Output Drops, Queue Drops pro Klasse
• QoS/Policer: Policer Hits, class-based drops, Shaping-Statistiken
• Server-Metriken: CPU-Steal, SoftIRQ, NIC Drops, TCP Stack Stats, Socket Backlog, I/O Pressure
• Flow-Daten: Top Talker, Burst-Muster, Traffic-Shifts (Microbursts-Indiz)

Für praktikable Capture- und Analyseworkflows sind die Wireshark-Dokumentation und die tcpdump-Manpage besonders hilfreich.

PCAP-Muster lesen: Was Retransmissions Ihnen wirklich verraten

Ein Packet Capture ist die schnellste „Ground Truth“, wenn es um TCP geht – vorausgesetzt, Sie interpretieren die Muster richtig. Ziel ist nicht, jedes Feld zu erklären, sondern die wenigen Indikatoren zu erkennen, die Netzwerk vs. Server/Stack trennen.

Fast Retransmit mit Duplicate ACKs

• Typisches Bild: Empfänger sendet mehrere Duplicate ACKs für dieselbe Sequenznummer; Sender retransmittet „missing segment“ schnell.
• Interpretation: Es gab wahrscheinlich Loss oder starkes Reordering auf dem Pfad. Loss ist wahrscheinlicher, wenn gleichzeitig Drops/Errors sichtbar sind.
• Netzwerk-Indiz: Queue Drops, Policer Drops, CRC/FCS-Errors, Microburst-Korrelation.

RTO Retransmissions (Timeout-basiert)

• Typisches Bild: ACKs bleiben aus, dann retransmittet der Sender nach Timeout; oft mit exponentiellem Backoff.
• Interpretation: Entweder massiver Loss, sehr hohe Verzögerung/Queueing oder ein Pfad-/State-Problem (Firewall/NAT/Asymmetrie).
• Server-/Stack-Indiz: Empfänger ist „still“, weil er nicht schedulen kann (CPU/SoftIRQ), oder weil Receive Queues überlaufen.

Zero Window / Window Shrinking

• Typisches Bild: Empfänger kündigt ein sehr kleines oder null Receive Window an; Sender stoppt und sendet später Window Probes.
• Interpretation: Kein klassisches Netzwerk-Loss: Der Empfänger kann Daten nicht schnell genug verarbeiten (Application/Kernel/Buffer/Storage).
• Typische Ursache: Server überlastet, langsame Disk, zu kleine Socket-Buffer, App liest nicht.

Spurious Retransmissions durch Delay/Reordering

• Typisches Bild: Retransmission, aber kurz danach kommt das „originale“ Segment doch an; ACKs zeigen, dass nichts fehlte.
• Interpretation: Starke Latenzspitzen oder Reordering (z. B. ECMP, Pfadwechsel, Queueing) können TCP „täuschen“.
• Hinweis: Prüfen Sie Pfadinstabilität (SD-WAN Failover/Failback, Routing Events) und Queueing-Indikatoren.

Netzwerkursachen: Wenn Retransmissions wirklich „im Netz“ entstehen

Wenn Retransmissions durch das Netzwerk getrieben sind, sehen Sie meist weitere Signale: Drops, Errors, Queueing, Jitter/RTT-Peaks oder Pfadwechsel. Die folgenden Ursachen sind in Enterprise-LAN/WAN am häufigsten.

Queueing und Microbursts

• Mechanismus: Kurzzeitige Congestion füllt Queues; Delay steigt; bei vollem Buffer entstehen Drops; TCP retransmittet.
• Signale: P95/P99 RTT-Spikes, Queue Drops, Retransmits in kurzen Fenstern, Durchschnittsauslastung moderat.
• Typische Orte: Campus-Uplinks, WAN-Egress, Data-Center-Fan-in, SD-WAN Edges.

Physikalische Fehler (L1/L2)

• Mechanismus: Frames werden durch CRC/FCS verworfen; höher oben wirkt es wie Paketverlust.
• Signale: CRC/FCS-Errors, Link Flaps, sporadische Retransmits auch bei niedriger Last.
• Fix-Richtung: Medium/Transceiver/Port prüfen, Optikwerte, Patchen, Entstörung.

Policing/Shaping (Provider oder QoS)

• Mechanismus: Policer dropt Bursts oder begrenzt Rate; TCP reagiert mit Retransmits und reduziert cwnd.
• Signale: Policer Hits, Drops in bestimmten Klassen, Throughput „gedeckelt“.
• Fix-Richtung: Edge-Shaping (glätten) statt Provider-Policing, QoS-Parameter anpassen.

MTU/PMTUD-Probleme

• Mechanismus: Zu große Pakete werden verworfen, Fragmentation/PMTUD ist gestört; Retransmits steigen, Transfers hängen.
• Signale: kleine Requests ok, große Transfers hängen; Retransmits besonders bei großen Segmenten/Records.
• Fix-Richtung: MSS-Clamping, ICMP für PMTUD gezielt erlauben, Tunnel-Overhead korrekt berücksichtigen.

ECMP/Asymmetrie/Middleboxes

• Mechanismus: Teil der Flows landet auf „schlechtem“ Pfad oder Rückweg ist asymmetrisch; Stateful Geräte droppen.
• Signale: nur manche Nutzer/Flows betroffen; Probleme sind flow-sticky und reproduzierbar.
• Fix-Richtung: fehlerhaften Member drainen, Pfad stabilisieren, Symmetrie sicherstellen.

Server- und Stack-Ursachen: Wenn Retransmissions durch Endsysteme getrieben werden

Viele Retransmission-Tickets sind in Wahrheit System- oder Applikationsprobleme, die TCP-Symptome erzeugen. Entscheidend ist: Der Sender retransmittet, weil ACKs fehlen oder verzögert sind – und genau diese Verzögerung kann durch den Empfänger verursacht sein.

CPU-Pressure und SoftIRQ-Backlogs

• Mechanismus: NIC-Interrupts/SoftIRQs werden nicht rechtzeitig abgearbeitet; Pakete warten, ACKs kommen spät; Sender retransmittet.
• Signale: Retransmits ohne passende Drops im Netzwerk; erhöhte CPU/Steal; unregelmäßige ACK-Patterns.
• Fix-Richtung: CPU- und IRQ-Affinity prüfen, Ressourcen erhöhen, noisy neighbors (VM) reduzieren.

NIC-Ring-Overflow und Kernel Drops

• Mechanismus: RX-Ring oder Kernel-Queues laufen voll; Pakete werden am Host gedroppt, ohne dass das Netz es „weiß“.
• Signale: Host-seitige Drop-Counter steigen; Netzwerkinterfaces zeigen keine Errors; Retransmits steigen.
• Fix-Richtung: Treiber/Offloads, Ring-Größen, Kernel-Tuning, CPU-Headroom.

Receive Window / Application Backpressure

• Mechanismus: Anwendung liest langsam, Socket-Buffer füllen sich; Empfänger kündigt kleines/Zero Window an; Sender stoppt oder retransmittet bei Timeouts.
• Signale: Zero Window, Window Probes, geringe Window-Größe, hohe App-Latenz, I/O Pressure.
• Fix-Richtung: Applikation und Storage optimieren, Socket-Buffer, Threading, I/O.

TLS/Proxy/Load Balancer als „Server-Limit“

• Mechanismus: Termination/Inspection kostet CPU; Session-Handling wird eng; ACKs/Responses verzögern sich.
• Signale: Retransmits korrelieren mit LB/Firewall CPU oder Session-Pressure; oft nur bestimmte Services.
• Fix-Richtung: Kapazität/Scale-out, Policy anpassen, TLS-Settings, Session-Timeouts prüfen.

Trennmessungen: Die schnellsten Tests für eine eindeutige Zuordnung

Wenn Sie wenig Zeit haben, nutzen Sie Trennmessungen, die mehrere Ursachenfamilien auf einmal ausschließen.

• Beidseitiger Capture: PCAP am Client und am Server: Fehlt ein Segment schon am Server-Eingang oder wird es erst im Host gedroppt?
• Alternativer Pfad: gleicher Service über zweiten Standort/ISP/VPN-Gateway: bleibt es, ist Server/Service wahrscheinlicher.
• Single Stream vs. Multi Stream: nur Single Stream langsam → RTT/Windowing/Serverlimit; Multi Stream ok kaschiert.
• Klein vs. groß: nur große Transfers betroffen → MTU/PMTUD/MSS oder Policing-Bursts.
• Hostwechsel: anderer Client/anderer Server: wenn Problem „mitwandert“, ist das Endsystem ein starker Kandidat.

Ein praktisches Runbook: Retransmissions in 15 Minuten einordnen

Dieses Muster hilft On-Call Engineers, schnell zur wahrscheinlichsten Domäne zu kommen, ohne in Tool-Hopping zu verfallen.

• Minute 0–3: Scope definieren (welche Services, welche Standorte, nur bestimmte Flows, seit wann?).
• Minute 3–6: Golden Signals prüfen (P95/P99 RTT, Loss, Drops/Errors, Queue Drops, Policer Hits).
• Minute 6–9: Pfad verifizieren (SD-WAN/ECMP, NAT/Firewall, Asymmetrie). Trennmessung via alternativem Pfad, wenn möglich.
• Minute 9–12: Server/Stack-Checks (CPU/SoftIRQ, NIC Drops, Windowing/Zero Window Indikatoren, LB/Firewall Pressure).
• Minute 12–15: Gezielt PCAP (kurz, gefiltert) oder Member drainen/Path pinnen als Low-Risk Mitigation; anschließend Verifikation gegen Baseline.

Verifikation: Wie Sie beweisen, dass der Fix wirklich wirkt

Retransmissions verschwinden nicht immer vollständig, aber sie müssen in den Normalbereich zurückkehren. Professionelle Verifikation bedeutet: gleiche Messpunkte, gleiche Zeitfenster, Vorher/Nachher.

• Retransmit-Rate: deutlich sinkend und stabil im Normalbereich
• P95/P99 Latenz: Peaks gehen zurück, Jitter stabilisiert
• Queue Drops/Errors: steigen nicht weiter (oder sind dauerhaft beseitigt)
• Service-Sicht: Timeouts, Retries und Nutzerbeschwerden sinken messbar

Weiterführende Quellen für Standards und Analysepraxis

• RFC 9293 (TCP) für Retransmissions, Windowing und Transportmechanik
• RFC 791 (Internet Protocol) für IP-Grundlagen, MTU und Fragmentation als häufige Retransmit-Ursache
• Wireshark Dokumentation für TCP-Analyse, SACK/ACK-Muster und Timing-Interpretation
• tcpdump Manpage für performantes Capturing und BPF-Filter
• RFC Editor als Primärquelle für Netzwerkstandards und saubere Protokollinterpretation

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.