Ohne PCAP: TCP-Retransmissions über Metriken erkennen

TCP-Retransmissions über Metriken erkennen zu können, ist in der Praxis oft wertvoller als ein einzelner Packet Capture – insbesondere dann, wenn PCAP aus Datenschutz-, Performance- oder Zugriffsgründen nicht möglich ist. Retransmissions sind ein zentrales Symptom für Paketverlust, Überlast, fehlerhafte Links, Queue Drops, fehlerhaftes MTU/PMTUD-Verhalten oder ungünstige Pfade. Gleichzeitig sind sie ein „still killer“ für Latenz: Selbst wenn Anwendungen keine harten Fehler melden, steigen Response-Zeiten und Timeouts, weil TCP verlorene Segmente erneut senden muss und dabei auf Timeouts, Duplicate ACKs oder Fast Retransmit reagiert. Der entscheidende Punkt ist: Sie müssen Retransmissions nicht zwingend mit Wireshark nachweisen. Mit den richtigen Metriken aus Betriebssystem, Load Balancer, Proxy, Service Mesh und Observability-Stack lassen sich TCP-Retransmissions zuverlässig identifizieren, eingrenzen und trendbasiert alarmieren – ohne in Paketdaten zu schauen. Dieser Artikel zeigt Methoden, Kennzahlen, Interpretation und Tooling, damit Sie Retransmissions messbar machen und in ein sauberes Troubleshooting überführen.

Was TCP-Retransmissions wirklich bedeuten

TCP garantiert zuverlässige Übertragung. Wenn ein Segment nicht bestätigt wird, wird es erneut gesendet. Das kann passieren, weil das Segment im Netz verloren geht, weil es verworfen wird (Drops), weil ACKs verloren gehen oder weil die Gegenstelle überlastet ist und nicht rechtzeitig reagiert. Für die Praxis wichtig: Retransmissions sind keine „Schuldzuweisung“. Sie sind ein Indikator, dass die Übertragung nicht glatt läuft – und sie entstehen in unterschiedlichen Mechanismen.

• Fast Retransmit: Retransmission nach mehreren Duplicate ACKs – typisch bei echtem Paketverlust, aber auch bei Reordering.
• RTO-basierte Retransmission: Retransmission nach Ablauf des Retransmission Timeout (RTO) – meist gravierender, weil die Wartezeit Latenz stark erhöht.
• Spurious Retransmission: „Unnötige“ Retransmission, z. B. durch starkes Reordering oder zu aggressives Timing.

Für fundierte Grundlagen sind die TCP-Spezifikationen und Empfehlungen hilfreich, etwa RFC 5681 (TCP Congestion Control) und RFC 6298 (Computing TCP’s Retransmission Timer).

Warum Retransmissions ohne PCAP messbar sind

Auch ohne Paketmitschnitt existieren mehrere Beobachtungsebenen, die Retransmissions indirekt oder direkt als Zähler erfassen:

• Kernel- und OS-Metriken: Linux und andere Systeme zählen Retransmits, RTO-Events, Duplicate ACKs, Out-of-Order-Segmente und mehr.
• Socket- und Flow-Sicht: Tools wie ss oder eBPF liefern per-Connection-Indikatoren.
• Proxy/Load-Balancer-Metriken: Termination-Points sehen Handshake-Fehler, Resets, Timeouts und teilweise Retransmit-nahe Signale (z. B. Upstream-Connect-Latenz).
• Applikations- und SLO-Sicht: Retransmissions zeigen sich als steigende P95/P99-Latenz, erhöhte Timeouts, Retries und Abbrüche.

Der Schlüssel ist Korrelation: Retransmission-Metriken allein zeigen „Symptom“, in Kombination mit Latenz, Drops, Queueing und Fehlerquoten entsteht ein belastbares Bild.

Die wichtigsten Metriken, um TCP-Retransmissions zu erkennen

Retransmissions (absolut) und Retransmission Rate

