9.2 TCP-Handshake, Timeouts und TCP Reset

Ziel dieser Seite

Diese Seite beschreibt den vollständigen Lebenszyklus einer TCP-Verbindung:

Verbindungsaufbau zwischen Client und Server;

Aushandlung wichtiger TCP-Optionen;

zuverlässige und geordnete Datenübertragung;

Bestätigungen, Sequenznummern und Wiederholungen;

kontrollierter Verbindungsabbau;

Timeouts auf unterschiedlichen Ebenen;

abrupter Verbindungsabbruch durch TCP Reset;

systematische Diagnose mit Windows, Linux, macOS und Paketaufzeichnungen.

Nach der Bearbeitung muss unterschieden werden können:

ob bereits der TCP-Verbindungsaufbau scheitert;

welche Seite den Verbindungsaufbau nicht fortsetzt;

ob ein Port aktiv abgelehnt wird;

ob Pakete verworfen oder verzögert werden;

ob TCP erfolgreich aufgebaut wurde und erst das Anwendungsprotokoll scheitert;

ob eine Verbindung kontrolliert mit FIN oder abrupt mit RST beendet wurde;

ob ein Timeout aus TCP, der Anwendung, einem Proxy oder einer Firewall stammt;

welche Gegenstelle oder Zwischenkomponente wahrscheinlich einen Reset erzeugt hat;

ob Wiederholungen auf Paketverlust oder lediglich auf eine unvollständige Aufzeichnung zurückzuführen sind.

Ein TCP-Fehler darf nicht allein anhand einer Anwendungsmeldung wie „Timeout“ oder „Connection reset“ eingeordnet werden. Er muss mit Socketzuständen, Zeitpunkten, Protokollen und bei Bedarf einer begrenzten Paketaufzeichnung korreliert werden.

Sicherheits- und Wirkungsklassen

Kennzeichnung	Bedeutung
LESEND	Erfasst ausschließlich vorhandene Zustände.
NETZAKTIV	Erzeugt Netzwerkverkehr zum geprüften Ziel.
SENSITIV	Kann interne Adressen, Verbindungen oder Nutzdaten sichtbar machen.
ÄNDERND	Verändert Konfiguration oder Laufzeitzustand.
AUSFALLRISIKO	Kann Verbindungen, Prozesse oder Dienste beeinträchtigen.

Paketaufzeichnungen können enthalten:

interne und externe IP-Adressen;

Portnummern;

Hostnamen;

Anwendungsdaten;

Authentifizierungsinformationen;

Cookies oder Tokens;

unverschlüsselte Nutzdaten;

Zertifikatsinformationen;

Kommunikationsbeziehungen.

Aufzeichnungen müssen technisch und zeitlich begrenzt, geschützt gespeichert und nach Abschluss der Diagnose kontrolliert entfernt werden.

Grundlegende Eigenschaften von TCP

TCP stellt Anwendungen einen zuverlässigen, geordneten und bidirektionalen Bytestrom zur Verfügung.

TCP bietet unter anderem:

verbindungsorientierte Kommunikation;

Sequenznummern;

Bestätigungen;

Prüfsummen;

Wiederholungen verlorener Segmente;

Flusskontrolle;

Überlastkontrolle;

geordnete Übergabe der Daten;

kontrollierten Verbindungsabbau;

Erkennung bestimmter ungültiger oder nicht mehr existierender Verbindungen.

TCP stellt keine Anwendungsnachrichten bereit. Eine Anwendung übergibt einen Bytestrom. Die Aufteilung in einzelne TCP-Segmente kann sich während der Übertragung ändern.

Folgende Annahmen sind deshalb falsch:

Eine TCP-Verbindung entspricht einer Anfrage.
Ein TCP-Segment entspricht einer Anwendungsnachricht.
Ein ACK bedeutet, dass die Anwendung die Daten verarbeitet hat.
Ein erfolgreicher Handshake bedeutet, dass HTTP, TLS oder die Anwendung funktioniert.

Ein TCP-ACK bestätigt grundsätzlich, dass die TCP-Implementierung der Gegenstelle die entsprechenden Bytes angenommen hat. Es beweist nicht, dass:

die Anwendung die Bytes gelesen hat;

die Anwendung die Anfrage verstanden hat;

Daten auf einen Datenträger geschrieben wurden;

eine Transaktion erfolgreich abgeschlossen wurde;

eine Anwendungsantwort erzeugt wurde.

TCP-Verbindung eindeutig bestimmen

Eine TCP-Verbindung wird durch ihre Endpunkte unterschieden:

Transportprotokoll
lokale IP-Adresse
lokaler Port
entfernte IP-Adresse
entfernter Port

Beispiel:

Client: 192.0.2.100:53124
Server: 192.0.2.25:443

Die Verbindung kann kompakt dargestellt werden als:

192.0.2.100:53124 → 192.0.2.25:443

Auf der Serverseite ist dieselbe Verbindung aus umgekehrter Perspektive sichtbar:

lokal:   192.0.2.25:443
remote:  192.0.2.100:53124

Bei NAT, Load Balancern oder Proxys können sich Adressen und Ports entlang des Pfads verändern. Paketaufzeichnungen auf verschiedenen Seiten müssen deshalb anhand von:

Zeitpunkt;

Richtung;

TCP-Flags;

Sequenznummern;

Nutzdaten;

übersetzten Adressen und Ports

korreliert werden.

Wichtige TCP-Flags

Flag	Bedeutung
`SYN`	Synchronisiert Sequenznummern und beginnt normalerweise den Verbindungsaufbau.
`ACK`	Das Bestätigungsfeld ist gültig.
`FIN`	Der Sender hat keine weiteren Daten mehr zu senden.
`RST`	Verbindung zurücksetzen oder ungültige Verbindung ablehnen.
`PSH`	Kennzeichnet Daten für eine zeitnahe Weitergabe innerhalb des TCP-Datenstroms.
`URG`	Das Urgent-Pointer-Feld ist relevant.
`ECE`	Wird im Zusammenhang mit Explicit Congestion Notification verwendet.
`CWR`	Signalisiert eine reduzierte Congestion Window nach ECN.

PSH definiert keine Anwendungsnachricht und garantiert keine bestimmte Paketgröße oder sofortige Verarbeitung durch die Anwendung.

Verbindungsaufbau zwischen Client und Server

Der reguläre TCP-Verbindungsaufbau wird als Three-Way Handshake bezeichnet.

Client                                      Server

CLOSED                                      LISTEN
   |                                           |
   |  SYN, Seq=x                               |
   |------------------------------------------>|
   |                                           |
   |  SYN, ACK, Seq=y, Ack=x+1                 |
   |<------------------------------------------|
   |                                           |
   |  ACK, Ack=y+1                             |
   |------------------------------------------>|
   |                                           |
ESTABLISHED                                ESTABLISHED

Die drei logischen Schritte sind:

Der Client sendet ein Segment mit SYN.

Der Server bestätigt das Client-SYN und sendet sein eigenes SYN mit SYN, ACK.

Der Client bestätigt das Server-SYN mit ACK.

Das dritte Segment kann abhängig von Anwendung und TCP-Erweiterungen bereits Daten enthalten. Für die grundlegende Diagnose wird es dennoch als dritter Handshake-Schritt betrachtet.

Sequenznummern beim Handshake

Beispiel:

Client → Server:
SYN
Seq = 1000

Server → Client:
SYN, ACK
Seq = 7000
Ack = 1001

Client → Server:
ACK
Seq = 1001
Ack = 7001

Ein SYN verbraucht eine Sequenznummer. Deshalb bestätigt der Server:

1000 + 1 = 1001

Auch das SYN des Servers verbraucht eine Sequenznummer. Der Client bestätigt:

7000 + 1 = 7001

Die tatsächlich verwendeten Initial Sequence Numbers werden von den TCP-Implementierungen bestimmt und sind nicht als einfache fortlaufende Werte vorhersehbar.

TCP-Zustände während des Verbindungsaufbaus

Zustand	Bedeutung
`CLOSED`	Es besteht keine TCP-Verbindung.
`LISTEN`	Der Server wartet auf neue Verbindungsanfragen.
`SYN-SENT`	Ein SYN wurde gesendet; eine passende Antwort steht aus.
`SYN-RECEIVED`	SYN wurde empfangen und mit SYN/ACK beantwortet; abschließendes ACK steht aus.
`ESTABLISHED`	Der Handshake ist abgeschlossen.

Eine große Zahl von Verbindungen in SYN-SENT kann bedeuten:

Zieladresse nicht erreichbar;

Zielport wird gefiltert;

Rückweg ist fehlerhaft;

Server antwortet nicht;

SYN/ACK wird verworfen;

falsche IPv4- oder IPv6-Adresse;

Überlastung oder Ressourcenproblem;

ausgehende Verbindung wird lokal blockiert.

Viele Einträge in SYN-RECEIVED können bedeuten:

abschließende ACKs erreichen den Server nicht;

Rückweg vom Server zum Client funktioniert, Hinweg des ACKs jedoch nicht;

Clients brechen den Aufbau ab;

SYN-Flood oder ungewöhnlich viele unvollständige Verbindungsversuche;

vorgeschaltete Systeme oder Health Checks öffnen Verbindungen nicht vollständig;

