Die Kurzantwort:

TCP-Retransmissions sind erneute Übertragungen von TCP-Datenpaketen, wenn der Sender davon ausgeht, dass ein Paket verloren gegangen ist oder nicht rechtzeitig bestätigt wurde. Sie entstehen häufig durch Paketverlust, Überlastung, Microbursts, Queue Drops, fehlerhafte Netzwerkkomponenten, WLAN-Probleme, WAN-Störungen oder zu hohe Verzögerungen. TCP-Retransmissions sind wichtig, weil sie den realen Durchsatz senken, Antwortzeiten erhöhen und Anwendungen spürbar verlangsamen können – selbst wenn ausreichend Bandbreite vorhanden ist.

TCP-Retransmissions zeigen,dass Daten erneut gesendet werden mussten

TCP ist ein zuverlässiges Transportprotokoll. Es sorgt dafür, dass Daten vollständig, in der richtigen Reihenfolge und ohne Lücken beim Empfänger ankommen. Damit das funktioniert, bestätigt der Empfänger dem Sender den Erhalt von Daten.

Wenn ein TCP-Segment nicht bestätigt wird oder der Sender Hinweise darauf bekommt, dass ein Segment fehlt, wird dieses Segment erneut übertragen. Diese erneute Übertragung nennt man TCP-Retransmission.

Aus Sicht der Anwendung ist das zunächst positiv: TCP versucht, verlorene Daten zu reparieren. Ohne Retransmissions würden viele Anwendungen fehlerhafte oder unvollständige Daten erhalten.

Für die Netzwerk-Performance sind TCP-Retransmissions aber ein wichtiges Warnsignal. Sie zeigen, dass Daten nicht beim ersten Versuch sauber angekommen sind. Das kann zu Verzögerungen, niedrigerem Durchsatz und schlechterer Anwendungsperformance führen.

Eine einzelne Retransmission ist nicht automatisch kritisch. Wiederholte oder gehäufte Retransmissions deuten jedoch darauf hin, dass auf der Kommunikationsstrecke etwas nicht stabil läuft.

Was bedeutet TCP-Retransmission?

Eine TCP-Retransmission ist die erneute Übertragung eines bereits gesendeten TCP-Segments.

TCP arbeitet mit Sequenznummern und Bestätigungen. Der Sender verschickt Daten in Segmenten. Der Empfänger bestätigt, welche Daten angekommen sind. Bleibt eine Bestätigung aus oder erkennt der Sender anhand der Rückmeldungen, dass Daten fehlen, wird das betroffene Segment erneut gesendet.

Vereinfacht gesagt:

  1. Ein Sender schickt Daten an einen Empfänger.
  2. Der Empfänger bestätigt empfangene Daten.
  3. Eine Bestätigung fehlt oder zeigt eine Lücke.
  4. Der Sender geht von Verlust oder Störung aus.
  5. Das betroffene Segment wird erneut übertragen.

Diese erneute Übertragung sorgt dafür, dass die Kommunikation zuverlässig bleibt. Sie verursacht aber zusätzlichen Verkehr und kostet Zeit.

Warum gibt es TCP-Retransmissions?

TCP-Retransmissions entstehen, weil TCP Zuverlässigkeit herstellen muss. Das Netzwerk selbst garantiert nicht, dass jedes Paket immer ankommt. Pakete können verloren gehen, verzögert werden oder in anderer Reihenfolge eintreffen. Typische Gründe für Retransmissions sind:

  • Paketverlust
  • überlastete Links
  • Microbursts
  • Queue Drops
  • Interface Drops
  • volle Puffer
  • fehlerhafte Kabel oder Transceiver
  • CRC-Fehler
  • WLAN-Störungen
  • VPN- oder WAN-Probleme
  • Firewall- oder Security-Inspection-Verzögerungen
  • Paketverwerfung durch QoS- oder Policy-Regeln
  • asymmetrisches Routing
  • Paket-Reordering
  • Providerprobleme
  • Cloud- oder Internetpfadprobleme
  • überlastete Server oder Clients