Die absolute Zahl von Retransmits ist stark lastabhängig. Aussagekräftiger ist oft eine Rate oder ein Verhältnis zu gesendeten Segmenten/Bytes. Je nach Datenquelle können Sie Retransmits pro Sekunde oder als Prozentanteil messen.

$\mathrm{RetransmissionRate}=\frac{\mathrm{retransmittedSegments}}{\mathrm{totalSentSegments}}$

Wenn Ihnen „totalSentSegments“ nicht verfügbar ist, kann eine Byte-basierte Näherung helfen (Retransmit-Bytes / Sent-Bytes). Wichtig ist weniger die perfekte Physik als eine stabile, vergleichbare Definition.

RTO-Events und Timeouts

RTO-basierte Retransmissions sind meist kritischer als Fast Retransmit, weil sie Wartezeit erzwingen. Wenn Ihre Metriken RTO/Timeouts abbilden, sind sie ein besonders starkes Signal für echte Störungen (Loss oder starke Verzögerung).

Duplicate ACKs und Out-of-Order

Duplicate ACKs häufen sich bei Verlust, können aber auch bei Reordering auftreten. Out-of-Order-Segmente deuten auf Pfadvariabilität, ECMP-Effekte oder asymmetrische Last hin. In Kombination mit Retransmits sind sie hilfreich, um „Loss“ von „Reordering“ abzugrenzen.

TCP Reset (RST) und Zero Window

RST ist kein Retransmit, aber ein wichtiges Begleitsymptom: Wenn Verbindungen abrupt beendet werden, sehen Sie oft parallel Retries auf Applikationsebene. Zero Window (oder persistente Window-Probleme) zeigt, dass der Empfänger nicht schnell genug liest – das kann Retransmits und Timeouts begünstigen, obwohl das Netzwerk nicht „schuld“ ist.

Linux: Retransmissions über OS-Metriken erkennen

In Linux sind viele TCP-Zähler über Kernel-Statistiken verfügbar. Sie sind häufig die schnellste und neutralste Datenquelle, weil sie direkt dort entstehen, wo TCP implementiert ist.

netstat -s / ss -s: schnelle Indikatoren

Für eine erste Einordnung eignen sich zusammengefasste Statistiken. Typische Hinweise sind:

• Segments retransmitted: direkter Retransmit-Zähler
• Timeouts / retransmits: je nach Ausgabe und Kernel
• Out-of-order / reordering: Hinweise auf Pfad- oder Queueing-Effekte

Für detaillierte Kernel-Metriken und tcp-spezifische Zähler ist die Linux-Dokumentation bzw. Kernel-Referenz hilfreich, z. B. über kernel.org Dokumentation und die TCP-bezogenen Abschnitte im Linux-Kernel-Tree.

/proc/net/snmp und /proc/net/netstat: maschinenlesbare Zähler

Diese Dateien enthalten Metriken, die Exporter einsammeln können. Für Observability ist das ideal: Sie sammeln die Werte periodisch und berechnen daraus Raten und Perzentile über Zeit. Retransmits werden typischerweise als Counter geführt (monoton steigend), aus denen Sie pro Zeitintervall eine Rate bilden.

Prometheus node_exporter: standardisierte Erfassung

Viele Teams nutzen Prometheus als Standard. Der node_exporter sammelt Kernel- und Systemmetriken, die sich für Trendanalysen eignen. Einstieg und Referenz: Prometheus node_exporter. Je nach Exporter-Version und Collector-Konfiguration variieren die konkreten Metriknamen, das Prinzip bleibt jedoch gleich: Counter in Raten umwandeln, mit Latenz/Errors korrelieren und pro Host/Service segmentieren.

Ohne PCAP auf Flow-Ebene: eBPF als Metrik-Quelle

eBPF-basierte Observability kann TCP-Events in hoher Qualität liefern, ohne vollständige Payloads zu erfassen. Das ist häufig ein guter Kompromiss zwischen Datenschutz, Performance und Diagnosefähigkeit. Sie erhalten Metriken pro Prozess, Container, Pod oder Service, und können Retransmits gezielt einem Workload zuordnen.

