TCP: Zustände, Datenfluss und Diagnose

TCP verwandelt den unzuverlässigen Pakettransport von IP in einen geordneten, bidirektionalen Datenstrom für Anwendungen. Die Anwendung schreibt Bytes in einen Socket; TCP segmentiert sie, nummeriert ihre Position, bestätigt empfangene Bereiche und überträgt Lücken erneut. SMTP, IMAP, POP3, LDAP und HTTPS bauen auf dieser Zusage auf. Wenn eine solche Anwendung «hängt», muss der Administrator daher zuerst unterscheiden, ob noch TCP auf eine Bestätigung wartet oder bereits das Anwendungsprotokoll blockiert.

Der Artikel folgt dem Lebenslauf einer Verbindung: Socket und Listener, Drei-Wege-Handshake, Datenübertragung, Fluss- und Staukontrolle, Abbau und TIME-WAIT. Aus diesem normalen Ablauf werden danach Diagnose, Kapazitätsplanung, Monitoring und Härtung abgeleitet.

TCP kennt jedoch weder Nachrichten noch Benutzer, Zertifikate oder Mailadressen. Es bewahrt auch keine Anwendungsgrenzen: Zwei aufeinanderfolgende Schreiboperationen können in einem Segment zusammengefasst oder auf mehrere Segmente verteilt werden. Ein erfolgreicher TCP-Handshake beweist deshalb nur, dass zwei TCP-Endpunkte eine Verbindung aufbauen konnten. Ob danach ein SMTP-Banner erscheint, TLS ausgehandelt wird oder eine LDAP-Bindung gelingt, entscheidet die darüberliegende Anwendung.

Für Administratoren ist TCP weniger als Schichtenmodell denn als Zustands- und Signalsystem relevant. SYN, ACK, FIN und RST zeigen, an welchem Übergabepunkt eine Verbindung scheitert. Socketzustände, Retransmissions, Empfangsfenster und Timer erklären, weshalb ein Dienst erreichbar, aber langsam oder scheinbar eingefroren sein kann.

Die Erklärung folgt einer TCP-Verbindung vom ersten SYN über den geordneten Bytestrom bis zu Beendigung oder Reset. Fenster, Retransmits, Überlastung und Diagnose werden an den jeweiligen Phasen erklärt.

Socket- und Verbindungsmodell

Bevor Pakete fliessen, bindet eine Anwendung einen Socket an Adresse und Port. Ein Server lauscht beispielsweise auf TCP 25; jede angenommene Verbindung wird anschliessend durch Quelladresse, Quellport, Zieladresse und Zielport eindeutig. Darum können tausende Clients denselben Listener verwenden, solange sich mindestens ihre Quelladresse oder ihr ephemerer Port unterscheidet. Für die Diagnose reicht «Port 25» folglich nicht: Benötigt wird immer das vollständige Verbindungspaar (RFC 9293, Abschnitt 3.1).

Auf einem Server bindet ein Prozess einen Socket an eine lokale Adresse und versetzt ihn in den Zustand LISTEN. Die Wahl der Bind-Adresse ist betrieblich wichtig:

Der Serverport ist meist durch eine IANA-Registrierung vorgegeben; der Client wählt gewöhnlich einen ephemeren Port aus dem vom Betriebssystem verwalteten Bereich. Firewalls, NAT-Gateways und Load Balancer müssen daher nicht nur den bekannten Zielport, sondern den vollständigen Rückweg zum dynamischen Quellport zulassen.

TCP Control Block

Für jede Verbindung hält der TCP-Stack einen Transmission Control Block (TCB). Darin stehen unter anderem Zustand, lokale und entfernte Sockets, Sende- und Empfangssequenz, Fenster, Timer und Sicherheitsparameter. Der TCB ist der Grund, weshalb eine Verbindung zustandsbehaftet ist und weshalb Load Balancer oder Firewalls mit symmetrischem Rückweg arbeiten müssen: Erreicht ein Antwortsegment einen anderen Knoten ohne passenden Zustand, kann dieser es verwerfen oder mit RST beantworten.

