TCP-Verbindungen: Handshake, Retransmission-Timer und Keep-Alives

Worum es geht

Der RFC 9293 beschreibt den Drei-Wege-Handshake: Der Client sendet ein SYN, der Server antwortet mit SYN-ACK und wechselt in den Zustand SYN-RECEIVED, das ACK des Clients schliesst die Verbindung ab. Jedes Segment, das Daten trägt, wird bestätigt; trifft die Bestätigung nicht ein, bevor das Retransmission-Timeout (RTO) abläuft, wird das Segment erneut gesendet. Der RFC 6298 legt fest, wie das RTO aus gemessenen Umlaufzeiten berechnet wird, mit einem Anfangswert von 1 Sekunde vor jeder Messung, und wie es nach jedem Ablauf verdoppelt ("Backoff") wird. Der RFC erlaubt Keep-Alives, verlangt sie aber nicht: Prüfsonden, die auf einer inaktiven Verbindung gesendet werden, mit einem Standardintervall, das nicht weniger als zwei Stunden betragen darf.

Warum es wichtig ist

Die Timer erklären die meisten Meldungen der Art „warum hing das so lange". Laut tcp(7) wiederholt Linux ein anfängliches SYN tcp_syn_retries-mal (Standard 6, rund 127 Sekunden), bevor ein Verbindungsaufbau fehlschlägt, und wiederholt Daten in einer bestehenden Verbindung tcp_retries2-mal (Standard 15, rund 13 bis 30 Minuten), bevor aufgegeben wird. Keep-Alives werden nur gesendet, wenn beim Socket SO_KEEPALIVE gesetzt ist; die Standardwerte sind tcp_keepalive_time 7200 Sekunden, danach 9 Prüfsonden im Abstand von 75 Sekunden. Ein Server, dessen Gegenstelle ohne FIN oder RST verschwunden ist, hält die Verbindung – und damit deren Speicher und Dateideskriptor – deshalb lange offen.

So wird es angewendet

• Auf Anwendungsebene Timeouts für Verbindungsaufbau, Lesen und Schreiben setzen; sich nicht darauf verlassen, dass TCP tote Gegenstellen schnell erkennt.
• Bei langlebigen Verbindungen (Datenbank-Pools, Message-Broker, Tunnel) Keep-Alive aktivieren und die Inaktivitätszeit pro Socket senken (TCP_KEEPIDLE, TCP_KEEPINTVL, TCP_KEEPCNT in tcp(7)) statt systemweit.
• TCP_USER_TIMEOUT verwenden, wo die Bibliothek es anbietet: Es begrenzt, wie lange unbestätigte Daten ausstehen dürfen, bevor die Verbindung geschlossen wird.
• Zur Diagnose ss -tin für Retransmit-Zähler und RTO-Werte heranziehen, sowie den Verbindungszustand (SYN-SENT bedeutet, dass nie ein SYN-ACK zurückkam).

Stolpersteine

Ein abgeschlossener Handshake belegt die Erreichbarkeit nur zum Zeitpunkt des Verbindungsaufbaus; verwirft ein NAT-Gerät oder eine Firewall den Zustand später, entsteht Stille statt eines Fehlers. Der Retransmission-Backoff verläuft exponentiell, sodass wenige aufeinanderfolgende Verluste zu einem Stillstand von mehreren zehn Sekunden führen. Keep-Alive-Prüfsonden sind ACK-Segmente und werden nicht zuverlässig zugestellt, weshalb der RFC es untersagt, eine einzelne unbeantwortete Sonde als tote Verbindung zu werten.