TCP-Retransmission als Ursache für Kommunikationsausfälle bei Industriekameras – Ursachensuche und Eingrenzung

Bei der Kommunikation mit Industriekameras und in der Gerätesteuerung ist das lästigste Phänomen eine Verbindung, die im Durchschnitt schnell ist, aber gelegentlich für mehrere Sekunden stoppt. Die Reproduktionsrate ist gering, und im Normalbetrieb passiert nichts Auffälliges – deshalb wirken nach und nach UI, Threads, GC, Kamera-SDK, NIC und Switch alle ein wenig verdächtig.

Dieser Artikel behandelt einen Fall, bei dem die TCP-Kommunikation zwischen einer Anwendung, die eine Industriekamera steuert, und dem Host gelegentlich für einige Sekunden stoppte. Bei der Untersuchung stellte sich heraus, dass die Ursache nicht ein Anwendungsstillstand war, sondern ein durch Paketverlust verursachtes Warten von TCP auf eine Neuübertragung. Darüber hinaus ließ sich die Wartezeit in diesem System durch Aktivieren der Timestamps-Funktion aus der RFC1323-Familie (nach heutiger Einordnung RFC 7323) auf ein Minimum reduzieren.

Gerätenamen, Konfiguration und Zahlenwerte wurden verallgemeinert, aber die Denkweise lässt sich unverändert in der Praxis anwenden.

Inhaltsverzeichnis

1. Zuerst das Fazit (in Kürze)
2. Wie sich das Symptom zeigt
   • 2.1. Die Anwendung lebt, aber allein die Antworten stoppen für Sekunden
   • 2.2. Bei geringer Häufigkeit ist es allein anhand der Logs schwer zu erkennen
3. Was tatsächlich passierte (Diagramm)
   • 3.1. Vom Paketverlust zum Warten auf die Neuübertragung
   • 3.2. Der sekundenweise Stillstand passte zur Form des RTO
4. Beobachtungen aus der Untersuchung
   • 4.1. Zunächst Stillstandsursachen innerhalb der Anwendung ausschließen
   • 4.2. Neuübertragungen per Paketaufzeichnung bestätigen
   • 4.3. Die ausgehandelten TCP-Optionen betrachten
5. Warum RFC1323-Zeitstempel helfen
   • 5.1. Zeitstempel dienen RTTM und PAWS
   • 5.2. Sie beseitigen die Mehrdeutigkeit der RTT-Messung bei Neuübertragung
   • 5.3. Warum sich in diesem Fall die Wartezeit verkürzen ließ
6. Die tatsächlich ergriffenen Maßnahmen
   • 6.1. Zeitstempel aktivieren
   • 6.2. TSopt in SYN / SYN-ACK prüfen
   • 6.3. Wo nachzusehen ist, wenn es trotzdem nicht hilft
7. Worauf in Wireshark zu achten ist
8. Grobe Entscheidungshilfe
9. Zusammenfassung
10. Referenzen

1. Zuerst das Fazit (in Kürze)

• TCP-Kommunikation, die gelegentlich für einige Sekunden stoppt, kann statt eines Anwendungsstillstands in Wirklichkeit ein Warten auf die Neuübertragung nach Paketverlust sein
• Zeigt die Paketaufzeichnung Retransmission mit einer großen Zeitlücke, und passt die Stillstandsdauer zum Wartemuster des RTO, ist das ziemlich verdächtig
• Die TCP-Timestamps-Option ist ein Mechanismus für die RTT-Messung und PAWS und beseitigt zudem die Mehrdeutigkeit der RTT-Messung bei einer Neuübertragung
• In diesem Fall ließ sich durch Aktivieren der Timestamps-Funktion aus der RFC1323-Familie die Zeit verringern, in der die RTO-Schätzung veraltet und konservativ blieb, wodurch sich der sekundenweise Stillstand auf ein Minimum reduzieren ließ
• Allerdings ist das keine Zauberei, die den Verlust selbst beseitigt. Eine Überprüfung der physischen Schicht, des NIC, der Switches, der Zwischengeräte, der Treiber und des Pufferdesigns bleibt separat nötig