• Vorteil: Sehr hohe Granularität (z. B. pro Connection/Service) ohne vollständigen Mitschnitt.
• Praxisnutzen: Schnelles Eingrenzen auf „wer verursacht/erlebt Retransmits“.
• Datenschutz: Fokus auf Metadaten und Zähler statt Payload.

Als verbreitete Einstiegspunkte gelten eBPF-Toolsets und Plattformen, etwa BCC (BPF Compiler Collection) oder Observability-Lösungen, die eBPF nutzen. Entscheidend ist, dass Sie Retransmits als Rate und nach Dimensionen (Quelle/Ziel, Pod, Namespace, Service) auswerten.

Service Mesh, Proxy und Load Balancer: Indirekte Retransmission-Signale

Wenn TLS oder HTTP-Termination im Proxy stattfindet (Ingress, Sidecar, API Gateway), sehen Sie dort häufig Symptome, die Retransmissions sehr gut begleiten – auch wenn der Proxy selbst keine „Retransmit“-Metrik ausgibt.

Upstream-Connect-Time, Upstream-Response-Time und Timeouts

• Upstream connect latency steigt: kann auf TCP-Probleme, SYN-Retries oder Verlust hindeuten.
• Upstream timeouts nehmen zu: passt zu RTO-basierten Retransmits oder überlasteten Backends.
• 5xx/502/504 Anstieg: häufig Folge von Verbindungsproblemen oder Überlast.

Bei Envoy, NGINX oder HAProxy sind Metrik- und Logging-Optionen umfangreich. Als technische Anlaufstellen eignen sich z. B. Envoy Dokumentation oder die NGINX Dokumentation. Wichtig ist die Trennung: Ein Proxy kann Applikationsfehler sehen, die nicht aus TCP stammen – deshalb immer mit OS- oder eBPF-Metriken gegenprüfen.

Retries auf HTTP-Ebene sind nicht gleich TCP-Retries

Applikations-Retries (z. B. im Client oder Proxy) können Retransmissions maskieren oder verstärken. Wenn TCP-Retransmissions steigen, sehen Sie häufig auch mehr HTTP-Retries, was wiederum die Last erhöht und die Lage verschärft. Deshalb sollten Sie Retries, Timeouts und Retransmits gemeinsam betrachten.

Interpretation: Wann Retransmissions ein echtes Problem sind

Ein gewisses Maß an Retransmissions ist in realen Netzen normal. Entscheidend ist, ob die Retransmission Rate steigt, ob RTO-Events zunehmen, und ob Nutzer- oder Service-Symptome sichtbar werden.

• Warnsignal: Retransmission Rate steigt parallel zu P95/P99-Latenz und Timeout-Rate.
• Kritisch: RTO/Timeout-Events nehmen zu, Verbindungen brechen ab, Error Budgets werden angegriffen.
• Kontextabhängig: Steigende Retransmits ohne spürbare Latenz-/Error-Auswirkung kann bei starkem Reordering oder kurzzeitigen Netzereignissen auftreten, sollte aber trendbasiert beobachtet werden.

Retransmissions vs. Reordering abgrenzen

Reordering kann Duplicate ACKs erzeugen und sogar Retransmits triggern, obwohl kaum echte Drops vorliegen. Hinweise auf Reordering sind steigende Out-of-Order-Zähler bei moderater Failure Rate und eher „spiky“ statt konstantem Verhalten. Hier helfen Korrelationen mit Pfadänderungen, ECMP-Policies oder Cloud-Networking-Ereignissen.

Typische Ursachen, die Sie ohne PCAP eingrenzen können

Auch ohne Paketdaten lassen sich Ursachen oft erstaunlich weit eingrenzen, wenn Sie systematisch vorgehen und Metriken kombinieren.

Überlast und Queue Drops

