TCP

Was ist TCP?

TCP (Transmission Control Protocol) ist eines der beiden zentralen Transportprotokolle des Internets (neben UDP) und die Grundlage für HTTP/:cid-link{cid="" text="HTTPS"}, E-Mail (SMTP/IMAP/POP3), SSH und fast alle anderen verbindungsorientierten Protokolle. TCP garantiert, dass Datenpakete vollständig, in der richtigen Reihenfolge und ohne Duplikate beim Empfänger ankommen — auch wenn das Netzwerk dazwischen Pakete fallen lässt, neu anordnet oder verzögert.

Der Preis für diese Zuverlässigkeit ist Overhead: Verbindungsaufbau (Three-Way-Handshake), Acknowledgements, Retransmissions und Congestion Control fügen Latenz und Datenvolumen hinzu. HTTP/3 und QUIC wurden entwickelt, um genau diesen Overhead zu reduzieren.

Wie funktioniert TCP?

Vor der Datenübertragung wird eine Verbindung über den Three-Way-Handshake etabliert:

1. SYN: Client sendet ein Segment mit gesetztem SYN-Flag und einer zufälligen Sequenznummer.
2. SYN-ACK: Server antwortet mit SYN+ACK, bestätigt die Client-Sequenznummer und sendet eine eigene.
3. ACK: Client bestätigt die Server-Sequenznummer. Die Verbindung ist offen.

Dieser Handshake kostet einen Round-Trip (RTT) — bei 50ms Latenz also 50ms bevor ein einziges Byte Nutzdaten übertragen wird. Bei HTTPS kommt der TLS-Handshake dazu (weiterer RTT bei TLS 1.2, halber RTT bei TLS 1.3).

Zuverlässigkeit erreicht TCP durch:

• Sequenznummern: Jedes Byte hat eine eindeutige Sequenznummer, sodass der Empfänger Lücken und Duplikate erkennt.
• Acknowledgements: Der Empfänger bestätigt empfangene Daten. Ausbleibende ACKs lösen Retransmission aus.
• Congestion Control: TCP reduziert die Senderate bei Paketverlusten (Slow Start, AIMD) — verhindert Netzüberlastung.

TCP in der Praxis

Für Webentwickler ist TCP meist unsichtbar — aber Performance-Probleme haben oft TCP-Ursachen:

Connection Reuse: HTTP/1.1 eingeführt Keep-Alive, um TCP-Verbindungen für mehrere Requests zu nutzen — statt pro Request einen neuen Three-Way-Handshake durchzuführen. HTTP/2 geht weiter mit Multiplexing (viele Requests über eine TCP-Verbindung gleichzeitig).

Head-of-Line Blocking bei HTTP/2: HTTP/2 überträgt mehrere Streams über eine TCP-Verbindung. Geht ein TCP-Paket verloren, blockiert TCP (das alle Pakete in Reihenfolge liefern muss) alle Streams — nicht nur den betroffenen. HTTP/3 löst das durch QUIC (UDP-basiert), das Streams unabhängig voneinander behandelt.

TCP Keepalive bei persistenten Verbindungen: Redis, MySQL, WebSocket-Verbindungen nutzen TCP-Keepalive, um zu erkennen ob die Verbindung noch lebt. Falsch konfigurierte Keepalive-Timeouts führen zu Ghost-Connections in Connection-Pools.

Ports: TCP-Ports identifizieren Dienste auf einem Host. Bekannte Ports: 80 (HTTP), 443 (HTTPS), 22 (SSH), 3306 (MySQL), 6379 (Redis). Ports über 1024 sind frei verfügbar — WordPress lokal auf Port 8765 nutzt auch TCP.

Was passiert bei TCP-Problemen?

TCP-Verbindungsprobleme äußern sich als Timeouts — der häufigste Fehler in WordPress-Logs. Wenn MySQL nicht erreichbar ist, wartet PHP auf den TCP-Connect, bis der connect_timeout abläuft. Wenn Redis hängt, warten alle WordPress-Anfragen. Firewall-Regeln die TCP-Verbindungen stillschweigend droppen (statt mit RST abzuweisen) sind besonders schwer zu debuggen, weil Retransmissions und Timeouts die eigentliche Ursache verschleiern.

Bei Hetzner-Servern mit WireGuard VPN: TCP-Verbindungen durch den VPN-Tunnel haben etwas höhere MTU-Overhead — tcp_mtu_probing auf dem Server aktivieren verhindert PMTUD-Blackhole-Probleme.

Häufige Fragen

Was ist der Unterschied zwischen TCP und UDP? TCP ist verbindungsorientiert und zuverlässig (Three-Way-Handshake, Acknowledgements, geordnete Lieferung). UDP ist verbindungslos und unzuverlässig — keine Handshakes, keine Bestätigungen, keine Reihenfolge-Garantie. UDP ist schneller für Anwendungen die Latenz über Zuverlässigkeit priorisieren (DNS-Abfragen, Video-Streaming, Online-Spiele, QUIC/HTTP/3).

Warum hat HTTP/3 TCP aufgegeben? TCP hat strukturelle Nachteile: Head-of-Line-Blocking (ein verlorenes Paket blockiert alle Streams), langsamer Verbindungsaufbau (Handshake + TLS), und schlechte Performance bei Netzwechseln (Mobile, WiFi → LTE). QUIC auf UDP implementiert alles was TCP kann, aber ohne diese Einschränkungen und mit eingebautem TLS 1.3.

Wie viele TCP-Verbindungen darf ein Browser gleichzeitig öffnen? Bei HTTP/1.1: 6 Verbindungen pro Host (Browser-Limit). Bei HTTP/2: 1 Verbindung pro Host (Multiplexing macht mehrere überflüssig). Das war einer der Hauptgründe für Domain-Sharding bei HTTP/1.1 — ein Optimierungs-Trick der bei HTTP/2 kontraproduktiv ist.