Kurz gesagt: Wenn die wahre Ursache von „stoppt gelegentlich für ein paar Sekunden“ eine Wartezeit innerhalb von TCP ist, geht man mit reinem Einsatz für Anwendungs-Retries am Kern vorbei. Es ist schneller, zuerst auf die Leitung zu schauen und festzustellen, ob es sich um ein Warten auf eine Neuübertragung handelt.

Im Folgenden tauchen fortlaufend TCP-Abkürzungen auf. Für Windows-Entwickler, die keine Netzwerkspezialisten sind, ist hier vorab eine Zusammenfassung. Wenn Sie nur diese im Kopf behalten, sollten Sie danach nicht ins Stocken geraten.

2. Wie sich das Symptom zeigt

2.1. Die Anwendung lebt, aber allein die Antworten stoppen für Sekunden

Zunächst verwirrend ist, dass die Anwendung insgesamt nicht eingefroren wirkt.

• Die UI ist nicht vollständig tot
• Der Prozess ist auch nicht abgestürzt
• Auch die CPU ist nicht ausgelastet
• Allerdings fehlt gelegentlich allein die Antwort auf Kamera-Steuerbefehle für einige Sekunden

Solche Symptome lassen sich nur schwer von einem Deadlock oder einer Endlosschleife innerhalb der Anwendung unterscheiden. Zudem entsteht bei der Gerätesteuerung durch einen einzigen mehrsekündigen Stillstand direkt der Eindruck eines Linienstopps. Auch wenn die Durchschnittswerte sauber aussehen, ist das Empfinden vor Ort deutlich schlechter.

2.2. Bei geringer Häufigkeit ist es allein anhand der Logs schwer zu erkennen

Was diese Art von Fehler mühsam macht, ist die geringe Auftretenshäufigkeit. Das Verhalten ähnelt „einmal pro Stunde“, „einmal pro halbem Tag“ oder „nur wenn mehrere Bedingungen zusammentreffen“.

Verfolgt man das allein über Logs, sieht es meist so aus.

• Im Anwendungslog bleibt es bei „gesendet“ und „keine Antwort erhalten“ stehen
• Im Log der Empfangsseite sieht es aus, als sei „nichts angekommen“
• Zufällig tritt im selben Zeitraum auch noch ein anderes Ereignis auf, wodurch sich die Verdächtigen verteilen

Versucht man in einer solchen Situation, die Kausalität allein aus den Anwendungslogs zu rekonstruieren, verstrickt man sich ziemlich zuverlässig. Es ist schneller, eine Ebene tiefer zur Kommunikationsschicht hinabzusteigen.

3. Was tatsächlich passierte (Diagramm)

3.1. Vom Paketverlust zum Warten auf die Neuübertragung

Der Ablauf in diesem Fall ist einfach. Irgendwo unterwegs ging ein Paket verloren, die Sendeseite wartete auf das ACK, und da keines kam, wurde der RTO abgewartet, bevor erneut gesendet wurde.

sequenceDiagram
    participant Host as Hostanwendung
    participant Net as Netzwerk
    participant Cam as Kameraseite

    Host->>Net: Steuerbefehl (Seq=N)
    Note over Net: Hier verloren
    Note over Host: Kein ACK, also wird gewartet
    Note over Host: Die Erholung dieser Anfrage erfordert das Warten auf den RTO
    Host->>Net: Steuerbefehl erneut gesendet
    Net->>Cam: Erneut gesendetes Paket kommt an
    Cam-->>Net: ACK
    Net-->>Host: ACK
    Note over Host: Hier setzt die Kommunikation wieder ein

Aus Sicht der Anwendung sieht das aus wie „für einige Sekunden gestoppt“, aber aus TCP-Sicht ist es lediglich „noch kein ACK erhalten, also wurde auf den Ablauf des Retransmission-Timers gewartet“. Unspektakulär, aber dieses Stillstands-Muster kommt ganz normal vor.