Verbindungsaufbau, Datentransfer und Abbau

Mit dem aktiven Öffnen beginnt der sichtbare Verbindungszustand. Der Client sendet SYN samt initialer Sequenznummer, der Listener antwortet mit SYN+ACK und eigener Sequenznummer, danach bestätigt der Client mit ACK. Bereits diese drei Segmente handeln Optionen wie Maximum Segment Size, Window Scale, Selective Acknowledgment und Timestamps aus. Fehlt ein Paket, kommt die Antwort über einen anderen Weg oder verändert ein Zwischenprodukt die Optionen, zeigt der Handshake bereits, wo sich Erreichbarkeit und spätere Leistung trennen.

Nach dem Handshake befindet sich die Verbindung in ESTABLISHED. Beide Seiten können unabhängig voneinander Daten senden und ihre Senderichtung mit FIN schliessen. Ein ordentlicher Abbau benötigt deshalb typischerweise je ein FIN und ACK pro Richtung. Die Seite, die den letzten ACK sendet, verbleibt in TIME-WAIT, damit verspätete Segmente einer alten Verbindung nicht in eine neue Verbindung mit demselben Socketpaar geraten (RFC 9293, Abschnitte 3.3.2 und 3.6).

Ein RST ist kein geordneter Abschluss. Es bricht die Verbindung ab und verwirft ausstehende Zustände. Beim Verbindungsaufbau bedeutet ein gültiges RST gewöhnlich, dass der Zielhost erreichbar ist, aber der Socket nicht akzeptiert wird. Nach bereits übertragenen Daten kann ein RST von der Anwendung, vom Betriebssystem oder von einem zustandsbehafteten Zwischenknoten stammen. Die Position des RST im Paketmitschnitt ist daher wichtiger als die allgemeine Fehlermeldung «connection reset».

Die Zustände als Betriebsindikatoren

Die Zustandsnamen sind in RFC 9293 definiert. Eine hohe Anzahl ist kein Fehler an sich. Entscheidend sind Alter, Wachstumsrate, betroffene Gegenstellen und die Relation zu Verbindungsrate, Dateideskriptoren, ephemerem Portbereich und Anwendungslimits.

Sequenznummern, ACKs und Retransmission

Nach dem Handshake zählt TCP den Datenstrom byteweise. Die Sequenznummer bezeichnet das erste Byte eines Segments; das ACK nennt das nächste erwartete Byte und bestätigt damit alles davor. Pakete dürfen verloren gehen, doppelt ankommen oder ihre Reihenfolge wechseln. Der Empfänger kann sie puffern, gibt der Anwendung aber erst einen lückenlosen Strom weiter. Genau deshalb kann ein einziger fehlender Bereich eine scheinbar ruhige Anwendung blockieren, obwohl spätere Pakete bereits am Host angekommen sind.

Geht ein Segment oder sein ACK verloren, kann der Sender den fehlenden Bereich auf zwei Wegen erkennen:

1. Retransmission Timeout (RTO): Aus geglätteter Round-Trip Time und deren Variation wird ein Timer abgeleitet. Läuft er ab, wird das älteste unbestätigte Segment erneut gesendet. RFC 6298 definiert Berechnung, Mindestwerte und exponentielles Backoff.
2. Fast Retransmit: Mehrere doppelte ACKs zeigen eine Lücke im Datenstrom an. Der Sender kann den mutmasslich verlorenen Bereich erneut senden, ohne auf den RTO zu warten (RFC 5681).

Eine Retransmission beweist nicht automatisch Paketverlust im Netzwerk. Ein Mitschnitt kann auf nur einer Seite entstanden sein, Pakete durch Capture-Drops fehlen oder eine Spurious Retransmission zeigen. Wireshark kennzeichnet seine TCP-Analyse ausdrücklich als aus dem beobachteten Paketstrom abgeleitete Interpretation (Wireshark User’s Guide – TCP Analysis). Für eine belastbare Aussage sind daher möglichst Mitschnitte an Client, Server und einem relevanten Zwischenpunkt zu korrelieren.

