# TCP/IP Internals: Die Mechanik der Verbindung

TL;DR / Management Summary Ein Netzwerk-Socket ist unter Linux ein komplexes Objekt im Kernel-Memory. Jede TCP-Verbindung durchläuft eine präzise definierte State Machine: Vom Aufbau (3-Way-Handshake) bis zum Abbau (4-Way-Teardown). Ein Senior Admin muss wissen, was im Kernel passiert, wenn Verbindungen im TIME_WAIT hängen bleiben, wie der Retransmission-Timer arbeitet und wie der Kernel unvollständige Datenströme wieder zusammensetzt (TCP Reassembly).

# 1. Einführung & Architektur

Die Zustände einer Verbindung.

Der Kernel verwaltet für jede Verbindung eine Struktur (struct tcp_sock).

# Die TCP State Machine (Mermaid)

graph TD
    A[CLOSED] -->|1. SYN| B[SYN_SENT]
    B -->|2. SYN-ACK| C[ESTABLISHED]
    A -->|1. Listen| D[LISTEN]
    D -->|2. SYN Received| E[SYN_RECV]
    E -->|3. ACK| C
    C -->|FIN| F[FIN_WAIT_1]
    F -->|ACK| G[FIN_WAIT_2]
    G -->|FIN| H[TIME_WAIT]
    H -->|Timeout 60s| A

# 2. Der Verbindungsaufbau: Handshake & Backlog

Wo Sockets geboren werden.

Wenn ein Client ein SYN sendet, landet er in der SYN Backlog Queue. Erst nach dem finalen ACK wird der Socket in die Accept Queue verschoben.

• Tuning: net.ipv4.tcp_max_syn_backlog bestimmt, wie viele halboffene Verbindungen der Kernel puffert (Schutz vor SYN-Floods).

# 3. Der Verbindungsabbau: TIME_WAIT

Der Geisterzustand.

Nach dem Schließen einer Verbindung bleibt der Socket für 60 Sekunden im TIME_WAIT.

• Warum?: Um sicherzustellen, dass verzögerte Pakete der alten Verbindung nicht als Teil einer neuen Verbindung (mit gleicher IP/Port) interpretiert werden.
• Problem: Bei tausenden Kurzzeit-Verbindungen (z.B. Microservices) gehen dem Server die Sockets aus.

# 4. Day-2 Operations: Metriken aus dem Kernel

Zustände zählen.

# Zusammenfassung der Zustände

ss -s
# Zeigt die Anzahl der Sockets in jedem Zustand (ESTAB, TIME-WAIT, etc.)

# TCP-Fehler und Retransmits

nstat -az | grep -E "TcpRetransSegs|TcpOutRsts"
# TcpRetransSegs: Pakete, die erneut gesendet werden mussten (Netzwerk-Problem).
# TcpOutRsts: Verbindungen, die der Kernel hart abgebrochen hat.

# 5. Troubleshooting & “War Stories”

Wenn die Logik den Dienst bricht.

# Story 1: “Der hängende Handshake (SYN-RECV)”

Symptom: ss -ant zeigt hunderte Verbindungen im Status SYN_RECV. Der Server antwortet extrem langsam auf neue Anfragen. Ursache: Möglicher SYN-Flood Angriff oder ein Netzwerkpfad, der zwar SYN durchlässt, aber das SYN-ACK des Servers blockiert. Lösung: Aktivieren Sie SYN Cookies (Artikel 332) und prüfen Sie die MTU-Einstellungen auf dem Pfad (Artikel 271).

# Story 2: “Zombies im Rechenzentrum”

Symptom: Ein Datenbank-Server hat tausende offene Verbindungen (ESTABLISHED), obwohl die Applikations-Server neu gestartet wurden. Ursache: Applikations-Crash ohne sauberen Close. Da TCP keine Keep-Alives im Standard-Intervall (2h) sendet, hält der Kernel die Sockets ewig offen. Lösung: Reduzieren Sie die Kernel-Keep-Alives: net.ipv4.tcp_keepalive_time = 600 (10 Minuten).

# 6. Fazit & Empfehlung

• Verständnis: Betrachten Sie TIME_WAIT nicht als Fehler, sondern als Sicherheits-Feature des Protokolls.
• Wartung: Nutzen Sie nstat, um Trends bei Retransmissions zu erkennen – ein Anstieg deutet oft auf ein sterbendes Kabel oder einen überlasteten Switch hin.
• Wahl: Nutzen Sie für interne Kommunikation (Inter-Process) lieber Unix-Domain-Sockets (AF_UNIX) statt TCP/IP. Sie umgehen die gesamte TCP-State-Machine und sind massiv schneller.

# Anhang: Cheatsheet für Socket-Experten