Die Steuerkommunikation in diesem Fall bestand überwiegend aus kleinen Request/Response-Vorgängen, und bei einem einzelnen Austausch war keine große Menge unbestätigter Daten unterwegs. Deshalb handelte es sich um eine Konfiguration, bei der das Warten auf den RTO eher zutage tritt, bevor genug Duplicate ACKs für ein Fast Retransmit zusammenkommen.

3.2. Der sekundenweise Stillstand passte zur Form des RTO

Das Warten von TCP auf eine Neuübertragung erfolgt zwar je nach Implementierung unterschiedlich, aber grundsätzlich konservativ. Nach RFC 6298 liegt der Basiswert des initialen RTO bei 1 Sekunde; ist der berechnete Wert kleiner, wird er auf 1 Sekunde aufgerundet, und bei einem Timeout verdoppelt er sich.

flowchart LR
    A[Paketverlust] --> B[Kein ACK]
    B --> C[RTO-Wartezeit]
    C --> D[Neuübertragung]
    D --> E{ACK kommt zurück?}
    E -- Ja --> F[Kommunikation setzt wieder ein]
    E -- Nein --> G[RTO verdoppeln]
    G --> C

Deshalb kann es selbst in Situationen, in denen man sich ein Ende innerhalb weniger hundert Millisekunden wünscht, unter schlechten Bedingungen zu Wartezeiten von 1, 2 oder 4 Sekunden kommen. Das „gelegentliche mehrsekündige Stoppen“ in diesem Fall passte ziemlich direkt zu diesem Muster.

4. Beobachtungen aus der Untersuchung

4.1. Zunächst Stillstandsursachen innerhalb der Anwendung ausschließen

Statt sofort auf TCP zu tippen, wurden zunächst die typischen Ursachen auf Anwendungsseite ausgeschlossen.

Wichtig ist hier, den Verursacher nicht allein anhand der Zeitstempel im Anwendungslog festzulegen. Bei Gerätesteuerungsanwendungen spiegelt ein Warten auf höherer Ebene manchmal nur ein Warten auf einer tieferen Ebene wider.

4.2. Neuübertragungen per Paketaufzeichnung bestätigen

Bei einer Paketaufzeichnung zeigte sich im Zeitraum des Stillstands TCP Retransmission, und zudem stellte sich heraus, dass unmittelbar davor kein ACK zurückgekommen war.

Folgende Punkte sind dabei zu prüfen.

• Wird dieselbe Seq erneut gesendet?
• Stimmt der Zeitabstand bis zur Neuübertragung mit der Stillstandsdauer überein?
• Sieht es eher nach einem Warten auf den Ablauf des RTO aus als nach Dup ACK oder Fast Retransmission?
• Erscheint die betroffene Verbindung jedes Mal im selben tcp.stream?

Passt das zusammen, wird die Erklärung „TCP wartet auf eine Neuübertragung“ deutlich wahrscheinlicher als „die Anwendung steht still“.

4.3. Die ausgehandelten TCP-Optionen betrachten

Als Nächstes wurden SYN / SYN-ACK beim Verbindungsaufbau betrachtet. Zeitstempel werden im 3-Way-Handshake der TCP-Verbindung ausgehandelt; erscheint hier kein TSopt, wird es auf dieser Verbindung nicht verwendet.

sequenceDiagram
    participant Host as Host
    participant Cam as Kameraseite

    Host->>Cam: SYN + TSopt ?
    Cam-->>Host: SYN/ACK + TSopt ?
    Host->>Cam: ACK
    Note over Host,Cam: Erst wenn dies hier ausgehandelt wurde, kann TSopt in den folgenden Segmenten verwendet werden

Ändert man nur die OS-Einstellungen, ohne dies zu prüfen, entsteht der ebenso unspektakuläre Fehler „eigentlich müsste es aktiviert sein, aber es wirkt nicht“. Die Tatsache auf der Leitung zählt mehr als der Konfigurationswert.