Wichtig ist: TCP-Retransmissions sind nicht die Ursache selbst, sondern ein Symptom. Sie zeigen, dass TCP Daten erneut übertragen musste. Die eigentliche Ursache muss über weitere Messwerte eingegrenzt werden.

Wie erkennt TCP, dass Daten erneut übertragen werden müssen?

TCP kann auf unterschiedliche Weise erkennen, dass Daten möglicherweise verloren gegangen sind.

Retransmission Timeout

Wenn der Sender für ein gesendetes Segment innerhalb einer bestimmten Zeit keine passende Bestätigung erhält, läuft ein Retransmission Timer ab. Dann sendet TCP das betroffene Segment erneut.

Das nennt man Retransmission Timeout.

Dieser Mechanismus ist wichtig, wenn keine oder zu wenige Rückmeldungen beim Sender ankommen. Er kann aber zu deutlichen Verzögerungen führen, weil TCP zunächst wartet, bevor erneut gesendet wird.

Duplicate ACKs und Fast Retransmit

TCP kann auch durch wiederholte Bestätigungen erkennen, dass ein Segment fehlt. Wenn der Empfänger Daten außerhalb der erwarteten Reihenfolge erhält, bestätigt er weiterhin den zuletzt vollständig empfangenen Datenstand. Aus Sicht des Senders entstehen dadurch Duplicate ACKs.

Erhält der Sender mehrere Duplicate ACKs, kann er annehmen, dass ein Segment verloren gegangen ist, und es schneller erneut senden. Dieser Mechanismus wird Fast Retransmit genannt.

Fast Retransmit ist schneller als ein Timeout, weil TCP nicht erst auf das Ablaufen des Retransmission Timers warten muss.

Warum sind TCP-Retransmissions problematisch?

TCP-Retransmissions sind problematisch, weil sie Zeit und Bandbreite kosten. Daten, die eigentlich bereits übertragen wurden, müssen erneut gesendet werden. Gleichzeitig wartet die Anwendung häufig auf vollständige Daten oder Bestätigungen.

Besonders kritisch sind Retransmissions auf WAN-, VPN- und Cloud-Strecken. Dort sind RTT und Latenz oft höher als im lokalen Netzwerk. Wenn Pakete erneut übertragen werden müssen, verlängert sich die Wartezeit entsprechend stärker.

Die Folgen können sein:

  • niedrigerer Durchsatz
  • längere Antwortzeiten
  • verzögerte Dateiübertragungen
  • langsamere Datenbankzugriffe
  • stockende Cloud-Anwendungen
  • längere Ladezeiten
  • instabile VPN-Verbindungen
  • schlechtere Sprach- oder Kommunikationsqualität
  • Timeouts in Anwendungen
  • erhöhte Server- oder Client-Wartezeiten
  • ungleichmäßige Performance

Zusammenhang mit den anderen Kennzahlen

Paketverlust

Paketverlust ist eine der häufigsten Ursachen für TCP-Retransmissions. Wenn ein TCP-Segment auf dem Weg zum Empfänger verloren geht, kann der Empfänger es nicht bestätigen. TCP muss das Segment erneut übertragen.

Der Zusammenhang ist direkt: Paketverlust führt häufig zu TCP-Retransmissions. TCP-Retransmissions reduzieren häufig den effektiven Durchsatz.

Dabei ist nicht nur die Höhe des Paketverlusts wichtig, sondern auch das Muster. Ein gleichmäßiger Paketverlust von 0,1 Prozent kann anders wirken als kurze Phasen mit gebündeltem Paketverlust. Gerade Microbursts oder Queue Drops können innerhalb weniger Sekunden mehrere Pakete verwerfen. Das führt zu gehäuften Retransmissions und spürbaren Performance-Einbrüchen.

Im Tagesdurchschnitt kann der Paketverlust unauffällig wirken. Für eine konkrete Anwendung kann der kurze Verlustmoment trotzdem entscheidend sein.