Serverwarteschlangen oder Ressourcen sind erschöpft.

Ein einzelner kurz sichtbarer Zustand SYN-SENT oder SYN-RECEIVED ist normal. Entscheidend sind Häufigkeit, Dauer und Vergleich mit einer Baseline.

TCP-Optionen während des Handshakes

Wichtige Optionen werden typischerweise in SYN-Segmenten angeboten oder ausgehandelt.

Option	Zweck
`MSS`	Maximale TCP-Nutzdatenmenge, die die jeweilige Seite in einem Segment empfangen möchte.
`Window Scale`	Erweitert die darstellbare TCP-Empfangsfenstergröße.
`SACK Permitted`	Erlaubt Selective Acknowledgment.
`Timestamps`	Unterstützt unter anderem RTT-Messungen und Schutzmechanismen gegen alte Segmente.
`ECN`	Ermöglicht Überlastsignalisierung ohne zwingenden Paketverlust, sofern der Pfad sie unterstützt.

Bei der Diagnose müssen die SYN- und SYN/ACK-Optionen verglichen werden.

Zu prüfen sind:

bietet der Client eine MSS an?

bietet der Server eine abweichende MSS an?

wird Window Scaling angeboten?

wird SACK unterstützt?

werden TCP-Timestamps verwendet?

verschwinden Optionen zwischen Client und Server?

verändert eine Firewall oder Optimierungskomponente SYN-Pakete?

unterscheiden sich erfolgreiche und fehlerhafte Verbindungen?

Ein Handshake kann trotz unterschiedlicher angebotener Optionen erfolgreich sein. Die Optionen können jedoch das spätere Übertragungsverhalten beeinflussen.

Erfolgreicher TCP-Handshake

Eine normale Paketfolge ist:

Client → Server  SYN
Server → Client  SYN, ACK
Client → Server  ACK

Dieser Befund beweist:

der Client konnte ein SYN senden;

das SYN erreichte einen antwortenden TCP-Endpunkt;

eine SYN/ACK-Antwort erreichte den Client;

das abschließende ACK konnte gesendet werden;

die TCP-Verbindung wurde mindestens kurzfristig aufgebaut.

Dieser Befund beweist nicht:

dass TLS funktioniert;

dass das richtige Zertifikat geliefert wird;

dass HTTP antwortet;

dass der virtuelle Host stimmt;

dass die Anwendung gesund ist;

dass Authentifizierung funktioniert;

dass eine Datenbankanfrage verarbeitet wird;

dass die Verbindung dauerhaft stabil bleibt.

SYN ohne Antwort

Typischer Paketbefund:

Client → Server  SYN
Client → Server  SYN erneut
Client → Server  SYN erneut
...
Timeout

Mögliche Ursachen:

Zielhost ist nicht erreichbar;

Routing ist fehlerhaft;

lokale Firewall verwirft das SYN;

Netzwerkfirewall verwirft das SYN;

Zielport wird still verworfen;

SYN erreicht den Server nicht;

Server-SYN/ACK wird auf dem Rückweg verworfen;

falsche Zieladresse;

falsche Adressfamilie;

NAT-Zuordnung fehlt;

Load Balancer besitzt kein erreichbares Frontend;

Server oder Zwischenkomponente ist überlastet;

Paketaufzeichnung wurde am falschen Punkt durchgeführt.

Aus einer alleinigen Clientaufzeichnung kann nicht sicher geschlossen werden, ob das SYN den Server erreicht hat. Dafür wird eine korrelierte Aufzeichnung am Server oder an einem geeigneten Zwischenpunkt benötigt.

SYN wird mit Reset beantwortet

Typischer Paketbefund:

Client → Server  SYN
Server → Client  RST, ACK

Typische Einordnung:

Zielhost ist erreichbar;

auf dem angesprochenen Endpunkt existiert häufig kein passender Listener;

das Betriebssystem oder eine Zwischenkomponente lehnt die Verbindung aktiv ab;

eine Firewall kann mit einem Reset ablehnen;

ein Load Balancer besitzt möglicherweise kein verwendbares Backend;

Portweiterleitung zeigt auf einen geschlossenen Zielport.

Eine Anwendung meldet in diesem Fall häufig:

Connection refused
Verbindung abgelehnt
No connection could be made because the target machine actively refused it

Die Meldung beweist nicht, dass der eigentliche Zielserver selbst den Reset erzeugt hat. Firewalls, Proxys und Load Balancer können ebenfalls TCP-Reset-Segmente erzeugen.

Server sendet SYN/ACK, erhält aber kein ACK

Typischer Befund am Server:

Client → Server  SYN
Server → Client  SYN, ACK
Server → Client  SYN, ACK erneut
Server → Client  SYN, ACK erneut
...

Mögliche Ursachen:

SYN/ACK erreicht den Client nicht;

Clientfirewall verwirft die Antwort;

asymmetrischer Rückweg;

NAT-Zustand ist fehlerhaft;

Client sendet das ACK über einen anderen Pfad;

Quelladressprüfung verwirft das Paket;

Clientprozess wurde beendet;

fehlerhafte oder unvollständige Paketaufzeichnung;

Zwischenkomponente verwirft das abschließende ACK.

Zur Eingrenzung werden Aufzeichnungen auf Client- und Serverseite benötigt.

Handshake funktioniert nur teilweise

Paketbefund	Einordnung
kein SYN sichtbar	Anwendung startet keinen TCP-Aufbau oder Aufzeichnungspunkt ist falsch
SYN sichtbar, keine Antwort	Filterung, Routing, Verlust oder fehlender Rückweg
SYN gefolgt von RST	aktive Ablehnung
SYN/ACK wird wiederholt	abschließendes ACK fehlt
Handshake vollständig, danach keine Daten	Anwendung wartet, Protokollmissverständnis oder falsche Rolle
Handshake vollständig, danach RST	Anwendung, Betriebssystem oder Zwischenkomponente bricht ab
Handshake vollständig, danach FIN	kontrollierte Beendigung
Handshake vollständig, TLS beginnt und stoppt	TLS- oder Anwendungsproblem, nicht TCP-Verbindungsaufbau

Die kontrollierte Datenübertragung bei TCP

Nach dem Handshake können beide Seiten Daten senden.

TCP arbeitet als bidirektionaler Bytestrom:

Client ⇄ Server

Jede Richtung besitzt eigene:

Sequenznummern;

Bestätigungen;

Empfangsfenster;

Sendepuffer;

Empfangspuffer;

Wiederholungszustände.

Ein Client kann gleichzeitig Daten senden und Daten des Servers empfangen.

Sequenznummern bei der Datenübertragung

Beispiel:

Client sendet:
Seq = 1001
TCP-Nutzdatenlänge = 500 Bytes

Der Server bestätigt als nächste erwartete Sequenznummer:

Ack = 1501

Berechnung:

1001 + 500 = 1501

Die Bestätigungsnummer bezeichnet das nächste Byte, das die empfangende Seite erwartet.

Wenn der Server Ack = 1501 sendet, bestätigt er kumulativ alle Bytes bis einschließlich Sequenznummer 1500.

Kumulative Bestätigungen

TCP-ACKs sind grundsätzlich kumulativ.

Beispiel:

Segment 1: Seq 1001, Länge 500
Segment 2: Seq 1501, Länge 500
Segment 3: Seq 2001, Länge 500

Wenn der Empfänger anschließend sendet:

Ack = 2501

sind damit alle zusammenhängend empfangenen Bytes bis 2500 bestätigt.

Ein fehlendes Segment kann dazu führen, dass der Empfänger weiterhin dieselbe nächste erwartete Sequenznummer bestätigt.

Selective Acknowledgment

Wenn SACK während des Handshakes erlaubt wurde, kann der Empfänger zusätzlich mitteilen, welche späteren Datenblöcke bereits angekommen sind.

Beispiel:

Segment 1 angekommen
Segment 2 fehlt
Segment 3 angekommen
Segment 4 angekommen

Der kumulative ACK verweist weiterhin auf Segment 2. SACK-Informationen können jedoch anzeigen, dass Segment 3 und Segment 4 bereits vorhanden sind.

Dadurch muss der Sender nicht zwingend alle späteren Daten erneut übertragen.

Verzögerte ACKs

TCP-Implementierungen können Bestätigungen kurz verzögern, um:

mehrere empfangene Segmente gemeinsam zu bestätigen;

ACKs mit eigenen ausgehenden Daten zu kombinieren;

unnötige kleine Pakete zu reduzieren.

Ein nicht sofort sichtbares ACK ist deshalb nicht automatisch ein Fehler.

Entscheidend sind:

tatsächliche Verzögerungsdauer;

Wiederholungen;

Anwendungsreaktion;

Vergleich mit erfolgreichen Verbindungen;

Betriebssystem- und Protokollverhalten.

Flusskontrolle

Der Empfänger teilt über das TCP-Empfangsfenster mit, wie viele weitere Bytes er aufnehmen kann.

Vereinfacht:

Sender darf nur so viele unbestätigte Daten senden,
wie das angekündigte Empfangsfenster zulässt.

Ein kleiner werdendes Empfangsfenster kann darauf hindeuten, dass die empfangende Anwendung Daten nicht schnell genug aus dem Socket liest.

