9.2 TCP-Handshake, Timeouts und TCP Reset

Ziel dieser Seite

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

Nach der Bearbeitung muss unterschieden werden können:

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:

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:

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:

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:

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:

  1. Der Client sendet ein Segment mit SYN.
  2. Der Server bestätigt das Client-SYN und sendet sein eigenes SYN mit SYN, ACK.
  3. 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:

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

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:

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:

Dieser Befund beweist nicht:

SYN ohne Antwort

Typischer Paketbefund:

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

Mögliche Ursachen:

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:

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:

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:

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:

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

Entscheidend sind:

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:

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

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:

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

TCP-Retransmissions richtig einordnen

Eine als Retransmission markierte Übertragung kann bedeuten:

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:

Deshalb gilt:

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

Zu vergleichen sind:

TCP besitzt keine Anwendungs-Lebendigkeitsprüfung

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

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

Mögliche zusätzliche Mechanismen sind:

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:

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:

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:

Benötigter Nachweis:

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:

Typische Ursachen eines TCP Reset

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:

Nächster Nachweis:

Reset unmittelbar nach erfolgreichem Handshake

Paketfolge:

SYN
SYN, ACK
ACK
RST

Mögliche Ursachen:

Zu prüfen sind:

Reset nach Übertragung einer Anfrage

Paketfolge:

Handshake erfolgreich
Client sendet Anfrage
Server oder Zwischenkomponente sendet RST

Mögliche Ursachen:

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:

Zu vergleichen sind:

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:

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:

Belastbarer Nachweis:

  1. Aufzeichnung am Client.
  2. Aufzeichnung am Server.
  3. Zeitliche Synchronisation beider Systeme.
  4. Vergleich derselben TCP-Verbindung.
  5. Prüfung, ob der Reset den Server verlässt.
  6. Prüfung, ob der Server den Reset überhaupt empfängt.
  7. 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:

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:

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:

Zu prüfen sind:

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:

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:

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:

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:

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:

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:

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:

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

  1. Exakte Anwendungsmeldung aufnehmen.
  2. Datum, Uhrzeit und Zeitzone dokumentieren.
  3. Client, Server, Zielname und Zielport bestimmen.
  4. Verwendete IP-Adresse und Adressfamilie erfassen.
  5. Transportprotokoll bestätigen.
  6. Erwarteten Listener auf dem Server prüfen.
  7. Besitzenden Prozess bestimmen.
  8. Lokalen TCP-Test am Server durchführen.
  9. TCP-Test vom betroffenen Client durchführen.
  10. Socketzustand während des Versuchs beobachten.
  11. Prüfen, ob ein SYN erzeugt wird.
  12. Prüfen, ob der Server das SYN empfängt.
  13. Prüfen, ob SYN/ACK oder RST zurückgesendet wird.
  14. Prüfen, ob das abschließende ACK ankommt.
  15. Bei erfolgreichem Handshake Anwendungsdaten prüfen.
  16. Connect- und Anwendungs-Timeout unterscheiden.
  17. FIN und RST unterscheiden.
  18. Reset-Richtung und Reset-Zeitpunkt bestimmen.
  19. Client-, Server- und Zwischenprotokolle korrelieren.
  20. Retransmissions und Duplicate ACKs auswerten.
  21. Captureverlust und Offloading berücksichtigen.
  22. NAT-, Firewall- und Proxyzustand prüfen.
  23. Load Balancer und Backendverbindung getrennt prüfen.
  24. Container- und Netzwerk-Namespace berücksichtigen.
  25. Idle-Phase und Timeoutwerte dokumentieren.
  26. Frische und wiederverwendete Verbindung vergleichen.
  27. Hypothese und Gegenbeweis formulieren.
  28. Genau eine kontrollierte Maßnahme durchführen.
  29. Identischen Verbindungsversuch wiederholen.
  30. Anwendungsprotokoll vollständig verifizieren.
  31. Weitere repräsentative Clients prüfen.
  32. Temporäre Filter und Aufzeichnungen entfernen.
  33. 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

Verifikation

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

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

Offizielle Microsoft-Dokumentation

Offizielle Linux-Dokumentation

Offizielle Wireshark-Dokumentation

Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet.

Revision #1
Created 2 August 2026 16:14:00 by Admin
Updated 2 August 2026 16:41:40 by Admin