Durchsatz

TCP-Retransmissions wirken sich direkt auf den Durchsatz aus. Der reale Durchsatz beschreibt die tatsächlich erfolgreich übertragene Datenmenge. Wenn Daten erneut übertragen werden müssen, sinkt die nutzbare Übertragungsleistung.

Eine Verbindung kann zum Beispiel 1 Gbit/s Bandbreite haben. Wenn aber regelmäßig Pakete verloren gehen und erneut übertragen werden müssen, erreicht die Anwendung vielleicht nur 200 oder 300 Mbit/s realen Durchsatz.

Das liegt nicht zwingend daran, dass zu wenig Bandbreite vorhanden ist. Das Problem entsteht, weil TCP Daten erneut senden und die Übertragungsgeschwindigkeit anpassen muss.

Besonders bei großen Dateiübertragungen, Backups, Replikationen, Cloud-Migrationen, Storage-Zugriffen oder Datenbankverbindungen können Retransmissions den Durchsatz erheblich reduzieren.

RTT

RTT, also Round Trip Time, beschreibt die Zeit für Hin- und Rückweg einer Kommunikation. TCP ist stark von Rückmeldungen abhängig. Wenn Daten gesendet werden, wartet TCP auf Bestätigungen des Empfängers.

Je höher die RTT ist, desto stärker können sich Retransmissions auswirken.

Bei niedriger RTT kann ein verlorenes Segment vergleichsweise schnell erneut übertragen und bestätigt werden. Bei hoher RTT dauert dieser Vorgang länger. Auf WAN-, VPN- oder Cloud-Strecken kann das besonders spürbar werden.

Ein Beispiel: Bei einer RTT von 5 Millisekunden fällt eine einzelne Retransmission weniger stark auf als bei einer RTT von 120 Millisekunden. Je länger der Weg und je höher die Verzögerung, desto stärker beeinflussen Verluste und erneute Übertragungen die Gesamtperformance.

Deshalb sollten TCP-Retransmissions immer gemeinsam mit RTT, One-Way Delay, Jitter und Paketverlust betrachtet werden.

Microbursts

Microbursts sind sehr kurze Lastspitzen, bei denen innerhalb eines kleinen Zeitfensters mehr Daten übertragen werden sollen, als eine Verbindung oder Netzwerkkomponente verarbeiten kann.

Während eines Microbursts können Warteschlangen entstehen. Wenn Puffer oder Queues voll sind, werden Pakete verworfen. Diese verworfenen Pakete führen bei TCP häufig zu Retransmissions.

Das ist besonders tückisch, weil Microbursts in klassischen Durchschnittswerten oft verborgen bleiben.

Eine WAN-Strecke kann im Fünf-Minuten-Durchschnitt nur zu 35 Prozent ausgelastet sein. Trotzdem können innerhalb dieses Zeitfensters kurze Spitzen auftreten, in denen Queues überlaufen und Pakete verloren gehen. Die Folge sind TCP-Retransmissions und sinkender Durchsatz.

Für die Anwendung wirkt die Verbindung langsam oder instabil. Im klassischen Monitoring sieht die durchschnittliche Auslastung jedoch unkritisch aus.

Interface Drops

Interface Drops oder Queue Drops entstehen, wenn Netzwerkkomponenten Pakete verwerfen. Das kann passieren, wenn Puffer voll sind, Warteschlangen überlaufen oder eine Komponente Verkehr nicht schnell genug weiterleiten kann.

Solche Drops sind eine direkte technische Ursache für Paketverlust. Bei TCP-Verbindungen führen sie häufig zu Retransmissions.

Wichtig ist die Unterscheidung: Drops zeigen, dass Pakete an einer Komponente verworfen wurden. Paketverlust zeigt, dass Pakete nicht beim Ziel angekommen sind. TCP-Retransmissions zeigen, dass TCP Daten erneut übertragen musste.