Ein Empfangsfenster von null bedeutet, dass momentan kein weiterer Empfangspuffer verfügbar ist. Die ausführliche Diagnose von Zero Window und Übertragungsstillständen erfolgt auf der dafür vorgesehenen Seite zu Retransmissions, Zero Window und MTU-Problemen.

Überlastkontrolle

Zusätzlich zur Flusskontrolle begrenzt TCP die Sendemenge anhand des vermuteten Netzzustands.

Wichtige Begriffe:

Begriff	Bedeutung
`cwnd`	Congestion Window des Senders
`rwnd`	vom Empfänger angekündigtes Receive Window
`RTT`	gemessene Round Trip Time
`RTO`	berechneter Retransmission Timeout
Slow Start	vorsichtige Erhöhung der Sendemenge zu Beginn oder nach bestimmten Verlusten
Congestion Avoidance	kontrollierte Anpassung der Sendemenge
Fast Retransmit	schnelle Wiederholung bei Verlusthinweisen
Fast Recovery	Wiederherstellung nach bestimmten Verlustereignissen

Die tatsächlich sendbare unbestätigte Datenmenge wird unter anderem durch Empfangsfenster und Congestion Window begrenzt.

Retransmission Timeout

Ein Sender startet für noch nicht bestätigte Daten einen Wiederholungstimer.

Der RTO wird aus gemessenen Laufzeiten und deren Schwankungen berechnet. Er ist kein fester universeller Wert.

Wenn eine Bestätigung nicht rechtzeitig eintrifft:

läuft der Wiederholungstimer ab;

das betreffende Segment kann erneut gesendet werden;

der Wiederholungstimer wird typischerweise vergrößert;

die Sendegeschwindigkeit kann reduziert werden;

nach weiteren erfolglosen Versuchen kann die Verbindung aufgegeben werden.

Die genaue Anzahl der Versuche und die Gesamtdauer sind abhängig von:

Betriebssystem;

TCP-Implementierung;

Verbindungsphase;

Anwendung;

Socketoptionen;

Systemkonfiguration;

Zwischenkomponenten.

Es darf kein universeller TCP-Timeoutwert angenommen werden.

Fast Retransmit

Beim klassischen Fast-Retransmit-Verfahren können mehrere Duplicate ACKs den Sender darauf hinweisen, dass ein früheres Segment fehlt, während spätere Segmente angekommen sind.

Der Sender kann das fehlende Segment wiederholen, bevor der normale RTO abläuft.

Moderne TCP-Implementierungen können zusätzlich oder alternativ weitere Verlustalgorithmen und SACK-Informationen verwenden. Deshalb darf nicht jeder Fast-Retransmit ausschließlich anhand einer festen Zahl von Duplicate ACKs erklärt werden.

Duplicate ACKs richtig einordnen

Duplicate ACKs können entstehen durch:

tatsächlich verlorenes Segment;

Paketumordnung;

duplizierte Pakete;

verzögerte Übertragung;

unvollständige Paketaufzeichnung;

asymmetrische Aufzeichnung;

unterschiedliche Netzwerkpfade;

Captureverlust am Analysesystem.

Ein Duplicate ACK ist ein Hinweis und kein alleiniger Beweis für Paketverlust.

TCP-Retransmissions richtig einordnen

Eine als Retransmission markierte Übertragung kann bedeuten:

ursprüngliches Segment ging im Netzwerk verloren;

Bestätigung ging verloren;

ursprüngliches Segment wurde am Aufzeichnungspunkt nicht erfasst;

Pakete trafen in anderer Reihenfolge ein;

Aufzeichnungssoftware verlor Pakete;

Daten wurden durch Offloading anders dargestellt;

Wireshark ordnete den Datenstrom heuristisch ein.

Wireshark-Analysefelder wie tcp.analysis.retransmission sind Analyseergebnisse und keine im TCP-Paket übertragenen Flags.

TCP Checksum Offloading berücksichtigen

Bei einer Aufzeichnung auf dem sendenden Host kann eine TCP-Prüfsumme als fehlerhaft erscheinen, obwohl das Netzwerkpaket später korrekt übertragen wird.

Mögliche Ursache:

die Netzwerkkarte berechnet die Prüfsumme erst nach dem Aufzeichnungspunkt;

TCP Segmentation Offload zerlegt große Datenblöcke erst in der Netzwerkkarte;

Generic Receive Offload oder Large Receive Offload fasst Daten zusammen.

Deshalb gilt:

Eine lokal als fehlerhaft angezeigte TCP-Prüfsumme
beweist ohne weitere Prüfung keinen Netzwerkfehler.

Zu vergleichen sind:

Aufzeichnung am sendenden Host;

Aufzeichnung auf einem externen Messpunkt;

Offloading-Anzeige des Analysewerkzeugs;

erfolgreiche und fehlerhafte Verbindungen.

TCP besitzt keine Anwendungs-Lebendigkeitsprüfung

Eine bestehende TCP-Verbindung kann im Zustand ESTABLISHED verbleiben, obwohl:

die Gegenstelle ausgefallen ist;

ein Kabel getrennt wurde;

eine Firewall den Sitzungszustand gelöscht hat;

der Netzwerkpfad nicht mehr funktioniert;

die Anwendung der Gegenstelle nicht mehr reagiert.

Solange keine Daten übertragen oder Prüfmechanismen ausgelöst werden, erkennt TCP einen solchen Zustand nicht zwingend sofort.

Mögliche zusätzliche Mechanismen sind:

TCP Keepalive;

anwendungsspezifische Heartbeats;

Request-Timeouts;

Health Checks;

Sitzungszeitüberschreitungen;

erneuter Verbindungsaufbau.

Ein TCP-Keepalive beweist nur eine Reaktion des TCP-Endpunkts. Es beweist nicht automatisch, dass die Anwendung fachlich gesund ist.

Timeout ist nicht gleich Timeout

Die Meldung „Timeout“ kann aus verschiedenen Ebenen stammen.

Timeoutart	Phase	Typischer Befund
DNS-Timeout	vor TCP	kein SYN zum eigentlichen Server
TCP-Connect-Timeout	Handshake	SYN bleibt unbeantwortet
TCP-Retransmission-Timeout	Datenübertragung	unbestätigte Segmente werden wiederholt
TLS-Handshake-Timeout	nach TCP-Aufbau	TCP steht, TLS wird nicht abgeschlossen
Application-Read-Timeout	nach Anfrage	TCP steht, erwartete Antwort fehlt
Application-Write-Timeout	Datenversand	Anwendung kann nicht rechtzeitig schreiben
Proxy-Connect-Timeout	Proxy zum Backend	Client erreicht Proxy, Proxy nicht das Backend
Proxy-Read-Timeout	Proxy wartet auf Backend	Backendverbindung besteht, Antwort dauert zu lange
Firewall-Idle-Timeout	längere Inaktivität	Sitzungszustand der Firewall wird entfernt
NAT-Idle-Timeout	längere Inaktivität	NAT-Zuordnung läuft ab
Load-Balancer-Idle-Timeout	längere Inaktivität	Load Balancer verwirft inaktive Sitzung
TCP-Keepalive-Timeout	Prüfmechanismus	Gegenstelle reagiert nicht auf Keepalive-Probes
Anwendungsdeadline	beliebige Phase	Anwendung bricht nach eigener Gesamtfrist ab

Vor einer Änderung muss festgestellt werden, welcher Zeitgeber tatsächlich abgelaufen ist.

Connect-Timeout erkennen

Typischer Ablauf:

Anwendung startet Verbindung
Client sendet SYN
keine verwertbare Antwort
SYN wird wiederholt
Anwendung meldet Timeout

Zu prüfen sind:

Zeitpunkt des ersten SYN;

Anzahl und Abstand der SYN-Wiederholungen;

Zeitpunkt der Anwendungsmeldung;

kommt ein SYN/ACK oder RST an?

erreicht das SYN den Server?

erreicht die Antwort den Client?

beendet die Anwendung den Versuch vor dem TCP-Stack?

versucht die Anwendung danach eine weitere Zieladresse?

Bei mehreren DNS-Adressen kann die Anwendung nacheinander oder parallel unterschiedliche Ziele versuchen. Die sichtbare Gesamtdauer muss daher nicht dem Timeout eines einzelnen TCP-Versuchs entsprechen.

Anwendungs-Timeout nach erfolgreichem Handshake

Typischer Ablauf:

SYN
SYN, ACK
ACK
Anwendungsanfrage
keine oder verspätete Anwendungsantwort
Anwendung meldet Timeout

TCP ist in diesem Fall grundsätzlich aufgebaut.

Mögliche Ursachen:

Serveranwendung verarbeitet die Anfrage zu langsam;

Backenddienst reagiert nicht;

Datenbankabfrage blockiert;

Thread- oder Workerpool ist erschöpft;

Empfangsfenster wird klein oder null;

Proxy wartet auf ein Backend;

falsches Anwendungsprotokoll;

Deadlock oder Ressourcensperre;

Antwortpakete gehen verloren;

Anwendung verwendet eine zu kurze Frist.

Die Diagnose darf nicht bei einem erfolgreichen Porttest enden.

Idle-Timeout erkennen