Flusskontrolle und Staukontrolle

Zuverlässigkeit allein verhindert noch nicht, dass ein schneller Sender Empfänger oder Netz überlastet. TCP begrenzt die gleichzeitig unbestätigten Bytes deshalb mit zwei Fenstern, von denen am Ende das kleinere wirkt:

• Das Empfangsfenster rwnd schützt den Empfänger. Es beschreibt den aktuell verfügbaren Puffer. Meldet der Empfänger ein Zero Window, muss der Sender bis auf periodische Window Probes warten. Ein dauerhaftes Zero Window ist häufig kein Netzwerkproblem, sondern bedeutet, dass die empfangende Anwendung ihre Socketdaten nicht schnell genug liest.
• Das Congestion Window cwnd schützt den Pfad. Es wird lokal vom Sender geführt und anhand von Bestätigungen und Verlustsignalen angepasst. RFC 5681 beschreibt Slow Start, Congestion Avoidance, Fast Retransmit und Fast Recovery.

Wirksam ist grob das kleinere aus rwnd und cwnd. Hohe Bandbreite allein garantiert deshalb keinen hohen Durchsatz. Auf einem Pfad mit grossem Bandbreite-Latenz-Produkt muss genügend unbestätigte Datenmenge erlaubt sein. Die Window-Scale-Option erweitert das 16-Bit-Fenster; Timestamps unterstützen unter anderem RTT-Messung und den Schutz vor alten Sequenznummern (RFC 7323). Beide Optionen werden im Handshake ausgehandelt und lassen sich später nicht für dieselbe Verbindung nachschalten.

Für kurze SMTP-Transaktionen dominiert häufig die Zahl der Round Trips: TCP-Handshake, optionaler TLS-Handshake und mehrere Protokollantworten. Für grosse Anhänge und Replikationsströme werden zusätzlich RTT, Verlust, Fenster, Offloading und Congestion-Control-Algorithmus relevant. Ein Durchsatzproblem ist deshalb erst dann «Bandbreite», wenn Handshakezeit, Applikationspausen, Zero Windows und Retransmissions ausgeschlossen sind.

Timer, Keepalives und Idle Timeouts

Wo keine sofortige Antwort kommt, entscheiden Timer über den nächsten Schritt. Der Retransmission Timeout löst Datenwiederholungen aus, der Persist Timer hält eine Verbindung trotz Zero Window aufrecht, und TIME-WAIT verhindert, dass alte Segmente in eine neue Verbindung geraten. Betriebssysteme und Anwendungen ergänzen Keepalive sowie User Timeout. Wer nur «Timeout» protokolliert, verliert diese Unterschiede und damit die eigentliche Fehlerursache.

TCP-Keepalives sind standardmässig oft deaktiviert oder beginnen erst nach langen Leerlaufzeiten. Sie ersetzen keinen anwendungsseitigen Health Check. Ein erfolgreicher Keepalive sagt nur, dass der TCP-Peer antwortet; er beweist nicht, dass ein SMTP-Worker Nachrichten verarbeitet oder eine LDAP-Abfrage bedienen kann. Umgekehrt trennen Firewalls und Load Balancer inaktive Verbindungen häufig früher als die Endsysteme. Dann bleibt auf einer Seite ein scheinbar gültiger Socket, bis der nächste Datenversuch einen Timeout oder RST auslöst.

Bei langlebigen IMAP-, LDAP-Pool- oder API-Verbindungen müssen deshalb vier Werte zueinander passen: Anwendungs-Idle-Timeout, TCP-Keepalive-Intervall, Idle-Timeout jedes Zwischenknotens und Wiederverbindungslogik des Clients. Der kleinste unangekündigte Timeout bestimmt das beobachtete Verhalten.

Diagnose vom Socket bis zum Paket