Diese drei Ebenen hängen eng zusammen, beschreiben aber unterschiedliche Perspektiven. Für eine belastbare Analyse sollten sie gemeinsam betrachtet werden.

Warum mehr Bandbreite nicht immer hilft

Wenn Anwendungen langsam sind, wird häufig mehr Bandbreite als Lösung diskutiert. Bei TCP-Retransmissions ist das nicht immer der richtige Ansatz.

Mehr Bandbreite kann helfen, wenn die Ursache tatsächlich eine dauerhaft überlastete Verbindung ist. Wenn Retransmissions jedoch durch Paketverlust, Drops, fehlerhafte Komponenten, WLAN-Störungen, Security Inspection oder ungünstige Routingpfade entstehen, löst zusätzliche Bandbreite das Problem oft nicht vollständig.

Beispiele:

  • Eine Firewall verwirft Pakete unter Last.
  • Ein VPN-Gateway ist überlastet.
  • Ein Switch-Port zeigt Drops.
  • Eine WLAN-Verbindung verursacht Paketverluste.
  • Ein Providerpfad verliert Pakete sporadisch.
  • Eine Cloud-Strecke zeigt zeitweise hohe Latenz und Paketverlust.
  • Microbursts verursachen kurze Queue-Überläufe.

In diesen Fällen muss zuerst die Ursache der Retransmissions gefunden werden. Erst danach lässt sich bewerten, ob mehr Bandbreite sinnvoll ist.

Warum TCP-Retransmissions Anwendungen spürbar verlangsamen

Viele Anwendungen reagieren empfindlich auf Verzögerungen durch Retransmissions. Besonders betroffen sind Anwendungen, die viele Daten zuverlässig übertragen oder viele voneinander abhängige Transaktionen ausführen.

Bei Dateiübertragungen führen Retransmissions zu längeren Übertragungszeiten. Bei interaktiven Anwendungen können sie Antwortzeiten verschlechtern. Bei transaktionsorientierten Systemen können sie ganze Prozessketten verlangsamen.

Typische Beispiele sind:

  • zentrale Fachanwendungen
  • Datenbankanwendungen
  • ERP-Systeme
  • Dateiübertragungen
  • Backup- und Replikationsprozesse
  • Storage-Zugriffe
  • Cloud- und SaaS-Anwendungen
  • Remote-Desktop- und Terminalserver-Sitzungen
  • Softwareverteilung
  • Finanz- und Versicherungssysteme
  • Produktions- und Steuerungssysteme
  • medizinische Bilddatenübertragung
  • Partner- und Kundenschnittstellen

TCP-Retransmissions bei Cloud-, WAN- und VPN-Strecken

Cloud-, WAN- und VPN-Strecken sind besonders anfällig für sichtbare Auswirkungen von TCP-Retransmissions. Der Grund ist, dass diese Strecken häufig höhere Laufzeiten und mehr beteiligte Komponenten haben.

Auf dem Weg zwischen Standort und Cloud-Dienst können viele Elemente beteiligt sein: lokales LAN, Firewall, Proxy, VPN-Gateway, Internetprovider, Carrier-Netz, Cloud-Gateway, Load Balancer, Zielsystem und der Rückweg über andere Pfade.

Wenn auf einer dieser Teilstrecken Pakete verloren gehen oder stark verzögert werden, kann TCP mit Retransmissions reagieren. Für die Anwendung ist nicht immer erkennbar, wo das Problem entsteht. Sie wirkt einfach langsam oder instabil.

Deshalb ist eine Ende-zu-Ende-Betrachtung wichtig. Sie hilft, die tatsächliche Kommunikationsstrecke aus Sicht der Anwendung zu bewerten.

TCP-Retransmissions und Sprachqualität

Auch wenn Sprache häufig über UDP übertragen wird, können TCP-Retransmissions indirekt für Kommunikationsqualität relevant sein. Viele Unified-Communications-Plattformen, Signalisierungssysteme, Steuerkanäle, Webkomponenten oder Cloud-Dienste nutzen TCP oder TLS-basierte Verbindungen.