Typischer Ablauf:

TCP-Verbindung wird erfolgreich aufgebaut
Datenübertragung funktioniert
Verbindung bleibt längere Zeit inaktiv
erste neue Übertragung schlägt fehl
eine neue TCP-Verbindung funktioniert wieder

Mögliche Ursachen:

Firewall hat Sessiontabelleneintrag entfernt;

NAT-Zuordnung ist abgelaufen;

Load Balancer hat die Verbindung geschlossen;

Proxy hat seine Idle-Frist erreicht;

Serveranwendung hat die Sitzung beendet;

Client verwendet eine veraltete Verbindung aus einem Connection Pool;

TCP Keepalive ist nicht aktiv oder zu spät eingestellt.

Benötigter Nachweis:

genaue Dauer der Inaktivität;

Zeitpunkt der letzten erfolgreichen Datenübertragung;

Paketfolge beim ersten erneuten Sendeversuch;

Verhalten bei einer frisch aufgebauten Verbindung;

konfigurierte Idle-Timeouts aller Zwischenkomponenten;

Anwendungspool- und Keepalive-Konfiguration.

TCP Reset

Ein TCP-Reset wird durch das Flag RST signalisiert.

Ein Reset bedeutet grundsätzlich:

Diese TCP-Verbindung soll sofort zurückgesetzt werden
oder der angesprochene TCP-Zustand ist nicht gültig.

Im Unterschied zu einem geordneten Abbau mit FIN ist ein Reset ein abrupter Abbruch.

Mögliche Anwendungsmeldungen:

Connection reset by peer
ECONNRESET
An existing connection was forcibly closed by the remote host
Die Verbindung wurde vom Kommunikationspartner zurückgesetzt
SocketException: Connection reset

Die Formulierung „by peer“ bedeutet nicht zwingend, dass der eigentliche Anwendungsprozess der Gegenstelle den Reset absichtlich erzeugt hat. Der Reset kann stammen von:

Betriebssystem der Gegenstelle;

Anwendung;

lokalem Betriebssystem;

Firewall;

Load Balancer;

Reverse Proxy;

NAT-Gateway;

Intrusion-Prevention-System;

Service Mesh;

Container- oder Cloudnetzkomponente.

Typische Ursachen eines TCP Reset

Verbindung zu einem geschlossenen TCP-Port;

Anwendung bricht einen Socket ausdrücklich ab;

Prozess wird beendet oder stürzt ab;

Anwendung schließt mit ungelesenen Eingangsdaten;

ungültiges Segment für eine nicht mehr existierende Verbindung;

Gegenstelle hat den Verbindungszustand verloren;

Host wurde neu gestartet;

alte Verbindung wird nach längerer Inaktivität erneut verwendet;

Firewall oder Load Balancer hat den Sitzungszustand entfernt;

Proxy lehnt eine Verbindung oder Anfrage ab;

Backend ist nicht verfügbar;

Protokoll wird auf dem falschen Port verwendet;

Sicherheitskomponente beendet die Sitzung;

Verbindungslimit oder Ressourcenlimit wurde erreicht;

Zeitüberschreitung führt zu einem erzwungenen Abbruch;

fehlerhafte NAT- oder Sessionzuordnung;

Paket gehört zu einer früheren Verbindung mit wiederverwendetem Port;

Anwendung verwendet eine abortive Socket-Schließung.

Nicht jede Prozessbeendigung erzeugt zwingend einen Reset. Abhängig vom Socketzustand und Betriebssystem kann auch ein kontrollierter FIN-Abbau erfolgen.

Reset während des Handshakes

Paketfolge:

Client → Server  SYN
Server → Client  RST, ACK

Mögliche Einordnung:

kein Listener auf dem Zielport;

Firewall lehnt aktiv ab;

Portweiterleitung zeigt auf geschlossenen Port;

Load Balancer lehnt ab;

falsche Zieladresse;

Dienst wurde beendet;

Listener existiert nur auf einer anderen lokalen Adresse;

IPv4-/IPv6-Bindung passt nicht.

Nächster Nachweis:

Listener direkt auf dem Zielsystem prüfen;

Prozessbesitzer bestimmen;

Zieladresse und Adressfamilie bestätigen;

Paketaufzeichnung auf Serverseite durchführen;

Firewall- und NAT-Pfad prüfen.

Reset unmittelbar nach erfolgreichem Handshake

Paketfolge:

SYN
SYN, ACK
ACK
RST

Mögliche Ursachen:

Anwendung akzeptiert und verwirft die Verbindung sofort;

Prozess- oder Workerlimit erreicht;

Zugriffskontrolle lehnt ab;

Proxy besitzt kein Backend;

Client beendet den Socket abrupt;

Server erwartet sofortige Protokolldaten;

Health Check verwendet ein unpassendes Protokoll;

Verbindungszustand ist zwischen Komponenten inkonsistent.

Zu prüfen sind:

wer sendet den Reset?

wird vor dem Reset Anwendungsnutzlast übertragen?

existiert im Serverlog eine passende Verbindung?

tritt der Fehler bei jedem Client auf?

funktioniert ein protokollspezifischer Test?

Reset nach Übertragung einer Anfrage

Paketfolge:

Handshake erfolgreich
Client sendet Anfrage
Server oder Zwischenkomponente sendet RST

Mögliche Ursachen:

ungültiges Anwendungsprotokoll;

TLS-Daten an einem Klartextport;

Klartextdaten an einem TLS-Port;

fehlerhafte oder verbotene Anfrage;

Anwendung stürzt bei der Verarbeitung ab;

Proxy oder WAF beendet die Verbindung;

maximale Anfragegröße überschritten;

Sicherheitsrichtlinie löst aus;

Backend schließt abrupt;

Server liest die Anfrage nicht vollständig;

Client sendet weiter, nachdem der Server bereits geschlossen hat.

Der Inhalt unmittelbar vor dem Reset ist für die Ursachenbestimmung besonders wichtig.

Reset nach längerer Inaktivität

Typischer Ablauf:

Verbindung ist ESTABLISHED
keine Übertragung über längere Zeit
Client sendet neue Daten
RST wird empfangen

Mögliche Ursache:

Zwischenkomponente hat den Sitzungszustand gelöscht;

Server hat die Verbindung lokal bereits beendet;

Anwendung verwendet einen veralteten Socket;

Connection Pool prüft die Verbindung vor Wiederverwendung nicht;

Idle-Timeouts verschiedener Komponenten sind nicht abgestimmt.

Zu vergleichen sind:

TCP-Keepalive;

Anwendungsheartbeat;

Firewall-Idle-Timeout;

NAT-Timeout;

Proxy-Timeout;

Load-Balancer-Timeout;

Connection-Pool-Lebensdauer.

Reset nach Wiederholungen

Möglicher Ablauf:

Daten werden gesendet
Bestätigung fehlt
Daten werden wiederholt
weitere Wiederholungen
RST oder lokaler Verbindungsabbruch

Ein Reset nach Wiederholungen kann bedeuten:

Netzwerkpfad war unterbrochen;

Gegenstelle hat den Zustand verloren;

Anwendung oder Betriebssystem gibt die Verbindung auf;

eine Zwischenkomponente reagiert auf eine nicht mehr bekannte Sitzung;

Prozess wurde während des Fehlers beendet.

Die zeitliche Reihenfolge muss genau ausgewertet werden. Der Reset kann Folge und nicht Ursache des ursprünglichen Problems sein.

Reset-Absender bestimmen

In der Clientaufzeichnung ist zunächst die Quelladresse des Reset-Segments sichtbar. Sie ist jedoch nicht immer ein eindeutiger Beweis für den tatsächlichen Erzeuger.

Zwischenkomponenten können:

mit der Adresse des Servers antworten;

Verbindungen stellvertretend terminieren;

NAT-Adressen verwenden;

einen eigenen TCP-Endpunkt darstellen;

Reset-Segmente erzeugen.

Belastbarer Nachweis:

Aufzeichnung am Client.

Aufzeichnung am Server.

Zeitliche Synchronisation beider Systeme.

Vergleich derselben TCP-Verbindung.

Prüfung, ob der Reset den Server verlässt.

Prüfung, ob der Server den Reset überhaupt empfängt.

Protokolle von Firewall, Proxy und Load Balancer korrelieren.

Beispiel:

Client sieht einen RST.
Serveraufzeichnung zeigt keinen ausgehenden RST.
Firewallprotokoll zeigt eine aktive Sitzungsbeendigung.

Einordnung:
Der Reset wurde wahrscheinlich von der Firewall erzeugt.

Dies ist eine Schlussfolgerung aus mehreren Befunden und nicht allein aus der IP-Quelladresse.

FIN, RST und Timeout unterscheiden

Befund	Bedeutung
`FIN`	Sender beendet seine Senderichtung geordnet.
`RST`	Verbindung wird abrupt zurückgesetzt.
Timeout	Innerhalb der erwarteten Frist kam keine verwertbare Reaktion.
ICMP-Fehler	IP- oder Netzwerkebene meldet ein Problem.
Anwendungsfehler	TCP kann funktionieren, während das höhere Protokoll fehlschlägt.