Die Fehlersuche wird belastbar, sobald sie dieselbe Verbindung beschreibt wie die Anwendung: Quellhost, Zielname, aufgelöste Adresse, Zielport, Zeitpunkt und erwartetes Protokoll. Ein Ping ersetzt diese Angaben nicht. ICMP kann gesperrt sein, obwohl TCP funktioniert; umgekehrt beweist eine Echo-Antwort weder einen Listener noch den Zustand einer Stateful Firewall.

Erreichbarkeit und Listener

Test-NetConnection -ComputerName mail.example.ch -Port 25 -InformationLevel Detailed
Get-NetTCPConnection -State Listen -LocalPort 25 |
Select-Object LocalAddress, LocalPort, OwningProcess

nc -vz -w 5 mail.example.ch 25
sudo ss -ltnp ‘sport = :25’

Test-NetConnection kombiniert unter Windows Namensauflösung, Zieladresse, Porttest und optionale Routendiagnose. Unter Unix öffnet nc gezielt TCP- oder UDP-Verbindungen; telnet kann ebenfalls einen TCP-Port öffnen, verarbeitet dabei aber das Telnet-Protokoll und ist kein vollständig transparenter Ersatz. ss liest Socketinformationen des Linux-Kernels und kann Zustände, Timer, Queues und Prozesse filtern. Ein erfolgreicher Connect-Test öffnet und schliesst eine echte TCP-Verbindung; auf produktiven Diensten sollte er deshalb gezielt und nicht als hochfrequenter Portscan eingesetzt werden.

Paketmitschnitt und Zustandsfilter

pktmon filter remove
pktmon filter add MailTcp -t TCP -p 25
pktmon start --capture --pkt-size 0 --file-name C:\Temp\mail-tcp.etl
# Problem reproduzieren, danach:
pktmon stop
pktmon etl2pcap C:\Temp\mail-tcp.etl --out C:\Temp\mail-tcp.pcapng

sudo tcpdump -i any -nn -s 0 -w /tmp/mail-tcp.pcap \
  'host 192.0.2.25 and tcp port 25'
ss -tin state established ’( dport = :25 or sport = :25 )’

Pktmon erfasst Pakete im Windows-Netzwerkstack und kann sein ETL-Format in PCAPNG umwandeln. tcpdump verwendet unter Unix einen Capture-Ausdruck und schreibt hier eine PCAP-Datei für die spätere Analyse. Ein vollständiger Mitschnitt behält Payload und kann Zugangsdaten oder Nachrichteninhalte enthalten. Er gehört wie ein Mail-Export behandelt: eng filtern, kurz erfassen, geschützt speichern und nach der Analyse löschen. Bei TLS bleiben Adressen, Ports, Paketgrössen, Timing, Handshake-Metadaten und TCP-Signale sichtbar, nicht jedoch der verschlüsselte Anwendungsinhalt.

Signalbild und wahrscheinlichster Übergabepunkt

Kapazität und Ausfallbereiche

Nach der Einzelverbindung folgt die Kapazitätsfrage. Jeder Socket belegt Zustand im Client und Server, häufig zusätzlich in Firewall, NAT, Load Balancer oder Proxy. Die tragfähige Verbindungszahl wird daher nicht allein von CPU oder Bandbreite bestimmt, sondern von der kleinsten Tabelle, Queue oder Portmenge entlang des realen Pfads.

Administratoren sollten mindestens folgende Ressourcen auseinanderhalten:

• Listen-Backlog und SYN-Backlog: begrenzen vollständig beziehungsweise halb geöffnete Verbindungen;
• Dateideskriptoren und Prozesslimits: ein freier Port genügt nicht, wenn die Anwendung keinen Socket mehr annehmen kann;
• ephemere Ports: ausgehende Relays und Proxies können denselben Zielsocket nur mit unterschiedlichen lokalen Sockets parallel erreichen;
• NAT- und Conntrack-Tabellen: halten eigene Timer und können trotz freier Endsystemressourcen erschöpfen;
• Arbeitsspeicher pro Socket: Sende-/Empfangspuffer, TLS-Zustand und Anwendungskontext vervielfachen sich mit der Verbindungszahl;
• TIME-WAIT-Verteilung: die aktiv schliessende Seite trägt diesen Zustand; Architekturentscheidungen verschieben daher die Last;
• Load-Balancer-Affinität und Rückweg: zustandsbehaftete Geräte müssen beide Richtungen derselben Verbindung sehen.

Blindes Verkürzen von TIME-WAIT, Keepalive- oder Retransmissionstimern behebt selten die Ursache. Es verändert Protokollschutz und Fehlersemantik. Zuerst sind Verbindungsrate, Haltezeit, Vier-Tupel-Verteilung und die tatsächlich erschöpfte Tabelle zu messen.

Monitoring für Messaging-Umgebungen

Aus diesen Zuständen ergibt sich das Monitoring. Interfaceauslastung allein übersieht langsame Handshakes, Retransmits, Reset-Stürme und einen Empfänger mit geschlossenem Fenster. Ein brauchbares Dashboard verbindet daher Host-, Netz- und Anwendungssicht und stellt mindestens folgende Zeitreihen nebeneinander:

Synthetische Porttests sollten mit einem Protokolltest gekoppelt werden. Für SMTP bedeutet das: TCP-Connect, Banner, EHLO, optional StartTLS und eine kontrollierte Transaktion sind getrennte Messpunkte. Nur so bleibt erkennbar, ob Netzpfad, TLS oder Mailanwendung die Latenz verursacht.

Sicherheit und Härtung

TCP liefert Reihenfolge und Fehlerkorrektur, aber weder Vertraulichkeit noch eine kryptografische Identität. Anwendungen ergänzen dafür meist TLS, Netze gegebenenfalls IPsec und spezielle TCP-Verbindungen TCP-AO. Sequenznummern erschweren zwar blindes Einschleusen, ersetzen aber keine Authentisierung. Härtung muss zusätzlich SYN-Floods, gefälschte Resets, zu grosse Warteschlangen und missbrauchbare Listener berücksichtigen (RFC 9293, Abschnitt 7).

Für exponierte Messaging-Dienste sind folgende Kontrollen relevant:

• nur tatsächlich benötigte Listener und Adressfamilien veröffentlichen;
• Server- und Clientrollen in Firewalls getrennt modellieren, statt pauschal «TCP erlaubt» zu definieren;
• SYN-Backlog, SYN-Cookies und Verbindungsraten beobachten, bevor harte Rate Limits legitime Mailserver treffen;
• Proxy Protocol nur zwischen explizit vertrauenswürdigen Peers akzeptieren;
• TCP- und TLS-Terminierung dokumentieren, damit Quell-IP, Timeout und RST-Verantwortung nachvollziehbar bleiben;
• Paketmitschnitte und Socketdiagnosen als potenziell sensible Betriebsdaten schützen;
• unnötige Middlebox-Manipulation an MSS, Optionen und Idle Timern vermeiden und jede notwendige Abweichung testen.

Technische Geschichte

Die heute selbstverständliche Trennung zwischen IP und TCP entstand erst während der frühen Internetentwicklung. RFC 675 beschrieb 1974 noch ein gemeinsames Internet Transmission Control Program. Die spätere Aufteilung gab IP den paketvermittelten Transport zwischen Netzen und TCP die zuverlässige Ende-zu-Ende-Sitzung. RFC 793 standardisierte dieses TCP 1981.

Die Implementierungen entwickelten sich parallel weiter: Selective Acknowledgment, Explicit Congestion Notification, moderne Congestion-Control-Algorithmen, TCP Fast Open und Betriebssystem-Offloading erweitern den Kern. Für die Fehlersuche bleibt dennoch das ursprüngliche Modell aus Socketpaar, Sequenzraum, Fenstern, Zuständen und Timern tragfähig.