5. Warum RFC1323-Zeitstempel helfen

In der Praxis hält sich noch die Bezeichnung „RFC1323-Zeitstempel“, auch wenn die aktuelle Einordnung RFC 7323 lautet. Dieser Artikel schreibt der gängigen Praxis folgend RFC1323, meint damit inhaltlich aber die TCP-Timestamps-Option.

5.1. Zeitstempel dienen RTTM und PAWS

Die Timestamps-Option von TCP wird hauptsächlich für zwei Zwecke verwendet.

• RTTM (Round-Trip Time Measurement)
• PAWS (Protect Against Wrapped Sequences)

In diesem Fall war es die RTTM-Seite, die half. Indem die Gegenseite den TSval eines gesendeten Segments im TSecr des ACK zurückgibt, kann die Sendeseite die RTT feiner und genauer messen.

5.2. Sie beseitigen die Mehrdeutigkeit der RTT-Messung bei Neuübertragung

Kommt es zu einer Neuübertragung, wird ohne Zeitstempel unklar, „ob dieses ACK für die ursprüngliche Sendung oder für die Neuübertragung gilt“. Genau das ist der Punkt, den Karns Algorithmus im Blick hat.

RFC 6298 legt fest, dass aus erneut gesendeten Segmenten keine RTT-Stichprobe genommen werden darf. Der Grund: Es lässt sich nicht feststellen, für welche Sendung das ACK gilt. Mit der Timestamps-Option lässt sich diese Mehrdeutigkeit jedoch beseitigen, da sich anhand des im ACK enthaltenen TSecr erkennen lässt, welches Segment mit welchem TSval angekommen ist.

sequenceDiagram
    participant Host as Sendeseite
    participant Cam as Empfangsseite

    Host->>Cam: Seq=N, TSval=1000
    Note over Host,Cam: Dieses Segment geht verloren
    Note over Host: Kein ACK, also wird gewartet
    Host->>Cam: Erneut gesendet: Seq=N, TSval=2000
    Cam-->>Host: ACK, TSecr=2000
    Note over Host: Lässt sich erkennen, auf welche Sendung sich dies bezieht

Das ist der Kern der Verbesserung in diesem Fall.

5.3. Warum sich in diesem Fall die Wartezeit verkürzen ließ

In diesem Fall trat gelegentlich Paketverlust auf, und jedes Mal neigten die RTT-/RTO-Schätzungen dazu, sich in eine konservative Richtung zu verschieben. Aktiviert man Zeitstempel, lässt sich die RTT-Schätzung auch in Szenarien mit Neuübertragung leichter aktualisieren, wodurch sich die Zeit verringert, in der die RTO-Schätzung veraltet weiter anwächst.

Da hier leicht ein gedanklicher Sprung passiert, wird das im Folgenden etwas sorgfältiger aufgeschlüsselt.

Zunächst: Die Untergrenze des RTO selbst ändert sich unabhängig davon, ob Zeitstempel verwendet werden. RFC 6298 legt fest, dass ein berechneter RTO unter 1 Sekunde auf 1 Sekunde aufzurunden ist. Manche Implementierungen haben eine eigene Untergrenze; bei Windows entspricht das dem Wert MinRtoMs, der bei Get-NetTCPSetting erscheint (er liegt in 10-Millisekunden-Schritten im Bereich von 20 bis 300 Millisekunden). Es ist also nicht so, dass „die Untergrenze gesunken ist, weil Zeitstempel eingeführt wurden“.

Was tatsächlich wirkt, liegt davor. RFC 6298 legt die folgenden drei Punkte fest.

1. Jedes Mal, wenn der Retransmission-Timer abläuft, wird der RTO verdoppelt (exponentielles Backoff)
2. Ein durch Backoff erhöhter RTO kehrt zurück, sobald eine neue RTT-Messung vorliegt
3. Diese „neue RTT-Messung“ lässt sich nur gewinnen, wenn Daten gesendet werden, die nicht erneut übertragen wurden, und dafür ein ACK eintrifft