Retransmissions können dazu führen, dass Steuerinformationen verzögert werden, Sitzungen langsamer aufgebaut werden oder Cloud-Anwendungen träge reagieren. Im Umfeld von VoIP, Teams, Contact-Centern oder Cloud-Telefonie sollten TCP-Retransmissions deshalb nicht isoliert, aber im Zusammenhang mit MOS-Wert, Jitter, Paketverlust und One-Way Delay betrachtet werden.

Für die reine Sprachübertragung sind oft Paketverlust, Jitter und One-Way Delay entscheidender. Für die gesamte Kommunikationsplattform können TCP-Retransmissions dennoch ein wichtiger Hinweis auf Netzwerkprobleme sein.

Wie misst man TCP-Retransmissions?

TCP-Retransmissions lassen sich auf verschiedenen Ebenen messen und analysieren.

Paketmitschnitt

Ein Paketmitschnitt ist eine sehr genaue Methode, um TCP-Retransmissions sichtbar zu machen. Tools zur Protokollanalyse können erkennen, ob TCP-Segmente erneut übertragen wurden.

Der Vorteil ist die hohe Detailtiefe. Der Nachteil ist, dass Paketmitschnitte meist punktuell erfolgen und gezielt platziert werden müssen.

Netzwerk-Monitoring

Einige Monitoring-Systeme können Retransmissions aus Traffic-Analysen oder Flow-Daten ableiten. Je nach Datenquelle ist die Genauigkeit unterschiedlich.

Endsysteme

Server, Clients oder Betriebssysteme können TCP-Statistiken liefern. Diese zeigen, ob ein System Retransmissions beobachtet. Allerdings ist dann noch nicht klar, auf welcher Teilstrecke das Problem entsteht.

Ende-zu-Ende-Messung

Eine kontinuierliche Ende-zu-Ende-Messung kann helfen, Retransmissions mit anderen Kennzahlen in Verbindung zu bringen. Besonders wichtig ist der zeitliche Zusammenhang mit Paketverlust, RTT, One-Way Delay, Jitter, Durchsatz, Microbursts oder Drops.

Warum punktuelle Messungen oft nicht ausreichen

TCP-Retransmissions treten häufig sporadisch auf. Sie können nur zu bestimmten Zeiten, unter Last oder bei bestimmten Anwendungen entstehen.

Ein Paketmitschnitt nach einer Störungsmeldung kann unauffällig sein, wenn das Problem bereits vorbei ist. Ein einzelner Speedtest kann gut aussehen, obwohl die Anwendung regelmäßig durch kurze Paketverluste ausgebremst wird. Ein Durchschnittswert kann unkritisch wirken, obwohl es in kurzen Zeitfenstern zu starken Retransmissions kommt.

Deshalb ist der zeitliche Verlauf entscheidend. Wichtige Fragen sind: Wann treten Retransmissions auf? Wie häufig treten sie auf? Welche Anwendungen oder Strecken sind betroffen? Gibt es zeitliche Muster? Fallen sie mit Backups, Replikationen oder Synchronisationen zusammen? Treten gleichzeitig Paketverlust, Jitter oder RTT-Spitzen auf? Gibt es Interface Drops oder Queue Drops? Sind bestimmte Standorte, VPNs oder Cloud-Zugänge betroffen?

Ohne historische Daten bleiben viele dieser Fragen unbeantwortet.

Welche Werte sind bei TCP-Retransmissions akzeptabel?

Es gibt keinen universellen Grenzwert, der für alle Netzwerke gilt. Einzelne Retransmissions können in realen Netzwerken vorkommen und sind nicht automatisch kritisch.

Für geschäftskritische Anwendungen sollte bereits eine geringe, aber wiederkehrende Retransmission-Rate ernst genommen werden, wenn sie mit Performance-Problemen zusammenfällt.

