TCP und UDP: Ports, Dienste und der TCP-Handshake
TCP und UDP sind die beiden wichtigsten Transportprotokolle im Internet, und Portnummern sorgen dafuer, dass verschiedene Dienste auf demselben Host sauber getrennt bleiben. Wer verstehen will, wie Webserver, SSH, SMTP oder eigene Anwendungen erreichbar und ueberwachbar werden, braucht die Grundlagen zu TCP, UDP, Ports und dem TCP Three-Way Handshake.
Was TCP und UDP eigentlich sind
TCP, also Transmission Control Protocol, ist fuer zuverlaessige Kommunikation ausgelegt. Es baut eine Verbindung auf, haelt Pakete in der richtigen Reihenfolge, sendet fehlende Daten erneut und stellt sicher, dass beide Seiten denselben Verbindungszustand sehen. Deshalb wird TCP typischerweise fuer Websites, APIs, SSH, Datenbanken und Mailtransport verwendet.
UDP, also User Datagram Protocol, ist deutlich leichter. Es versendet Datagramme ohne vorherigen Verbindungsaufbau und ohne eingebaute Garantie fuer Reihenfolge, Zustellung oder Wiederholung. Dadurch eignet es sich gut fuer DNS-Anfragen, Streaming, VoIP, Online-Gaming und andere Faelle, in denen niedrige Latenz wichtiger ist als perfekte Zustellung.
Wann der Unterschied zwischen TCP und UDP relevant wird
Sie untersuchen die Erreichbarkeit eines Dienstes
Ein TCP-Dienst kann ausfallen, weil der Port geschlossen oder gefiltert ist oder die Anwendung nicht mehr lauscht. Ein UDP-Dienst verhaelt sich anders, weil es keinen formalen Verbindungsaufbau gibt, der die Bereitschaft auf dieselbe Weise bestaetigt.
Sie waehlen ein Protokoll fuer eine Anwendung
TCP ist meist die Standardwahl, wenn Korrektheit und geordnete Uebertragung zaehlen. UDP wird gewaehlt, wenn Geschwindigkeit, geringer Overhead oder Echtzeitverhalten wichtiger sind als Wiederholungen.
Sie muessen Firewall- und Portregeln verstehen
Dieselbe Portnummer kann getrennt fuer TCP und UDP existieren. Eine Firewall kann also TCP 443 erlauben und UDP 443 gleichzeitig blockieren, was das Verhalten des Verkehrs stark veraendert.
Sie wollen die Verfuegbarkeit von Diensten ueberwachen
Bei vielen Infrastruktur- und Applikationschecks ist die Frage, ob ein TCP-Port eine Verbindung annimmt, eines der klarsten Signale dafuer, dass der Endpoint erreichbar ist und der Dienst wirklich lauscht.
So funktioniert der TCP Three-Way Handshake
Der Client sendet SYN
Eine TCP-Verbindung beginnt damit, dass der Client ein SYN-Paket an den Zielport sendet. Damit signalisiert er, dass er eine Verbindung aufbauen und eine Sitzung starten moechte.
Der Server antwortet mit SYN-ACK
Ist der Port offen und der Dienst aktiv, antwortet der Server mit SYN-ACK. Damit bestaetigt er die Anfrage und zeigt, dass er bereit fuer den naechsten Schritt ist.
Der Client sendet ACK
Der Client bestaetigt mit ACK. Ab diesem Moment ist die TCP-Verbindung aufgebaut und die eigentlichen Anwendungsdaten koennen fliessen.
Scheitert der Handshake, ist der Dienst oft geschlossen oder gefiltert
Eine abgelehnte Verbindung, ein Timeout oder eine ausbleibende Antwort bedeuten haeufig, dass der Port geschlossen ist, eine Firewall blockiert oder der Dienst auf diesem Endpoint nicht verfuegbar ist.
So lassen sich Ports und typische Dienste einordnen
Eine Portnummer legt fest, welcher Dienst auf einem Host eingehenden Verkehr empfangen soll. Ein paar typische Beispiele:
22 SSH Remote-Shell und sichere Administration 25 SMTP Mailtransport zwischen Servern 53 DNS Aufloesung von Domainnamen 80 HTTP Unverschluesselter Webverkehr 443 HTTPS Verschluesselter Webverkehr ueber TLS 587 SMTP Mail Submission durch Clients
Port 22
SSH nutzt TCP 22 fuer sichere Fernadministration, Shell-Zugriff und Automatisierung.
Port 25 und 587
SMTP verwendet haeufig TCP 25 fuer den Mailtransport zwischen Servern und TCP 587 fuer authentifizierte Mail-Einlieferung durch Clients.
Port 80 und 443
HTTP laeuft typischerweise auf TCP 80, waehrend HTTPS auf TCP 443 verwendet wird. Das sind die bekanntesten Web-Ports.
TCP und UDP auf derselben Nummer
Die Portnummer allein reicht nicht. TCP 53 und UDP 53 haben beide mit DNS zu tun, sind aber trotzdem unterschiedliche Transportpfade mit unterschiedlichem Verhalten.
Warum sich Ports nicht immer gleich verhalten
Ein offener TCP-Port bedeutet meist, dass ein Dienst aktiv lauscht und bereit ist, den Handshake abzuschliessen. Ein geschlossener Port lehnt oft sofort ab, waehrend ein gefilterter Port haeufig nur in einen Timeout laeuft.
UDP ist schwieriger allgemein zu pruefen, weil es kein direktes Gegenstueck zum TCP-Handshake gibt. Ein UDP-Dienst kann funktionieren, auch wenn auf einen einfachen Probe-Versuch keine direkte Antwort kommt, je nach Protokoll und Anwendungslogik.
TCP vs UDP
| Thema | TCP | UDP |
|---|---|---|
| Verbindungsmodell | Verbindungsorientiert, mit Handshake vor der Datenuebertragung. | Verbindungslos, ohne Handshake vor dem Senden. |
| Zuverlaessigkeit | Bietet Wiederholungen, Reihenfolge und Nachverfolgung der Zustellung. | Garantiert weder Zustellung noch Reihenfolge oder Wiederholung. |
| Am besten geeignet fuer | Webanwendungen, APIs, SSH, Datenbanken, E-Mail und stabile Service-Sitzungen. | DNS, Streaming, Gaming, VoIP und latenzkritischen Verkehr. |
Sie brauchen zusaetzlich einen schnellen Latenz- und Erreichbarkeitstest?
Ping hilft bei der grundlegenden Host-Erreichbarkeit und beim Paketverlust, waehrend TCP-Port-Checks beantworten, ob ein bestimmter Dienst wirklich Verbindungen annimmt.
Zum Ping-Leitfaden βTypische Situationen richtig deuten
Ein Host antwortet auf Ping, aber TCP 443 faellt aus
Der Server kann auf Netzebene erreichbar sein, waehrend der HTTPS-Dienst trotzdem down, blockiert, falsch konfiguriert oder auf diesem Port gar nicht aktiv ist.
TCP 22 ist offen, aber der Login funktioniert nicht
Der SSH-Daemon ist vermutlich erreichbar, doch Authentifizierung, Autorisierung oder Shell-Zugriff koennen trotzdem nach dem erfolgreichen Portcheck scheitern.
Ein Port laeuft in Timeout statt die Verbindung sauber abzulehnen
Das spricht oft eher fuer Filterung oder eine Firewall-Regel als fuer eine sauber geschlossene Gegenstelle.
Ein UDP-Dienst bleibt beim Test still
Das heisst nicht automatisch, dass der Dienst down ist. Viele UDP-Protokolle antworten nur dann, wenn der Probe-Aufbau auch fuer die Anwendung gueltig ist.
Wichtige Einschraenkungen
- β Ein erfolgreicher TCP-Portcheck beweist die Erreichbarkeit des Ports, aber nicht die Gesundheit des gesamten Anwendungsablaufs.
- β Hinter einem offenen Port kann trotzdem ein fehlerhafter Dienst stehen, der erst nach dem Verbindungsaufbau ausfaellt.
- β UDP-Dienste lassen sich nicht so allgemein pruefen, weil oft ein klares, handshake-aehnliches Bestaetigungssignal fehlt.
- β Firewall-Verhalten, NAT und Rate Limiting koennen dafuer sorgen, dass derselbe Port je nach Quellstandort anders erscheint.
Wie Ports manuell getestet werden
nc -vz example.com 443 Ein haeufig genutzter Schnelltest, ob ein TCP-Port von Ihrer aktuellen Quelle aus eine Verbindung annimmt.
telnet example.com 25 Immer noch nuetzlich fuer einfache manuelle SMTP- oder TCP-Banner-Tests, auch wenn Telnet auf vielen Systemen nicht mehr standardmaessig installiert ist.
nmap -p 22,25,80,443 example.com Nmap kann mehrere Ports pruefen und einen breiteren Blick auf exponierte Dienste geben, je nach Scan-Typ und Berechtigungen.
Haeufige Fragen
Ein manueller Porttest hilft einmal. TCP-Port-Monitoring hilft dauerhaft.
nsmon prueft TCP-Ports kontinuierlich von Probe-Standorten aus, damit Sie merken, wenn ein Dienst keine Verbindungen mehr annimmt, bevor Nutzer das Problem melden. Erstellen Sie ein kostenloses Konto und ueberwachen Sie kritische TCP-Endpoints wie SSH, SMTP, HTTP, HTTPS oder eigene Applikationsports.