Zudem darf man nach Karns Algorithmus aus erneut gesendeten Segmenten keine RTT-Stichprobe nehmen. Diese Einschränkung entfällt jedoch, wenn die Timestamps-Option verwendet wird. Wie in 5.2 beschrieben, lässt sich anhand von TSecr erkennen, für welche Sendung das ACK gilt.

Reiht man das aneinander, wird das Muster sichtbar. In einem System mit vereinzelt wiederkehrendem Verlust erfüllen sich ohne Zeitstempel die Bedingungen 2 und 3 nur schwer, sodass der verdoppelt gebliebene RTO lange nicht auf Basis einer echten Messung zurückkehrt. Trifft in diesem Zustand der nächste Verlust ein, beginnt das Warten nicht bei 1 Sekunde, sondern gleich bei 2 oder 4 Sekunden. Mit Zeitstempeln lässt sich auch in Abschnitten mit Neuübertragung neu messen, sodass sich diese „Zeit, in der man nicht zurückkehren kann“, verkürzt – das ist der Wirkmechanismus, der in diesem Fall geholfen hat.

Um ehrlich zu sein: In diesem Artikel wurden die tatsächlichen RTO-Messwerte nach der Verbesserung nicht erhoben. Bekannt ist nur, dass der sekundenweise Stillstand so weit zurückging, dass er vor Ort kein Problem mehr darstellte. Wer den Effekt zahlenmäßig zeigen möchte, kommt mit den Anzeigefiltern aus Kapitel 7 und der Spalte Time delta from previous displayed packet am schnellsten voran, indem er die Verteilung des Zeitabstands bis zur Neuübertragung vor und nach der Änderung erfasst.

Anders gesagt: Was hier getan wurde, ist keine Zauberei, die TCP schneller macht, sondern die Zeit zu verringern, in der TCP länger als nötig abwartet.

Natürlich behauptet auch RFC 7323 nicht, dass „mehr RTT-Stichproben alles sauber lösen“. Wie stark sich das auf die RTO-Optimierung auswirkt, ist in mancher Hinsicht begrenzt. Doch der Umstand, dass sich die Mehrdeutigkeit bei einer Neuübertragung beseitigen lässt, kann in einem System wie diesem durchaus direkt wirken.

Es gibt auch Punkte zu beachten.

• Teile davon hängen von der Implementierung des TCP-Stacks ab
• Zeitstempel allein lassen den Paketverlust selbst nicht verschwinden
• Liegt das Problem an der physischen Schicht oder an Zwischengeräten, liegt die eigentliche Ursache woanders
• Auch SACK, NIC-Treiber, Offloading-Einstellungen und Probleme auf Switch-Seite sollten separat untersucht werden

Allerdings kann das in einem System wie diesem, wo „der Verlust nicht null ist“, aber „das eigentliche Problem die sekundenweise Wartezeit ist“, durchaus deutlich wirken.

6. Die tatsächlich ergriffenen Maßnahmen

6.1. Zeitstempel aktivieren

Als Maßnahme wurde dafür gesorgt, dass die Timestamps-Option an beiden Enden der Verbindung ausgehandelt werden kann. Auf Windows-Systemen wird das teilweise als RFC-1323-Option behandelt und ist von den OS- und Netzwerkeinstellungen abhängig.

Hier die konkreten Schritte. Zuerst wird der aktuelle Zustand geprüft.

netsh interface tcp show global

In der Ausgabe gibt es einen Eintrag zu RFC-1323-Zeitstempeln; dort wird geprüft, ob dieser aktiviert ist. Zum Aktivieren lautet der Befehl in einer Eingabeaufforderung mit Administratorrechten so.

netsh interface tcp set global timestamps=enabled

Für timestamps lassen sich die drei Werte disabled / enabled / default angeben; default setzt auf die Systemvorgabe zurück.

Für die Anzeige und Konfiguration über PowerShell gilt Folgendes.