Besonders kritisch sind gebündelte Retransmissions während kurzer Zeitfenster. Sie können auf Microbursts, Drops oder Überlastung hinweisen.

Entscheidend sind:

  • Häufigkeit
  • zeitliche Konzentration
  • betroffene Anwendung
  • betroffene Strecke
  • gleichzeitiger Paketverlust
  • Einfluss auf Durchsatz
  • Einfluss auf Antwortzeiten
  • Vergleich zur normalen Baseline
  • wiederkehrende Muster
  • Auswirkungen auf Geschäftsprozesse
Praxisbeispiel

Langsame Fachanwendung trotz unauffälliger Bandbreite

Ein Unternehmen betreibt eine zentrale Fachanwendung im Rechenzentrum. Mehrere Standorte greifen über WAN- und VPN-Strecken darauf zu. Die Anwender melden, dass Maskenwechsel und Datenabrufe zu bestimmten Tageszeiten deutlich langsamer werden.

Die Bandbreitenauslastung der WAN-Strecken wirkt im Durchschnitt unkritisch. Auch einzelne Ping-Tests zeigen keine dauerhafte Auffälligkeit.

Eine genauere Analyse zeigt jedoch, dass während bestimmter Zeitfenster Paketverlust und TCP-Retransmissions auftreten. Gleichzeitig steigt die RTT kurzzeitig an, und der reale Durchsatz sinkt deutlich. Die Ereignisse fallen mit parallelen Dateiübertragungen und Synchronisationsprozessen zusammen.

Die Ursache liegt nicht in dauerhaft fehlender Bandbreite, sondern in kurzfristigen Lastspitzen und Queue Drops. TCP muss verlorene Segmente erneut übertragen. Dadurch verlängern sich Antwortzeiten, und die Anwendung wirkt langsam.

Nach einer Anpassung der Priorisierung, einer zeitlichen Entzerrung großer Datenübertragungen und einer Prüfung der betroffenen Netzwerkkomponenten gehen die Retransmissions zurück. Die Anwendung reagiert wieder stabiler.

Das Beispiel zeigt: TCP-Retransmissions sind oft der technische Hinweis darauf, warum eine Verbindung trotz ausreichender Bandbreite nicht die erwartete Performance liefert.

Best Practicesim Umgang mit TCP-Retransmissions

Besonders wichtig ist, Retransmissions nicht vorschnell mit „zu wenig Bandbreite“ zu erklären. Sie sind ein Hinweis auf eine gestörte oder instabile Übertragung und müssen im Zusammenhang mit der gesamten Kommunikationsstrecke bewertet werden.

Für eine sinnvolle Bewertung von TCP-Retransmissions haben sich folgende Maßnahmen bewährt:

  • Retransmissions nicht isoliert betrachten
  • Paketverlust, RTT, One-Way Delay, Jitter und Durchsatz gemeinsam analysieren
  • zeitliche Muster und Ausreißer prüfen
  • Durchschnittswerte kritisch hinterfragen
  • betroffene Anwendungen und Kommunikationsstrecken identifizieren
  • Interface Drops und Queue Drops prüfen
  • Microbursts als mögliche Ursache berücksichtigen
  • WAN-, VPN-, Cloud- und Firewall-Strecken getrennt betrachten
  • Paketmitschnitte gezielt einsetzen
  • historische Messdaten speichern
  • Baselines für normalen Betrieb definieren
  • Änderungen an Firewalls, Providern, VPNs oder Cloud-Zugängen überwachen
  • große Datenübertragungen und Backups zeitlich analysieren
  • QoS- und Priorisierungsregeln prüfen
  • Endsysteme, Server und Clients einbeziehen

Zusammengefasst

TCP-Retransmissions sind erneute Übertragungen von TCP-Segmenten. Sie entstehen, wenn TCP davon ausgeht, dass Daten verloren gegangen sind oder nicht rechtzeitig bestätigt wurden.

