Wenn eine Website lädt, eine API antwortet oder ein Deployment ein Image aus einer Registry zieht, müssen Daten zuverlässig zwischen zwei Systemen ankommen. Genau dafür ist TCP zuständig. Ich erkläre, was das Transmission Control Protocol leistet, wie der Verbindungsaufbau funktioniert und worauf es im Hosting- und DevOps-Alltag bei Ports, Firewalls, Performance und Fehlersuche ankommt.
TCP sorgt für geordnete und zuverlässige Datenströme
- TCP ist ein verbindungsorientiertes Transportprotokoll auf Schicht 4 des Netzwerkmodells.
- Ein Three-Way Handshake baut die Verbindung zwischen Client und Server auf.
- Sequenznummern, Bestätigungen und Wiederholungen verhindern fehlende oder falsch sortierte Daten.
- TCP wird unter anderem für HTTPS, SSH, Datenbanken und Container-Registries genutzt.
- Im Vergleich zu UDP ist TCP zuverlässiger, aber meist mit mehr Overhead und höherer Latenz verbunden.
Was TCP genau ist und welche Aufgabe es übernimmt
TCP steht für Transmission Control Protocol. Es regelt, wie zwei Endpunkte Daten über ein IP-Netz austauschen. IP kümmert sich dabei vor allem darum, Pakete an die richtige Adresse zu bringen. TCP stellt darüber sicher, dass aus diesen einzelnen Paketen am Ziel wieder ein vollständiger, geordneter Datenstrom entsteht.
Das Protokoll arbeitet auf der Transportschicht, häufig auch als Layer 4 bezeichnet. Anwendungen wie ein Webserver oder eine Datenbank müssen dadurch nicht selbst prüfen, ob jedes Datenstück angekommen ist. Sie lesen und schreiben einen Bytestrom, während TCP im Hintergrund die Übertragung kontrolliert.
Der Begriff „zuverlässig“ bedeutet allerdings nicht, dass TCP eine Anwendung rettet, die abgestürzt ist. TCP kann die korrekte Übertragung von Bytes bis zum Netzwerkstack des Empfängers sicherstellen. Ob ein Webserver die Anfrage verarbeitet, eine Datenbank sie bestätigt oder ein Dienst fachlich korrekt antwortet, liegt weiterhin bei der jeweiligen Anwendung.
TCP ist kein Verschlüsselungsprotokoll
Eine häufige Verwechslung betrifft TCP und Sicherheit. TCP verschlüsselt keine Inhalte. Bei HTTPS kommt zusätzlich TLS zum Einsatz, das die Verbindung zwischen Anwendung und Gegenstelle schützt. TCP liefert die Bytes zuverlässig, TLS macht sie vertraulich und prüft die Identität des Servers.
Auch Ports gehören zum praktischen Verständnis dazu. Eine IP-Adresse identifiziert einen Host, während ein Port den zuständigen Dienst auf diesem Host auswählt. Typische Beispiele sind TCP 22 für SSH, 80 für HTTP und 443 für HTTPS. Diese Portnummern sind Konventionen, keine technische Pflicht.
So baut TCP eine Verbindung auf
Bevor Daten fließen, handelt TCP eine Verbindung aus. Dieser Vorgang heißt Three-Way Handshake und besteht aus drei Nachrichten. Der Client signalisiert mit SYN, dass er eine Verbindung starten möchte. Der Server antwortet mit SYN-ACK und bestätigt den Wunsch. Mit ACK bestätigt der Client die Antwort, danach kann die eigentliche Anwendungskommunikation beginnen.
Die beteiligten Systeme tauschen dabei unter anderem Startwerte für Sequenznummern und bestimmte TCP-Optionen aus. Dazu gehören beispielsweise Informationen über die maximale Segmentgröße oder Erweiterungen für eine bessere Übertragung. In einer normalen Umgebung dauert der Aufbau oft nur wenige Millisekunden, bei großer Entfernung oder zusätzlichen Netzwerkwegen kann er sich aber deutlich bemerkbar machen.
Was während der Übertragung passiert
TCP zerlegt den Bytestrom in kleinere Segmente. Jedes Segment erhält eine Sequenznummer, damit der Empfänger die richtige Reihenfolge erkennen kann. Der Empfänger sendet Bestätigungen, sogenannte ACKs, zurück. Bleibt eine Bestätigung aus oder erkennt TCP einen Fehler, werden betroffene Daten erneut übertragen.
Zusätzlich reguliert TCP die Sendegeschwindigkeit. Die Flusskontrolle schützt den Empfänger vor einem überfüllten Puffer. Die Staukontrolle reagiert auf überlastete Netzwerke und reduziert die Sendemenge, wenn Verluste oder Verzögerungen auftreten. Das ist einer der Gründe, warum TCP in gemeinsam genutzten Netzen stabiler arbeitet als ein Protokoll, das einfach ungebremst Daten sendet.
Eine TCP-Verbindung endet normalerweise kontrolliert über FIN-Nachrichten. Ein RST signalisiert dagegen einen abrupten Abbruch. In Logs sieht man deshalb oft Begriffe wie timeout, connection reset oder broken pipe. Sie beschreiben verschiedene Fehlerbilder und sollten nicht pauschal als dasselbe Problem behandelt werden.
Warum TCP im Hosting und DevOps so wichtig ist
Im Hosting taucht TCP an vielen Stellen auf, auch wenn es im Browser nicht sichtbar ist. Ein HTTPS-Aufruf, eine SSH-Sitzung, eine Verbindung zu PostgreSQL oder der Abruf eines Docker-Images nutzt traditionell TCP. Für Betreiber bedeutet das, dass offene Ports, Erreichbarkeit und Verbindungsgrenzen regelmäßig überprüft werden müssen.
Webserver und Reverse Proxy
Bei einer typischen Website verbindet sich der Client zunächst mit einem Reverse Proxy wie Nginx, Apache oder einem Load Balancer. Dieser nimmt die TCP-Verbindung an und leitet die Anfrage an einen internen Dienst weiter. Zwischen Browser, Proxy und Anwendung können deshalb mehrere getrennte TCP-Verbindungen bestehen.
Ein häufiger Denkfehler ist, nur den Zielserver zu prüfen. Wenn Port 443 am Load Balancer erreichbar ist, heißt das noch nicht, dass der Proxy seinen Backend-Dienst auf Port 8080 erreicht. Ich kontrolliere bei solchen Fehlern immer jede Verbindungsetappe einzeln, weil ein „Server nicht erreichbar“ oft nur bedeutet, dass eine interne Firewall oder ein falscher Listener dazwischenliegt.
Container und Kubernetes
In Docker und Kubernetes werden Anwendungen häufig über virtuelle Netzwerke verbunden. Ein Container kann auf einem Port lauschen, ohne dass dieser Port automatisch von außen erreichbar ist. Erst ein korrektes Port-Mapping, ein Kubernetes-Service oder ein Ingress stellt den gewünschten Zugang her.
Besonders wichtig ist die Unterscheidung zwischen bind address und Port. Lauscht ein Dienst nur auf 127.0.0.1, akzeptiert er Verbindungen ausschließlich aus dem eigenen Container oder Host. Für Verbindungen über das Container-Netzwerk muss er meist auf 0.0.0.0 oder auf der passenden internen Adresse lauschen. Das ist eine der unscheinbaren Ursachen für viele fehlerhafte Deployments.
Gesundheitsprüfungen und Skalierung
Ein TCP-Health-Check prüft in der Regel nur, ob ein Port eine Verbindung annimmt. Er beweist nicht, dass die Anwendung korrekt arbeitet. Für eine belastbare Überwachung ist ein HTTP- oder Anwendungs-Health-Check oft aussagekräftiger, weil er zusätzlich eine Antwort und gegebenenfalls eine Datenbankverbindung prüft.
Bei starkem Traffic werden außerdem die maximale Zahl gleichzeitiger Verbindungen, der Accept-Backlog und die Dateideskriptoren relevant. Ein Dienst kann technisch laufen und trotzdem neue Clients ablehnen, weil Connection Limits oder Ressourcen erschöpft sind. Keep-Alive-Verbindungen senken zwar den Handshake-Aufwand, halten aber Ressourcen länger gebunden.
TCP und UDP im direkten Vergleich
Ob TCP die richtige Wahl ist, hängt davon ab, was die Anwendung wichtiger findet. TCP priorisiert zuverlässige Reihenfolge. UDP verschickt dagegen einzelne Datagramme ohne eingebauten Verbindungsaufbau und ohne automatische Wiederholung verlorener Daten.
| Kriterium | TCP | UDP |
|---|---|---|
| Verbindungsaufbau | Ja, über Handshake | Nein |
| Reihenfolge | Wird sichergestellt | Nicht garantiert |
| Verlorene Daten | Werden erneut übertragen | Müssen von der Anwendung behandelt werden |
| Typische Stärke | Zuverlässige Datenübertragung | Geringer Overhead und kurze Reaktionszeiten |
| Typische Nutzung | HTTPS, SSH, Datenbanken, E-Mail | DNS, Streaming, Echtzeitspiele, VoIP |
Für eine Datenbankverbindung ist ein fehlendes Byte normalerweise nicht akzeptabel. Für einen Videocall kann es dagegen sinnvoller sein, ein einzelnes verlorenes Paket zu überspringen, statt auf eine Wiederholung zu warten. Zuverlässigkeit kostet Zeit, und genau diesen Kompromiss sollte man bei der Protokollwahl verstehen.
Eine moderne Besonderheit ist HTTP/3. Es verwendet QUIC, das auf UDP aufsetzt und viele Funktionen von TCP, etwa Zuverlässigkeit und Verschlüsselung, in einer neuen Architektur kombiniert. Daraus folgt nicht, dass TCP verschwunden ist. HTTP/1.1, HTTP/2, SSH und viele interne Dienste setzen weiterhin auf TCP.
Typische TCP-Probleme im Betrieb erkennen
Die Fehlermeldung allein reicht selten für eine sichere Diagnose. Ein Timeout kann auf eine Firewall, Routing-Probleme, einen überlasteten Dienst oder einen nicht geöffneten Port hindeuten. Ein Connection refused bedeutet dagegen meist, dass der Host erreichbar ist, dort aber kein Dienst auf diesem Port lauscht oder eine Regel die Verbindung aktiv zurückweist.
Eine einfache Prüfreihenfolge
- Die Namensauflösung prüfen und sicherstellen, dass der Hostname auf die erwartete IP-Adresse zeigt.
- Erreichbarkeit und Routing kontrollieren, ohne ICMP als alleinigen Beweis zu verwenden.
- Den konkreten TCP-Port mit
ncoder einem vergleichbaren Werkzeug testen. - Auf dem Server mit
ss -ltnpprüfen, ob ein Dienst tatsächlich lauscht. - Firewall, Security Groups, Load-Balancer-Regeln und Container-Port-Mappings vergleichen.
- Bei sporadischen Fehlern Latenz, Retransmissions, Verbindungszahl und Serverressourcen beobachten.
Für eine tiefere Analyse hilft ein Paketmitschnitt mit tcpdump oder Wireshark. Dort lässt sich erkennen, ob ein SYN den Server erreicht, ob ein SYN-ACK zurückkommt und ob später Retransmissions auftreten. Der Ort des fehlenden Pakets grenzt die Fehlerursache oft schneller ein als ein Blick in den Anwendungscode.
Lesen Sie auch: GitLab erklärt - Funktionen, Kosten und die passende Variante
TIME_WAIT und zu viele Verbindungen
Nach dem Schließen einer TCP-Verbindung kann ein Socket noch eine Zeit lang im Zustand TIME_WAIT bleiben. Das ist beabsichtigt, damit verspätete Segmente nicht mit einer neuen Verbindung verwechselt werden. Bei sehr vielen kurzlebigen Verbindungen kann dieser Zustand jedoch Ressourcen und lokale Ports stark beanspruchen.
Die nachhaltige Lösung ist meist nicht, TIME_WAIT blind zu verkürzen. Besser sind Connection Pooling, Keep-Alive, ein passendes Timeout-Konzept und weniger unnötige Neuverbindungen. In meinen Deployments bringt die Wiederverwendung bestehender Verbindungen häufig mehr als aggressive Kernel-Tuning-Werte, die nur Symptome verdecken.
Was bei TCP oft unterschätzt wird
TCP garantiert keinen konstanten Durchsatz und keine feste Latenz. Ein überlastetes WLAN, ein langsamer Load Balancer oder ein überfüllter Server kann die Übertragung deutlich bremsen, obwohl die TCP-Verbindung formal funktioniert. „Port offen“ bedeutet nur Erreichbarkeit, nicht gute Performance.
Auch ein erfolgreicher TCP-Handshake sagt wenig über die Qualität einer Anwendung aus. Ein Server kann Verbindungen annehmen, danach aber bei jeder Anfrage in einen Timeout laufen. Deshalb sollten technische Überwachung und Anwendungsmessung zusammenarbeiten. Sinnvolle Kennzahlen sind unter anderem Verbindungsfehler, Antwortzeit, Retransmissions, aktive Sessions und die Auslastung von CPU, Arbeitsspeicher und Dateideskriptoren.
Die knappste Antwort auf die Frage, was TCP ist, lautet deshalb: TCP ist der zuverlässige Transportweg für einen geordneten Bytestrom zwischen zwei Netzwerkendpunkten. Im Hosting entscheidet dieses Protokoll mit darüber, ob Dienste erreichbar, stabil und unter Last belastbar bleiben. Wer Handshake, Ports, Zustände und typische Fehlerbilder versteht, kann Netzwerkprobleme deutlich gezielter eingrenzen.