Ein FIN bedeutet nicht zwingend, dass die gesamte Verbindung sofort beendet ist. TCP unterstützt einen geordneten Abbau je Richtung.

Verbindungsabbau zwischen Client und Server

Ein regulärer TCP-Abbau besteht logisch aus:

Teilnehmer A                                 Teilnehmer B

ESTABLISHED                                 ESTABLISHED
     |                                           |
     |  FIN, ACK                                 |
     |------------------------------------------>|
     |                                           |
FIN-WAIT-1                                  CLOSE-WAIT
     |                                           |
     |  ACK                                      |
     |<------------------------------------------|
     |                                           |
FIN-WAIT-2                                  CLOSE-WAIT
     |                                           |
     |  FIN, ACK                                 |
     |<------------------------------------------|
     |                                           |
TIME-WAIT                                   LAST-ACK
     |                                           |
     |  ACK                                      |
     |------------------------------------------>|
     |                                           |
TIME-WAIT                                     CLOSED
     |
     | nach Ablauf der Wartezeit
     |
  CLOSED

Dies wird häufig als Four-Way Termination bezeichnet.

In einer echten Aufzeichnung müssen nicht immer vier getrennte Pakete sichtbar sein. ACK und FIN können kombiniert werden.

FIN verbraucht eine Sequenznummer

Wie SYN verbraucht auch FIN eine Sequenznummer.

Beispiel:

Teilnehmer A sendet:
FIN, Seq = 5000

Teilnehmer B bestätigt:
ACK = 5001

Das FIN signalisiert:

Ich werde in dieser Richtung keine weiteren Daten mehr senden.

Die Gegenrichtung kann abhängig vom Anwendungs- und Socketzustand noch Daten übertragen.

Half-Close

Bei einem Half-Close wurde nur eine Senderichtung geordnet geschlossen.

Beispiel:

Client sendet FIN.
Server bestätigt FIN.
Server sendet weiterhin verbleibende Antwortdaten.
Server sendet später sein eigenes FIN.

Half-Close ist nicht dasselbe wie eine Half-Open Connection.

Begriff	Bedeutung
Half-Close	Eine Richtung wurde geordnet mit FIN beendet.
Half-Open	Beide Endpunkte besitzen unterschiedliche Vorstellungen darüber, ob die Verbindung noch existiert.

Eine Half-Open Connection kann beispielsweise entstehen, wenn ein System neu startet und den früheren TCP-Zustand verliert, während die Gegenstelle die Verbindung weiterhin als vorhanden betrachtet.

TCP-Zustände beim Verbindungsabbau

Zustand	Bedeutung
`FIN-WAIT-1`	Lokales FIN wurde gesendet; Bestätigung oder FIN der Gegenstelle steht aus.
`FIN-WAIT-2`	Lokales FIN wurde bestätigt; FIN der Gegenstelle steht aus.
`CLOSE-WAIT`	FIN der Gegenstelle wurde empfangen; lokale Anwendung hat noch nicht geschlossen.
`CLOSING`	Beide Seiten haben nahezu gleichzeitig FIN gesendet.
`LAST-ACK`	Lokales FIN wurde nach empfangenem FIN gesendet; abschließendes ACK steht aus.
`TIME-WAIT`	Endpunkt wartet, damit verspätete Segmente einer alten Verbindung nicht falsch zugeordnet werden.
`CLOSED`	Verbindung ist vollständig beendet.

CLOSE-WAIT richtig interpretieren

CLOSE-WAIT bedeutet:

Die Gegenstelle hat ihre Senderichtung geschlossen.
Das lokale Betriebssystem wartet darauf,
dass die lokale Anwendung ihren Socket schließt.

Viele dauerhaft vorhandene CLOSE-WAIT-Sockets können hinweisen auf:

Anwendung liest EOF, schließt aber nicht;

Fehler im Connection-Handling;

blockierte Threads;

fehlende Fehlerbehandlung;

Ressourcenleck;

Anwendung wartet auf einen internen Vorgang;

Prozess reagiert nicht.

CLOSE-WAIT wird nicht durch das bloße Ändern eines TCP-Timers behoben. Zuerst müssen Prozess und Anwendungscode beziehungsweise Herstellerprotokolle geprüft werden.

FIN-WAIT-2 richtig interpretieren

FIN-WAIT-2 bedeutet:

Die lokale Seite hat ihre Senderichtung geschlossen.
Die Gegenstelle hat dies bestätigt,
aber noch kein eigenes FIN gesendet.

Mögliche Ursachen bei ungewöhnlich langen Beständen:

Gegenanwendung hält ihre Senderichtung offen;

Anwendung wartet auf weitere Verarbeitung;

Gegenprozess reagiert nicht;

Half-Close wird absichtlich verwendet;

Netzwerk- oder Zustandsproblem.

Ein kurzfristiger FIN-WAIT-2-Zustand ist nicht automatisch fehlerhaft.

TIME-WAIT richtig interpretieren

TIME-WAIT schützt unter anderem davor, dass verspätete Segmente einer alten Verbindung einer späteren Verbindung mit denselben Endpunkten zugeordnet werden.

Viele TIME-WAIT-Einträge können bei folgenden Arbeitslasten normal sein:

viele kurze HTTP-Verbindungen;

häufige Health Checks;

Proxy- oder API-Aufrufe;

fehlendes oder nicht genutztes Connection Pooling;

Lasttests;

Microservice-Kommunikation.

Zu prüfen sind:

Rate neuer Verbindungen;

Wiederverwendung bestehender Verbindungen;

Quellportbestand;

Verbindungslaufzeit;

Baseline;

Anwendungskonfiguration.

TIME-WAIT darf nicht vorsorglich durch aggressive Timeränderungen beseitigt werden.

Windows: TCP-Zustände prüfen

LESEND

Alle TCP-Verbindungen:

Get-NetTCPConnection |
  Sort-Object State, LocalPort

Verbindungen im Zustand SYN-SENT:

Get-NetTCPConnection `
  -State SynSent

Verbindungen im Zustand SYN-RECEIVED:

Get-NetTCPConnection `
  -State SynReceived

Aufgebaute Verbindungen:

Get-NetTCPConnection `
  -State Established

CLOSE-WAIT:

Get-NetTCPConnection `
  -State CloseWait

TIME-WAIT:

Get-NetTCPConnection `
  -State TimeWait

Bestimmten entfernten Port prüfen:

Get-NetTCPConnection `
  -RemotePort 443 |
  Select-Object `
    LocalAddress,
    LocalPort,
    RemoteAddress,
    RemotePort,
    State,
    OwningProcess

Serververbindungen eines lokalen Ports:

Get-NetTCPConnection `
  -LocalPort 443 |
  Select-Object `
    LocalAddress,
    LocalPort,
    RemoteAddress,
    RemotePort,
    State,
    OwningProcess

Kurzlebige Zustände können zwischen zwei Abfragen verschwinden. Eine Paketaufzeichnung ist für die vollständige zeitliche Reihenfolge zuverlässiger.

Windows: Prozess zuordnen

LESEND

Get-NetTCPConnection `
  -RemotePort 443 |
  ForEach-Object {
    $connection = $_
    $process = Get-Process `
      -Id $connection.OwningProcess `
      -ErrorAction SilentlyContinue

    [pscustomobject]@{
      LocalAddress  = $connection.LocalAddress
      LocalPort     = $connection.LocalPort
      RemoteAddress = $connection.RemoteAddress
      RemotePort    = $connection.RemotePort
      State         = $connection.State
      ProcessId     = $connection.OwningProcess
      ProcessName   = $process.ProcessName
    }
  }

Ein Prozess kann zwischen Socketabfrage und Prozessabfrage bereits beendet sein. Fehlende Prozessinformationen müssen deshalb mit Zeitpunkt und Ereignisprotokollen korreliert werden.

Windows: TCP-Verbindung aktiv testen

NETZAKTIV

Test-NetConnection `
  -ComputerName "app.example.test" `
  -Port 443 `
  -InformationLevel Detailed

Wichtige Felder:

ComputerName;

RemoteAddress;

RemotePort;

InterfaceAlias;

SourceAddress;

TcpTestSucceeded.

TcpTestSucceeded = True bestätigt einen erfolgreichen TCP-Verbindungsaufbau für diesen Versuch. Es bestätigt nicht die Funktion von TLS, HTTP oder der eigentlichen Anwendung.

Getrennte Prüfung einer konkreten Adresse:

Test-NetConnection `
  -ComputerName "192.0.2.25" `
  -Port 443 `
  -InformationLevel Detailed

Windows: TCP-Statistiken prüfen

LESEND

netstat -s -p tcp

IPv6-TCP-Statistiken:

netstat -s -p tcpv6

Verfügbare Leistungsindikatoren suchen:

Get-Counter `
  -ListSet "*TCP*"

Die Namen der Leistungsindikatoren können von Sprache und Windows-Version abhängen.

Zähler müssen über einen definierten Zeitraum als Differenz oder Rate ausgewertet werden. Ein hoher kumulierter Wert seit dem Systemstart beweist keine aktuelle Störung.

Windows: Paketaufzeichnung mit pktmon

pktmon verändert den Aufzeichnungszustand und erstellt Dateien.

SENSITIV · ÄNDERND

Vorhandene Aufzeichnung stoppen:

pktmon stop

Vorhandene Filter entfernen:

pktmon filter remove

Filter für TCP-Port 443 anlegen:

pktmon filter add TCP443 -t TCP -p 443

Aufzeichnung starten:

pktmon start --capture --pkt-size 0 --file-name C:\Temp\tcp443.etl

Nach reproduziertem Fehler stoppen:

pktmon stop

In PCAPNG konvertieren:

pktmon etl2pcap C:\Temp\tcp443.etl --out C:\Temp\tcp443.pcapng

Temporären Filter entfernen:

pktmon filter remove

Voraussetzungen:

Zielverzeichnis existiert;

ausreichend freier Speicher ist vorhanden;

Aufzeichnungszeitraum ist begrenzt;

Datei wird geschützt gespeichert;

Filter und Aufzeichnungszustand werden anschließend zurückgesetzt.

Linux: TCP-Zustände mit ss prüfen

LESEND

Alle TCP-Sockets:

ss -tan

TCP-Sockets mit Prozessinformationen:

sudo ss -tanp

SYN-SENT:

ss -tan state syn-sent

SYN-RECEIVED:

ss -tan state syn-recv

Aufgebaute Verbindungen:

ss -tan state established

CLOSE-WAIT:

ss -tan state close-wait

TIME-WAIT:

ss -tan state time-wait

Erweiterte TCP-Informationen für Zielport 443:

sudo ss -tin \
  'dport = :443'

Erweiterte Informationen für einen lokalen Serverport:

sudo ss -tin \
  'sport = :443'

Je nach Zustand und Kernel können erweiterte Angaben enthalten sein:

RTT;

RTO;

Congestion Window;

Retransmissions;

Sendemenge;

Empfangsmenge;

Window Scaling;

MSS;

Timer.

Die konkrete Ausgabe hängt von Kernel und TCP-Zustand ab.

Linux: TCP-Zähler prüfen

LESEND

nstat -az

Bestimmte Zähler:

nstat -az TcpRetransSegs

nstat -az TcpAttemptFails

nstat -az TcpEstabResets

Zusätzliche klassische Statistik:

netstat -s

Zu beachten:

Zähler sind häufig kumulativ;

ein Reset-Zähler nennt nicht automatisch die betroffene Anwendung;

Container oder Netzwerk-Namespaces können eigene Sichten besitzen;

für eine aktuelle Störung sind Vorher-Nachher-Differenzen notwendig.

macOS: TCP-Zustände prüfen

LESEND

netstat -anv -p tcp

TCP-Verbindungen mit Prozesszuordnung:

sudo lsof -nP -iTCP

Aufgebaute TCP-Verbindungen:

sudo lsof \
  -nP \
  -iTCP \
  -sTCP:ESTABLISHED

Interaktive TCP-Ansicht:

nettop -m tcp

TCP-Statistiken:

netstat -s -p tcp

Kurzlebige Handshakezustände können auch unter macOS leichter mit einer Paketaufzeichnung als mit wiederholten Socketabfragen erfasst werden.

Aktive Tests unter Linux und macOS

TCP-Porttest:

NETZAKTIV

nc -vz app.example.test 443

Linux mit begrenzter Wartezeit, abhängig von der installierten nc-Variante:

nc -vz -w 5 app.example.test 443

macOS mit TCP-Verbindungsfrist:

nc -vz -G 5 app.example.test 443

HTTP- oder HTTPS-Test mit getrennten Fristen:

curl \
  --connect-timeout 5 \
  --max-time 15 \
  -v \
  https://app.example.test/

Bedeutung:

--connect-timeout begrenzt die Verbindungsphase;

--max-time begrenzt den gesamten Aufruf.

Ein Fehler nach erfolgreicher Connected-Meldung ist kein reiner TCP-Connect-Fehler mehr.

Paketaufzeichnung unter Linux

SENSITIV · LESEND

Auf Port 443 begrenzen:

sudo tcpdump \
  -ni any \
  'tcp port 443' \
  -c 200

Auf einen Host und Port begrenzen:

sudo tcpdump \
  -ni any \
  'host 192.0.2.25 and tcp port 443' \
  -c 200

Mit ausführlicheren TCP-Informationen in Datei schreiben:

sudo tcpdump \
  -ni any \
  -s 0 \
  -w /tmp/tcp443.pcap \
  'host 192.0.2.25 and tcp port 443'

Nach reproduziertem Fehler mit Strg+C beenden.

Die Datei enthält möglicherweise sensible Daten und muss anschließend geschützt ausgewertet und kontrolliert entfernt werden.

Paketaufzeichnung unter macOS

Verwendbare Schnittstellen anzeigen:

tcpdump -D

Auf einer konkreten Schnittstelle:

sudo tcpdump \
  -ni en0 \
  'host 192.0.2.25 and tcp port 443' \
  -c 200

Lokale Loopback-Verbindung:

sudo tcpdump \
  -ni lo0 \
  'tcp port 8080' \
  -c 200

In Datei schreiben:

sudo tcpdump \
  -ni en0 \
  -s 0 \
  -w /tmp/tcp443.pcap \
  'host 192.0.2.25 and tcp port 443'

Wireshark-Filter für TCP

Bestimmter Port:

tcp.port == 443

Bestimmte IP-Adresse und Port:

ip.addr == 192.0.2.25 && tcp.port == 443

Nur initiale SYN-Segmente:

tcp.flags.syn == 1 && tcp.flags.ack == 0

SYN/ACK:

tcp.flags.syn == 1 && tcp.flags.ack == 1

Reset:

tcp.flags.reset == 1

FIN:

tcp.flags.fin == 1

Vermutete Wiederholungen:

tcp.analysis.retransmission

Vermuteter Fast Retransmit:

tcp.analysis.fast_retransmission

Duplicate ACKs:

tcp.analysis.duplicate_ack

Zero Window:

tcp.analysis.zero_window

Ein bestimmter TCP-Datenstrom:

tcp.stream == 7

Die Nummer des TCP-Streams wird von Wireshark innerhalb der geöffneten Aufzeichnung vergeben und ist keine übertragene Protokollnummer.

Aufzeichnung richtig planen

Vor Beginn sind festzulegen:

Client:
<Hostname und IP-Adresse>

Server:
<Hostname und IP-Adresse>

Port:
<TCP-Port>

Zeitfenster:
<Start und Ende>

Testhandlung:
<genau ein reproduzierbarer Versuch>

Aufzeichnungspunkte:
<Client, Server und gegebenenfalls Zwischenkomponente>

Erwartete Paketfolge:
<SYN, SYN/ACK, ACK und Anwendungsdaten>

Fehlerkriterium:
<Timeout, RST, FIN oder fehlende Antwort>

Die Systemzeiten der beteiligten Geräte müssen ausreichend synchron sein. Anderenfalls können Client-, Server-, Firewall- und Proxyprotokolle nicht zuverlässig korreliert werden.

Aufzeichnung am Client und Server vergleichen

Clientaufzeichnung	Serveraufzeichnung	Mögliche Einordnung
SYN sichtbar	SYN nicht sichtbar	Fehler vor dem Server
SYN sichtbar	SYN sichtbar	Hinweg funktioniert
kein SYN/ACK am Client	SYN/ACK verlässt Server	Rückweg oder Filterung
RST am Client	RST verlässt Server	Server oder Serveranwendung wahrscheinlich beteiligt
RST am Client	kein RST am Server	Zwischenkomponente wahrscheinlich beteiligt
Daten am Client gesendet	Daten erreichen Server	Hinweg der Daten funktioniert
ACK fehlt am Client	ACK verlässt Server	Rückwegproblem
Server erhält ACK nicht	Client sendet ACK	Filterung oder asymmetrischer Pfad
FIN auf beiden Seiten	FIN verlässt ursprünglichen Sender	kontrollierter Abbau
unterschiedliche Paketfolgen	Übersetzung oder Verlust	NAT, Proxy, Capturepunkt oder Netzwerkpfad prüfen

NAT, Firewall, Proxy und Load Balancer berücksichtigen

Eine Ende-zu-Ende-Verbindung kann tatsächlich aus mehreren getrennten TCP-Verbindungen bestehen.

Beispiel mit Reverse Proxy:

Client
→ TCP-Verbindung 1
→ Reverse Proxy
→ TCP-Verbindung 2
→ Backend

Ein Reset zwischen Proxy und Backend muss nicht als Reset zwischen Proxy und Client weitergegeben werden. Der Proxy kann stattdessen eine HTTP-Fehlerantwort erzeugen.

Beispiel mit NAT:

Client intern:        192.0.2.100:53124
NAT extern:           203.0.113.10:62000
Server:               198.51.100.25:443

Zu prüfen sind:

übersetzte Quelladresse;

übersetzter Quellport;

Sessiontabelleneintrag;

Ablaufzeit;

Rückweg;

Verbindung zum Backend;

getrennte Timeouts je TCP-Abschnitt;

welcher Abschnitt den Reset enthält.

Container und Kubernetes berücksichtigen

Eine TCP-Verbindung kann durch mehrere Netzwerk-Namespaces laufen:

Client
→ Hostport
→ Container-Netzwerk
→ Containersocket

oder:

Client
→ Load Balancer
→ Kubernetes-Service
→ Pod-IP
→ Anwendungscontainer

Zu prüfen sind:

Handshake am externen Endpunkt;

Handshake zum Backend;

Listener im Container oder Pod;

Host- und Containerport;

Service-port und targetPort;

Sidecar- oder Service-Mesh-Verbindung;

NetworkPolicy;

Readiness und EndpointSlices;

Reset innerhalb des Pods;

Reset am Ingress oder Gateway.

Ein erfolgreicher Handshake zum Load Balancer beweist keinen erfolgreichen Handshake zum Backend.

Typische Fehlermeldungen einordnen

Meldung	Mögliche TCP-Einordnung
`Connection refused`	häufig Reset als Antwort auf SYN
`Connection timed out`	Handshake oder Datenübertragung ohne rechtzeitige Antwort
`Connection reset by peer`	gültiger Reset wurde empfangen
`Broken pipe`	Schreiben auf bereits geschlossene Verbindung
`EOF`	Gegenstelle hat den Datenstrom beendet
`Operation timed out`	Frist der Anwendung oder Bibliothek abgelaufen
`No route to host`	Routing- oder lokal gemeldeter Erreichbarkeitsfehler
`Network is unreachable`	keine verwendbare Route
`TLS handshake timeout`	TCP möglicherweise erfolgreich, TLS nicht abgeschlossen
`Read timed out`	Verbindung steht, erwartete Daten fehlen
`Write timed out`	Daten konnten nicht innerhalb der Frist geschrieben werden

Der genaue Wortlaut hängt von Betriebssystem, Programmiersprache, Bibliothek und Anwendung ab.

Hypothese und Gegenbeweis

Beispiel für einen Connect-Timeout:

Hypothese:
Eine Netzwerkfirewall verwirft die SYN-Pakete zum TCP-Port 443.

Erwarteter Befund:
Der Client sendet wiederholt SYN-Pakete.
Der Server empfängt diese SYN-Pakete nicht.
Es wird weder SYN/ACK noch RST empfangen.

Gegenbeweis:
Die Serveraufzeichnung zeigt das eingehende SYN und ein ausgehendes SYN/ACK.

Testmethode:
Zeitgleich begrenzte Paketaufzeichnung auf Client und Server.

Erfolgskriterium:
Der genaue Punkt des Paketverlusts ist eingegrenzt.

Risiko:
Die Aufzeichnung enthält interne Verbindungsdaten und muss geschützt werden.

Beispiel für einen Reset:

Hypothese:
Der Reverse Proxy erzeugt den Reset, weil kein Backend verfügbar ist.

Erwarteter Befund:
Der Client-Handschlag mit dem Proxy ist erfolgreich.
Der Proxy kann keine Verbindung zum Backend aufbauen.
Der Client empfängt anschließend einen Reset.
Das Backend empfängt keinen Verbindungsversuch oder lehnt ihn ab.

Gegenbeweis:
Der Backend-Handschlag ist erfolgreich und der Reset verlässt nachweislich
das Backend.

Testmethode:
Aufzeichnungen und Protokolle an Client, Proxy und Backend korrelieren.

Kontrollierte Maßnahmen

Maßnahme	Voraussetzung	Risiko
Listener starten oder Bindung korrigieren	Reset wegen fehlendem Listener bestätigt	geänderte Erreichbarkeit
Firewallregel korrigieren	Paketverlust an der Firewall nachgewiesen	unbeabsichtigte Freigabe
Rückweg korrigieren	asymmetrischer oder fehlender Rückweg bestätigt	weitere Netze können betroffen sein
NAT-Zuordnung korrigieren	falsche Übersetzung bestätigt	bestehende Sitzungen werden beeinflusst
Proxy-Backend korrigieren	fehlerhafter Backendpfad nachgewiesen	produktiver Datenverkehr wird umgeleitet
Idle-Timeout abstimmen	Sitzungsablauf nach Inaktivität bestätigt	mehr Sitzungszustand und Ressourcenverbrauch
Connection-Pool-Lebensdauer anpassen	Wiederverwendung veralteter Verbindungen bestätigt	mehr neue Verbindungen
Anwendungs-Timeout anpassen	Verarbeitung dauert legitim länger und Ursache ist bekannt	Fehler werden eventuell später erkannt
TCP-Keepalive gezielt konfigurieren	verwaiste Idle-Verbindungen bestätigt	zusätzlicher Netzwerkverkehr
Anwendung korrigieren	`CLOSE-WAIT`, abortives Schließen oder Absturz bestätigt	Dienstneustart oder Deployment erforderlich
Backendkapazität erhöhen	Ressourcenengpass nachgewiesen	Kosten und Betriebsänderung
Protokoll oder Zielport korrigieren	falsches Protokoll beziehungsweise falscher Port bestätigt	Clientkonfiguration ändert sich

Timeouts dürfen nicht pauschal verlängert werden, um Paketverlust, Deadlocks oder überlastete Backends zu verdecken.

Systematischer Diagnoseablauf

Exakte Anwendungsmeldung aufnehmen.

Datum, Uhrzeit und Zeitzone dokumentieren.

Client, Server, Zielname und Zielport bestimmen.

Verwendete IP-Adresse und Adressfamilie erfassen.

Transportprotokoll bestätigen.

Erwarteten Listener auf dem Server prüfen.

Besitzenden Prozess bestimmen.

Lokalen TCP-Test am Server durchführen.

TCP-Test vom betroffenen Client durchführen.

Socketzustand während des Versuchs beobachten.

Prüfen, ob ein SYN erzeugt wird.

Prüfen, ob der Server das SYN empfängt.

Prüfen, ob SYN/ACK oder RST zurückgesendet wird.

Prüfen, ob das abschließende ACK ankommt.

Bei erfolgreichem Handshake Anwendungsdaten prüfen.

Connect- und Anwendungs-Timeout unterscheiden.

FIN und RST unterscheiden.

Reset-Richtung und Reset-Zeitpunkt bestimmen.

Client-, Server- und Zwischenprotokolle korrelieren.

Retransmissions und Duplicate ACKs auswerten.

Captureverlust und Offloading berücksichtigen.

NAT-, Firewall- und Proxyzustand prüfen.

Load Balancer und Backendverbindung getrennt prüfen.

Container- und Netzwerk-Namespace berücksichtigen.

Idle-Phase und Timeoutwerte dokumentieren.

Frische und wiederverwendete Verbindung vergleichen.

Hypothese und Gegenbeweis formulieren.

Genau eine kontrollierte Maßnahme durchführen.

Identischen Verbindungsversuch wiederholen.

Anwendungsprotokoll vollständig verifizieren.

Weitere repräsentative Clients prüfen.

Temporäre Filter und Aufzeichnungen entfernen.

Ursache, Maßnahme und Prävention dokumentieren.

Befundmatrix

Befund	Mögliche Einordnung	Nächster Nachweis
kein SYN sichtbar	Anwendung, DNS oder lokaler Socketaufruf	Anwendungstrace und Zieladresse
SYN wiederholt, keine Antwort	Drop, Routing oder Rückweg	serverseitige Aufzeichnung
SYN erreicht Server nicht	Netzpfad vor dem Server	Zwischenpunkte und Firewalllogs
SYN erreicht Server, kein SYN/ACK	lokaler Filter, kein Listener oder Überlastung	Socketliste und Servertrace
SYN wird mit RST beantwortet	aktive Ablehnung	Reset-Erzeuger und Listener prüfen
SYN/ACK verlässt Server, erreicht Client nicht	Rückweg oder Filterung	Client- und Firewallaufzeichnung
SYN/ACK wird wiederholt	abschließendes ACK fehlt	Clientaufzeichnung
Handshake vollständig	TCP-Connect funktioniert	Anwendungsprotokoll prüfen
Handshake vollständig, keine Nutzdaten	Anwendung wartet oder startet Anfrage nicht	Anwendungstrace
Anfrage gesendet, keine Antwort	Backend oder Anwendung langsam	Server- und Backendprotokolle
RST direkt nach Handshake	Anwendung oder Zwischenkomponente lehnt ab	Reset-Sender und Logs
RST nach Anfrage	Protokoll-, Anwendungs- oder Sicherheitsfehler	Daten vor dem Reset auswerten
RST nach langer Inaktivität	Idle-Timeout oder veralteter Socket	Timeoutwerte und frische Verbindung
FIN nach Anfrage	kontrollierte Schließung	Anwendungsergebnis prüfen
viele `CLOSE-WAIT`	lokale Anwendung schließt nicht	Prozess- und Threadanalyse
viele `TIME-WAIT`	viele kurzlebige Verbindungen	Verbindungsrate und Pooling
viele `SYN-SENT`	Ziele antworten nicht	Ziel- und Pfadvergleich
viele `SYN-RECEIVED`	Handshake bleibt unvollständig	Serverwarteschlange und Clientpfad
Retransmissions nur in einer Capturedatei	Captureverlust oder Offloading möglich	zweiter Aufzeichnungspunkt
frische Verbindung funktioniert	alte Verbindung fehlerhaft	Idle- und Poolingverhalten
Porttest funktioniert, TLS scheitert	TCP funktioniert, TLS fehlerhaft	TLS-Handshake analysieren
nur große Übertragung stockt	Verlust, Window oder MTU möglich	Folgeseite zu Retransmissions und MTU
nur ein Backend erzeugt Resets	Backend- oder Pfadproblem	direkte Backendtests
Reset am Client, nicht am Server	Zwischenkomponente wahrscheinlich	Firewall-, Proxy- und LB-Protokolle

Typische Diagnosefehler

Anwendungstimeout und TCP-Timeout gleichsetzen.

Einen erfolgreichen Ping als TCP-Nachweis verwenden.

Einen offenen TCP-Port als vollständigen Anwendungsnachweis bewerten.

Nur Test-NetConnection oder nc verwenden.

DNS-Zeit und TCP-Verbindungszeit vermischen.

Nur auf dem Client aufzeichnen.

Aus einer fehlenden Clientantwort schließen, dass der Server nichts gesendet hat.

Aus der RST-Quelladresse sicher auf den Erzeuger schließen.

Firewall, Proxy oder Load Balancer als Reset-Erzeuger ignorieren.

FIN und RST gleich behandeln.

CLOSE-WAIT durch Änderung von TCP-Timern beheben wollen.

TIME-WAIT pauschal als Fehler bewerten.

Wiederholungen ohne Sequenznummern und ACKs auswerten.

Duplicate ACKs automatisch als Paketverlust bewerten.

Wireshark-Analysemarkierungen als echte TCP-Flags interpretieren.

Checksum-Offloading ignorieren.

Captureverlust am Analysesystem ignorieren.

IPv4 und IPv6 nicht getrennt prüfen.

Client- und Serverzeit nicht synchronisieren.

NAT-Adressen und ursprüngliche Adressen verwechseln.

Proxyverbindung und Backendverbindung als eine einzige TCP-Verbindung behandeln.

Host-, Container- und Pod-Namespace verwechseln.

Veraltete Verbindung aus einem Pool nicht berücksichtigen.

Idle-Timeout ohne Messung vermuten.

Timeout pauschal erhöhen.

TCP Keepalive als Nachweis der Anwendungsgesundheit betrachten.

Firewall vollständig deaktivieren.

Prozess vorsorglich beenden.

Server vorsorglich neu starten.

mehrere Einstellungen gleichzeitig verändern.

Paketaufzeichnung ohne Filter laufen lassen.

sensible Capturedateien ungeschützt speichern.

nach der Maßnahme nur einen einzelnen erfolgreichen Versuch prüfen.

Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Zielname wird zur richtigen Adresse aufgelöst;

richtige IPv4- oder IPv6-Adresse wird verwendet;

erwarteter TCP-Listener ist vorhanden;

richtiger Prozess besitzt den Listener;

SYN erreicht den Server;

SYN/ACK erreicht den Client;

abschließendes ACK erreicht den Server;

TCP-Verbindung erreicht ESTABLISHED;

keine unerwarteten Reset-Segmente entstehen;

Daten werden in beiden Richtungen übertragen;

ACKs bestätigen die erwarteten Sequenzbereiche;

Retransmissionsrate entspricht der Baseline;

Anwendung antwortet innerhalb der vorgesehenen Frist;

TLS funktioniert, sofern vorgesehen;

Proxy erreicht sein Backend;

Load Balancer verwendet gesunde Backends;

NAT- und Firewallzustand bleiben während der Sitzung bestehen;

wiederverwendete Verbindungen funktionieren;

Verhalten nach repräsentativer Inaktivität ist korrekt;

Verbindung wird kontrolliert beendet;

keine dauerhaft wachsenden CLOSE-WAIT-Bestände entstehen;

TIME-WAIT-Bestand ist zur Arbeitslast plausibel;

mehrere aufeinanderfolgende Versuche funktionieren;

weitere repräsentative Clients funktionieren;

temporäre Capturefilter wurden entfernt;

Aufzeichnungen wurden geschützt oder kontrolliert gelöscht;

Ursache, Maßnahme und Prävention wurden dokumentiert.

Ein einzelner erfolgreicher Three-Way Handshake ist keine vollständige Verifikation der Anwendung.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Zeitpunkt:
<Datum, Uhrzeit und Zeitzone>

Client:
<Hostname und IP-Adresse>

Server:
<Hostname und IP-Adresse>

Zielname:
<FQDN>

Zielport:
<TCP-Port>

Adressfamilie:
<IPv4 oder IPv6>

Anwendung:
<Client- und Serveranwendung>

Exakte Fehlermeldung:
<Wortlaut>

Verwendete Quelladresse:
<Adresse und Port>

Verwendete Zieladresse:
<Adresse und Port>

Listener:
<Adresse, Port, Prozess und PID>

Handshake-Befund:
<SYN, SYN/ACK, ACK, RST oder fehlende Antwort>

Socketzustände:
<SYN-SENT, SYN-RECEIVED, ESTABLISHED und weitere>

Anwendungsdaten:
<gesendet, empfangen oder nicht sichtbar>

Timeoutart:
<DNS, Connect, TCP, TLS, Anwendung, Proxy oder Idle>

Timeoutdauer:
<gemessene Dauer>

Reset-Absender:
<nachgewiesener oder vermuteter Erzeuger>

Nachweis des Reset-Absenders:
<Client-, Server- und Zwischenaufzeichnung>

Retransmissions:
<Anzahl und Richtung>

FIN-Befund:
<kontrollierter Abbau oder fehlendes FIN>

Zwischenkomponenten:
<Firewall, NAT, Proxy, Load Balancer oder Service Mesh>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

Durchgeführte Maßnahme:
<genau eine kontrollierte Änderung>

Risiko und Rückweg:
<Beschreibung>

Verifikation:
<Handshake, Anwendungstest und weitere Systeme>

Prävention:
<Monitoring oder Konfigurationsverbesserung>

Checkliste

Schnellreferenz

Aufgabe	Befehl oder Filter
Windows-TCP-Verbindungen	`Get-NetTCPConnection`
Windows `SYN-SENT`	`Get-NetTCPConnection -State SynSent`
Windows `SYN-RECEIVED`	`Get-NetTCPConnection -State SynReceived`
Windows `ESTABLISHED`	`Get-NetTCPConnection -State Established`
Windows `CLOSE-WAIT`	`Get-NetTCPConnection -State CloseWait`
Windows `TIME-WAIT`	`Get-NetTCPConnection -State TimeWait`
Windows-TCP-Test	`Test-NetConnection -ComputerName <Ziel> -Port <Port> -InformationLevel Detailed`
Windows-TCP-Statistik	`netstat -s -p tcp`
Windows-Paketmonitor	`pktmon`
Linux-TCP-Sockets	`ss -tan`
Linux-TCP-Details	`sudo ss -tin`
Linux `SYN-SENT`	`ss -tan state syn-sent`
Linux `SYN-RECEIVED`	`ss -tan state syn-recv`
Linux `ESTABLISHED`	`ss -tan state established`
Linux `CLOSE-WAIT`	`ss -tan state close-wait`
Linux `TIME-WAIT`	`ss -tan state time-wait`
Linux-TCP-Zähler	`nstat -az`
macOS-TCP-Sockets	`netstat -anv -p tcp`
macOS-Prozesszuordnung	`sudo lsof -nP -iTCP`
macOS-Liveansicht	`nettop -m tcp`
TCP-Porttest	`nc -vz <Ziel> <Port>`
HTTP-/HTTPS-Test	`curl --connect-timeout 5 --max-time 15 -v <URL>`
Linux-Aufzeichnung	`sudo tcpdump -ni any 'tcp port <Port>' -c 200`
macOS-Aufzeichnung	`sudo tcpdump -ni <Schnittstelle> 'tcp port <Port>' -c 200`
Wireshark: Port	`tcp.port == <Port>`
Wireshark: initiales SYN	`tcp.flags.syn == 1 && tcp.flags.ack == 0`
Wireshark: SYN/ACK	`tcp.flags.syn == 1 && tcp.flags.ack == 1`
Wireshark: Reset	`tcp.flags.reset == 1`
Wireshark: FIN	`tcp.flags.fin == 1`
Wireshark: Retransmission	`tcp.analysis.retransmission`
Wireshark: Fast Retransmit	`tcp.analysis.fast_retransmission`
Wireshark: Duplicate ACK	`tcp.analysis.duplicate_ack`
Wireshark: TCP-Stream	`tcp.stream == <Nummer>`

Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen

Stop-Process
taskkill
Stop-Service
Restart-Service
netsh int ip reset
netsh winsock reset
Set-NetFirewallRule
New-NetFirewallRule
Deaktivieren der Windows-Firewall
kill
kill -9
systemctl stop
systemctl restart
sysctl -w
iptables
nft
ufw disable
firewall-cmd --permanent
docker restart
docker stop
kubectl delete
kubectl rollout restart
pauschales Erhöhen aller Timeouts
aggressives Verkürzen von TIME-WAIT
unkontrolliertes Aktivieren oder Ändern von TCP Keepalive
Deaktivieren von TCP-Offloading ohne Vergleichstest
Neustart von Firewall, Proxy oder Load Balancer

Ein Neustart kann TCP-Zustände, Sessiontabellen und den für die Diagnose wichtigen Ausgangszustand zerstören.

Quellen

Standards