Get-NetTCPSetting | Select-Object SettingName, Timestamps, MinRtoMs, InitialRtoMs
Set-NetTCPSetting -SettingName InternetCustom -Timestamps Enabled

Für Timestamps lassen sich Enabled / Disabled angeben. Welche SettingName-Werte sich ändern lassen, unterscheidet sich je nach Windows-Version, deshalb sollten Sie nicht sofort Set- ausführen, sondern zuerst mit Get-NetTCPSetting prüfen, welche Namen tatsächlich existieren. Übergeben Sie einen nicht existierenden Namen, bricht der Befehl dort ab.

Wer in einer älteren Umgebung direkt in der Registry nachsieht, findet den Wert unter dem folgenden Schlüssel als Tcp1323Opts (REG_DWORD).

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Die Bedeutung der Werte: 0 bedeutet, dass die RFC-1323-Optionen deaktiviert sind, 1 bedeutet nur Window Scaling, 2 bedeutet nur Timestamps, und 3 bedeutet, dass beide aktiviert sind. Merkt man sich, dass Bit 0 für Window Scaling und Bit 1 für Timestamps steht, kommt man nicht durcheinander.

Beim Konfigurieren sind drei Punkte zu beachten.

• Wirksam wird das erst bei neuen Verbindungen. Da Zeitstempel im 3-Way-Handshake ausgehandelt werden, wirkt sich das nicht auf bereits bestehende Verbindungen aus. Die Verbindung auf Geräteseite muss neu aufgebaut werden
• Ohne Unterstützung an beiden Enden kommt es nicht zustande. Auch wenn nur die Hostseite aktiviert ist: Gibt die Kamera im SYN/ACK kein TSopt zurück, wird es auf dieser Verbindung nicht verwendet
• Die Einstellung verändert auch die Eigenschaften der Verbindung. Zeitstempel vergrößern den TCP-Header, wodurch etwas weniger Nutzdaten in einem Segment Platz finden

In der Praxis zählt jedoch weniger, dass „es in der Konfigurationsoberfläche aktiviert ist“, sondern vielmehr, dass „TSopt tatsächlich in den realen SYN- / SYN-ACK-Paketen steht“. Das stimmt wirklich.

6.2. TSopt in SYN / SYN-ACK prüfen

Nach der Aktivierung wurden drei Punkte geprüft.

• Enthält das SYN der betroffenen Verbindung TSopt?
• Gibt auch die SYN/ACK-Seite TSopt zurück?
• Tragen auch die nachfolgenden Datensegmente und ACKs durchgehend TSopt?

Erst wenn dies bestätigt ist, lässt sich sagen, dass „Zeitstempel auf dieser Verbindung tatsächlich verwendet werden“.

6.3. Wo nachzusehen ist, wenn es trotzdem nicht hilft

Auch mit aktivierten Zeitstempeln kann die Verbesserung in folgenden Fällen gering ausfallen.

• Die Verlustrate selbst ist hoch
• Ein Zwischengerät beschädigt, verwirft oder verändert TCP-Optionen
• Es besteht ein anderes Problem im Bereich NIC / Treiber / Offloading
• Die Anwendung hängt alles an einem einzigen synchronen Aufruf, sodass ein einzelnes Warten wie ein kompletter Stillstand aussieht
• Die Hauptursache liegt tatsächlich nicht bei TCP, sondern in einem Verarbeitungsstillstand auf Kameraseite oder einer verstopften Warteschlange im Gerät

Deshalb ist es übersichtlicher, die Maßnahmen in dieser Reihenfolge anzugehen.

1. Zunächst das Warten auf die Neuübertragung auf der Leitung bestätigen
2. Prüfen, ob TSopt ausgehandelt wird
3. Zeitstempel aktivieren und die Verbesserung beobachten
4. Bleibt das Problem bestehen, Verlustquelle und Anwendungsdesign getrennt voneinander angehen

7. Worauf in Wireshark zu achten ist

Hier sind Anzeigefilter aufgeführt, die sich für die Eingrenzung gut eignen.