• Indikatoren: steigende Interface Drops, steigende Latenz, steigende Retransmits, ggf. Bufferbloat-Symptome
• Prüfen: NIC-Statistiken, Queue-Drops am Router/LB, CPU/IRQ-Last am Host

Fehlerhafte Links oder physische Probleme

• Indikatoren: CRC/Frame Errors, Interface Errors, Retransmits dauerhaft erhöht
• Prüfen: Switchport-Statistiken, Host-NIC-Counter, Fehlerraten pro Link

MTU/PMTUD-Probleme

• Indikatoren: sporadische Timeouts, bestimmte Payloadgrößen betroffen, erhöhte Retransmits bei bestimmten Pfaden
• Prüfen: ICMP „Fragmentation Needed“ (wenn sichtbar), MSS-Clamping, Änderungen an Tunneln/VXLAN

Überlastete Empfänger oder Anwendung als Engpass

• Indikatoren: Zero Window, steigende Latenz bei stabilem Netz, CPU/GC-Pressure, Saturation
• Prüfen: Host-/Container-Ressourcen, Socket-Backlog, Threadpools, I/O-Wartezeiten

Operationalisierung: Dashboards und Alerts, die funktionieren

Damit „TCP-Retransmissions über Metriken erkennen“ nicht nur eine Diagnoseübung bleibt, sollten Sie es als Standard-Observability etablieren. Die Kunst besteht darin, nicht bei jedem kleinen Ausschlag zu alarmieren, sondern signifikante Veränderungen zu erkennen.

Empfohlene Dashboard-Bausteine

• Retransmits Rate: pro Host, pro Service, pro Zone/Region
• RTO/Timeout-Indikatoren: sofern verfügbar, getrennt von Fast Retransmit
• Latenz-Perzentile: P50/P90/P99 auf Service- und Endpunkt-Ebene
• Timeouts/Errors: Applikations- und Proxy-Sicht (HTTP 5xx, gRPC errors)
• Netzwerk-Counter: Drops/Errors auf NIC und relevanten Network-Devices

Alert-Regeln als Kombination statt Einzelwert

Robust sind Alarme, die zwei Bedingungen koppeln: Retransmissions steigen und gleichzeitig verschlechtert sich eine Nutzermetrik (Latenz/Timeout). So reduzieren Sie False Positives, z. B. durch kurzzeitiges Reordering.

• Alarm, wenn Retransmission Rate über Baseline liegt und P99-Latenz steigt
• Alarm, wenn RTO/Timeout steigt und Error Rate (z. B. 5xx) zunimmt
• Warnung, wenn Retransmits steigen, aber (noch) ohne Impact – als Frühindikator

Praxis-Workflow: Retransmissions ohne PCAP systematisch untersuchen

• Schritt 1: Betroffenes Symptom bestätigen (P95/P99, Timeouts, Fehlerquote, Regionen).
• Schritt 2: Retransmission-Metriken auf Host-/Service-Ebene prüfen (Rate, Trend, Peaks).
• Schritt 3: RTO/Timeout-Indikatoren hinzufügen (falls vorhanden) und mit Retransmits korrelieren.
• Schritt 4: Netz-Counter (Drops/Errors/CRC) und Ressourcenauslastung (CPU, IRQ, Queue) gegenprüfen.
• Schritt 5: Segmentieren: Nur ein Service? Nur eine AZ? Nur ein Subnetz? Nur ein Client-Typ?
• Schritt 6: Hypothese ableiten (Überlast, Linkfehler, MTU, Empfänger-Engpass) und gezielt verifizieren.

Weiterführende Ressourcen

• RFC 5681: TCP Congestion Control
• RFC 6298: Computing TCP’s Retransmission Timer
• Prometheus node_exporter
• BCC: eBPF Toolsammlung
• Envoy Dokumentation (Metriken und Observability)
• NGINX Dokumentation (Monitoring und Logging)
• Linux Kernel Dokumentation

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.