Sie sind ein normaler Bestandteil der TCP-Zuverlässigkeit, aber gleichzeitig ein wichtiges Warnsignal für Netzwerk-Performance-Probleme. Häufige oder gebündelte Retransmissions können auf Paketverlust, Microbursts, Queue Drops, Überlastung, WLAN-Probleme, WAN-Störungen oder fehlerhafte Komponenten hinweisen.

Für Anwendungen können TCP-Retransmissions erhebliche Auswirkungen haben. Sie senken den realen Durchsatz, erhöhen Antwortzeiten und können zentrale Anwendungen, Cloud-Dienste, Datenbankzugriffe, Dateiübertragungen oder VPN-Verbindungen spürbar verlangsamen.

Eine belastbare Analyse betrachtet TCP-Retransmissions deshalb nie isoliert. Entscheidend ist der Zusammenhang mit Paketverlust, RTT, One-Way Delay, Jitter, Durchsatz, Interface Drops und zeitlichen Lastmustern. Eine kontinuierliche Ende-zu-Ende-Messung hilft, diese Zusammenhänge sichtbar und technisch nachvollziehbar zu machen.

Häufig gestellte Fragen zu TCP-Retransmissions

TCP-Retransmissions sind erneute Übertragungen von Datenpaketen, wenn TCP davon ausgeht, dass ein Paket verloren gegangen ist oder nicht rechtzeitig bestätigt wurde.

Einzelne Retransmissions sind nicht ungewöhnlich. Häufige oder gebündelte Retransmissions können jedoch auf Paketverlust, Überlastung oder andere Netzwerkprobleme hinweisen.

Weil Daten erneut übertragen werden müssen und TCP seine Übertragungsgeschwindigkeit anpassen kann. Dadurch sinkt die tatsächlich nutzbare Datenrate.

Wenn Pakete verloren gehen, muss TCP die fehlenden Daten erneut übertragen. Paketverlust ist daher eine häufige Ursache für Retransmissions.

Nicht immer. Wenn Retransmissions durch Drops, fehlerhafte Komponenten, WLAN-Probleme, VPN-Gateways, Firewalls oder Providerpfade entstehen, muss die eigentliche Ursache behoben werden.

Sie lassen sich durch Paketmitschnitte, TCP-Statistiken, Traffic-Analysen oder kontinuierliche Ende-zu-Ende-Messungen in Verbindung mit Paketverlust, RTT und Durchsatz erkennen.

Tipp von NETCOR

Bewerten Sie TCP-Retransmissions immer als Hinweis auf eine gestörte Übertragung – nicht als isolierten Einzelwert. Entscheidend ist, wann und auf welcher Kommunikationsstrecke Retransmissions auftreten und ob sie mit Paketverlust, RTT-Spitzen, Microbursts, Queue Drops oder sinkendem Durchsatz zusammenfallen. Eine kontinuierliche 24/7-Ende-zu-Ende-Messung macht diese Zusammenhänge sichtbar und hilft zu erkennen, ob Anwendungen durch echte Netzwerkereignisse ausgebremst werden.

Live erleben

GeNiEnd2End Kennenlernen

Retransmissions sichtbar machen, statt Symptome zu raten: In unserer Live-Demo zeigen wir Ihnen, wie GeNiEnd2End TCP-Retransmissions, Paketverlust und Durchsatzeinbrüche auf Ihren Kommunikationsstrecken kontinuierlich erfasst und nachvollziehbar macht.

Demo buchen

Weitere Grundlagen-Artikel

Was ist Paketverlust?

Bedeutung, Ursachen und Messung von Paketverlust – warum schon geringe Verluste stören können.

Zum Artikel

Interface Drops und Queue Drops

Warum Netzwerkkomponenten Pakete verwerfen – und wie Drops die Performance beeinflussen.

Zum Artikel

Was ist Durchsatz?

Bedeutung, Ursachen und Messung von Durchsatz – was im Netzwerk wirklich ankommt.

Zum Artikel