tcp.stream eq <Zielstream>
tcp.analysis.retransmission
tcp.analysis.fast_retransmission
tcp.analysis.lost_segment
tcp.options.timestamp.tsval
tcp.options.timestamp.tsecr

Beim Lesen gibt es einige Kniffe.

• Mit tcp.stream auf die betroffene Verbindung eingrenzen
• Time delta from previous displayed packet einblenden, um die Stillstandsdauer direkt abzulesen
• Prüfen, ob im fraglichen Moment Retransmission erscheint
• Prüfen, ob TSopt beim Verbindungsaufbau in SYN / SYN-ACK ausgehandelt wird
• Prüfen, ob im ACK TSecr zurückgegeben wird

Auch wie sich das auf dem Bildschirm darstellt, wird hier schriftlich festgehalten. Ist man damit vertraut, erkennt man diesen Fall auf einen Blick.

Ein typisches Muster sieht so aus: Zunächst erscheint eine Zeile mit derselben Seq, eine Sekunde später erneut, dann noch einmal zwei Sekunden danach, unmittelbar nach der letzten Zeile kommt ein ACK zurück, und ab dort läuft der normale Austausch wieder an. Stimmen diese „paar leeren Sekunden“ mit der Zeit überein, in der im Anwendungslog die Antwort ausblieb, ist der Verursacher so gut wie sicher identifiziert.

Beim Abgleich von Logs und Paketen ist auch auf die Differenz zwischen der Anwendungszeit und der Basiszeit der Aufzeichnung zu achten. Ist diese versetzt, neigt man dazu, ein unbeteiligtes Ereignis fälschlich als Verursacher zu identifizieren.

8. Grobe Entscheidungshilfe

Die letzte Zeile kommt wirklich häufig vor. Die Zufriedenheit darüber, eine Einstellung geändert zu haben, und die Tatsache, dass sie auf der Leitung tatsächlich verwendet wird, sind zwei verschiedene Dinge.

9. Zusammenfassung

Die wichtigsten Punkte:

• „Stoppt gelegentlich für einige Sekunden“ kann statt eines Anwendungsstillstands ein Warten von TCP auf eine Neuübertragung sein
• Passt die Stillstandsdauer zum Wartemuster des RTO und ist Retransmission sichtbar, ist das ein starkes Indiz
• Die TCP-Timestamps-Option ist ein Mechanismus für RTTM und PAWS und beseitigt die Mehrdeutigkeit der RTT-Messung bei Neuübertragung
• In diesem Fall ließ sich durch Aktivieren der RFC1323-Zeitstempel die Zeit verringern, in der der RTO übermäßig konservativ blieb

Vorgehensweisen, die vermieden werden sollten:

• Den Verursacher eines Kommunikationsstillstands allein aus den Anwendungslogs bestimmen
• Nur die OS-Einstellungen betrachten, ohne die realen Pakete anzusehen
• Annehmen, dass das Aktivieren von Zeitstempeln auch die Ursache des Verlusts beseitigt

Vorgehensweisen, die in der Praxis funktionieren:

• Zunächst die Leitung betrachten
• Die Form von Neuübertragung und Wartezeit prüfen
• Die Aushandlung von TSopt prüfen
• Auch nach der Verbesserung Verlustquelle und Anwendungsdesign getrennt angehen

Kurz gesagt: Bei dieser Art von Fehler kommt „herausfinden, wo gewartet wird“ vor „schneller machen“. Allein dadurch, dass man das nicht verfehlt, verkürzt sich die Untersuchung erheblich.

10. Referenzen

• RFC 1323 - TCP Extensions for High Performance
• RFC 7323 - TCP Extensions for High Performance
• RFC 5681 - TCP Congestion Control
• RFC 6298 - Computing TCP’s Retransmission Timer
• Description of Windows TCP features - Windows Server | Microsoft Learn
• Netsh commands for Interface Transmission Control Protocol - Microsoft Learn
• Set-NetTCPSetting - Microsoft Learn
• Get-NetTCPSetting - Microsoft Learn
• Wireshark User’s Guide - Time Display Formats And Time References
• Wireshark User’s Guide - Packet Colorization

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Verwandte Fallstudien

Diese Fallstudien zeigen einen ähnlichen Ansatz für Analyse, Priorisierung oder Neugestaltung.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was ist TCP Retransmission (TCP-Neuübertragung)?

Es ist der Mechanismus, mit dem TCP dieselben Daten erneut sendet, wenn für ein gesendetes Paket kein ACK (Bestätigung) zurückkommt. Geht irgendwo unterwegs ein Paket verloren, wartet die Sendeseite auf das ACK und sendet, falls keines kommt, erst nach Ablauf des Retransmission-Timers (RTO) erneut. Aus Sicht der Anwendung sieht das aus wie ein „Stillstand von einigen Sekunden“, aber aus TCP-Sicht ist es lediglich „noch kein ACK erhalten, also wird auf den Ablauf des Retransmission-Timers gewartet“ – dieses Stillstands-Muster kommt ganz normal vor. In der Paketaufzeichnung lässt sich das als TCP Retransmission beobachten.

Was verursacht TCP Retransmission?

Der unmittelbare Auslöser ist Paketverlust: Da kein ACK zurückkommt, kommt es zur Neuübertragung. Als Quelle des Verlusts müssen die physische Schicht (Kabel, Ports), NIC samt Treiber und Offloading-Einstellungen sowie Probleme an Switches oder Zwischengeräten einzeln untersucht werden. Das Aktivieren von TCP-Zeitstempeln kann zwar die Wartezeit nach einer Neuübertragung verkürzen, ist aber keine Zauberei, die den Verlust selbst beseitigt – die Untersuchung der Verlustquelle bleibt separat nötig. Es gibt auch Fälle, in denen ein Zwischengerät TCP-Optionen beschädigt oder verwirft, oder in denen tatsächlich nicht TCP, sondern ein Verarbeitungsstillstand auf Geräteseite die Hauptursache ist.

Warum stoppt die Kommunikation durch TCP-Retransmission gleich mehrere Sekunden lang?

Weil der Retransmission-Timer (RTO) von TCP konservativ wartet. Nach RFC 6298 liegt der Basiswert des initialen RTO bei 1 Sekunde; ist der berechnete Wert kleiner, wird er auf 1 Sekunde aufgerundet, und bei jedem Timeout verdoppelt er sich. Unter schlechten Bedingungen ergeben sich daher Wartezeiten wie 1, 2 oder 4 Sekunden. Bei Steuerkommunikation, die überwiegend aus kleinen Request/Response-Vorgängen besteht, tritt der RTO-Wartezustand eher zutage, bevor genug Duplicate ACKs für ein Fast Retransmit zusammenkommen – das zeigt sich als seltener, mehrsekündiger Stillstand. Aktiviert man die TCP-Timestamps-Option, lässt sich in manchen Fällen die Zeit verkürzen, in der die RTO-Schätzung durch die beim erneuten Senden entstehende Mehrdeutigkeit der RTT-Messung übermäßig konservativ bleibt.

Wie lässt sich TCP Retransmission in Wireshark untersuchen?

Als Anzeigefilter eignen sich unter anderem tcp.analysis.retransmission, tcp.analysis.fast_retransmission und tcp.analysis.lost_segment. Grenzen Sie mit tcp.stream auf die betroffene Verbindung ein, blenden Sie Time delta from previous displayed packet ein, um die Stillstandsdauer direkt zu sehen, und prüfen Sie, ob im fraglichen Moment eine Retransmission auftritt und ob der Zeitabstand bis zur Neuübertragung mit der Stillstandsdauer übereinstimmt. Ob TCP-Zeitstempel verwendet werden, prüfen Sie daran, ob TSopt bereits beim Verbindungsaufbau in SYN / SYN-ACK ausgehandelt wird. Wichtiger als die Aktivierung in der Konfigurationsoberfläche ist die Tatsache, dass TSopt tatsächlich in den realen Paketen steht.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.