TCP und UDP: Unterschied, Ports und wann du was nimmst

TCP und UDP sind die beiden Transportprotokolle, mit denen Programme über IP-Netze Daten austauschen. TCP baut vor dem ersten Byte eine Verbindung auf, nummeriert jedes Paket und sendet Verlorenes erneut — die Daten kommen vollständig und in der richtigen Reihenfolge an. UDP verschickt seine Datagramme sofort, ohne Handshake und ohne Empfangsbestätigung: schneller, aber ohne Zustellgarantie. Faustregel: TCP für Web, Mail und Dateien, UDP für DNS, Sprache und Video.

TCP und UDP im direkten Vergleich

Beide arbeiten auf der Transportschicht — der Schicht, die Daten nicht nur zum richtigen Rechner, sondern zum richtigen Programm auf diesem Rechner bringt. Die Unterschiede auf einen Blick:

Eigenschaft	TCP	UDP
Verbindung	verbindungsorientiert (Handshake vorab)	verbindungslos (sofort senden)
Zuverlässigkeit	Bestätigung und erneutes Senden	keine Garantie, kein erneutes Senden
Reihenfolge	geordnet durch Sequenznummern	ungeordnet, Pakete können sich überholen
Tempo	langsamer durch Verwaltungsaufwand	schneller, kaum Overhead
Header-Größe	20 bis 60 Byte	fest 8 Byte
Fluss- und Staukontrolle	ja (Sendefenster, Congestion Control)	nein, muss die Anwendung selbst regeln
Ports	eigener 16-Bit-Nummernraum (z. B. 443/TCP)	eigener 16-Bit-Nummernraum (z. B. 53/UDP)
Typische Dienste	HTTPS, SMTP, IMAP, SSH, SMB	DNS, DHCP, NTP, VoIP, Streaming, Spiele

TCP: Zustellung mit Empfangsbestätigung

TCP (Transmission Control Protocol) verhält sich wie ein Einschreiben mit Rückschein. Bevor Nutzdaten fließen, einigen sich beide Seiten im Drei-Wege-Handshake — dem Verbindungsaufbau in drei Schritten — darauf, dass sie bereit sind:

1. SYN — der Client meldet den Verbindungswunsch an und schickt eine zufällige Startnummer (Sequenznummer) mit.
2. SYN-ACK — der Server bestätigt und schickt seinerseits eine Startnummer.
3. ACK — der Client bestätigt die Antwort des Servers. Erst jetzt beginnt die Datenübertragung.

Während der Übertragung trägt jedes Segment eine Sequenznummer. Der Empfänger quittiert, was angekommen ist; bleibt die Quittung aus, sendet TCP das Segment erneut. Dazu kommt die Flusskontrolle: Der Empfänger meldet über die Fenstergröße, wie viele Daten er noch verkraftet, und die Staukontrolle drosselt bei Paketverlust die Senderate. Diese Absicherung kostet Zeit, Pakete und Header-Platz — dafür bekommt die Anwendung einen sauberen, geordneten Datenstrom.

UDP: senden ohne Rückfrage

UDP (User Datagram Protocol) verzichtet auf all das. Kein Handshake, keine Quittung, kein erneutes Senden, keine Staukontrolle. Das Protokoll schreibt Ziel-IP und Zielport auf das Datagramm und schickt es los — ob es ankommt, in welcher Reihenfolge oder ob doppelt, prüft UDP selbst nicht.

Klingt nach einem Nachteil, ist aber der eigentliche Zweck: Der Header bleibt mit festen 8 Byte winzig, es gibt keine Wartezeit auf Bestätigungen, und ein verlorenes Paket hält den Datenstrom nicht auf. Bei einem Videotelefonat stört ein kurzes Ruckeln weniger als eine Pause, in der auf die Wiederholung eines längst veralteten Audiopakets gewartet wird. Braucht eine Anwendung trotzdem Kontrolle, baut sie diese selbst obendrauf — genau so arbeitet QUIC, dazu weiter unten mehr.

Welche Ports nutzen TCP, welche UDP?

Ein Port ist eine 16-Bit-Nummer zwischen 0 und 65535, die einen Dienst auf dem Zielrechner adressiert. Wichtig für Prüfung und Praxis: TCP und UDP führen jeweils einen eigenen Nummernraum. TCP-Port 53 und UDP-Port 53 sind zwei verschiedene Endpunkte, auch wenn die IANA denselben Dienstnamen für beide Protokolle vergeben hat.

Die IANA teilt den Nummernraum in RFC 6335 in drei Bereiche:

• 0–1023 — System- bzw. Well-Known-Ports: fest vergeben, unter Linux darf nur ein privilegierter Prozess darauf lauschen (HTTPS, SSH, DNS).
• 1024–49151 — User- bzw. Registered-Ports: ebenfalls von der IANA vergeben, aber auch für normale Benutzerprozesse nutzbar (MySQL 3306, RDP 3389).
• 49152–65535 — dynamische bzw. ephemere Ports: nie fest vergeben. Aus diesem Bereich zieht dein Betriebssystem den Quellport jeder ausgehenden Verbindung.

Die Dienste, die in der Praxis und in Prüfungsaufgaben immer wieder vorkommen:

Port	Dienst	Protokoll
20/21	FTP (Daten/Steuerung)	TCP
22	SSH, SFTP	TCP
25	SMTP (Mailversand)	TCP
53	DNS	UDP und TCP
67/68	DHCP (Server/Client)	UDP
69	TFTP	UDP
80	HTTP	TCP
123	NTP (Zeitsynchronisation)	UDP
143 / 993	IMAP / IMAPS	TCP
161/162	SNMP (Abfrage/Traps)	UDP
443	HTTPS klassisch / HTTP/3 mit QUIC	TCP und UDP
445	SMB (Windows-Freigaben)	TCP
3389	RDP (Remotedesktop)	TCP, optional UDP

Das Muster dahinter ist gut zu merken: Dienste, bei denen jedes Byte stimmen muss, liegen auf TCP. Dienste mit kurzen Frage-Antwort-Paaren oder kontinuierlichen Datenströmen liegen auf UDP.

Offene TCP- und UDP-Ports auf dem eigenen Rechner prüfen

Welcher Dienst gerade auf welchem Port lauscht, zeigt dir das Betriebssystem selbst — nützlich, wenn ein Programm meldet, der Port sei belegt:

1. Windows, Eingabeaufforderung: netstat -ano listet alle Verbindungen samt Prozess-ID. Mit netstat -ano -p udp beschränkst du die Ausgabe auf UDP.
2. Windows, PowerShell: Get-NetTCPConnection -State Listen für lauschende TCP-Ports, Get-NetUDPEndpoint für die UDP-Seite.
3. Linux: ss -tuln — t für TCP, u für UDP, l für lauschende Sockets, n für numerische Ports statt Dienstnamen.

Beim Lesen der Ausgabe fällt der Unterschied der beiden Protokolle direkt auf: TCP-Einträge haben einen Verbindungszustand wie LISTEN oder ESTABLISHED, UDP-Sockets zeigen unter Linux dagegen UNCONN — es gibt schlicht keine Verbindung, deren Zustand man verwalten könnte. Prüfe nur Systeme, für die du zuständig bist; Port-Scans auf fremde Rechner sind kein Diagnose-, sondern ein Rechtsthema.

Wann nimmt man TCP, wann UDP?

Die Entscheidung hängt daran, was teurer ist: ein verlorenes Paket oder eine Verzögerung.

• TCP, wenn jedes Byte stimmen muss: Webseiten, E-Mail über SMTP/IMAP, Datei-Downloads, Datenbankverbindungen, Fernzugriff per SSH. Eine halb übertragene Datei wäre unbrauchbar.
• UDP, wenn Tempo zählt und einzelne Verluste tolerierbar sind: DNS-Abfragen, DHCP im Startvorgang, Zeitabgleich per NTP, VoIP und Videokonferenzen, Live-Streaming, Online-Spiele.

DNS zeigt die UDP-Logik am deutlichsten: Eine Namensauflösung ist eine kleine Frage mit kurzer Antwort. Der komplette TCP-Handshake wäre mehr Aufwand als die Abfrage selbst — bleibt die Antwort aus, fragt der Client einfach noch einmal. Passt die Antwort dagegen nicht in ein UDP-Paket, setzt der Server das TC-Flag (Truncated), und der Client wiederholt die Abfrage über TCP. Deshalb verlangen RFC 7766 und RFC 9210, dass DNS-Server beide Transportwege beherrschen.

QUIC: zuverlässiger Transport auf UDP

Der klare Schnitt „TCP gleich zuverlässig, UDP gleich unzuverlässig“ bröckelt seit HTTP/3. Dessen Transportprotokoll QUIC läuft auf UDP-Port 443 und bringt Verbindungsverwaltung, Wiederholung verlorener Pakete und Verschlüsselung selbst mit — statt sie von der Transportschicht zu erben. Laut w3techs unterstützten im August 2026 rund 40 Prozent der beobachteten Websites HTTP/3.

Für die Fehlersuche heißt das: Wenn eine Seite im Firmen- oder Hotelnetz spürbar zäh lädt, im Heimnetz aber nicht, blockiert dort möglicherweise die Firewall ausgehendes UDP auf Port 443. Der Browser fällt dann nach einem Timeout auf HTTPS über TCP zurück. Eine Firewall-Regel, die nur TCP 443 freigibt, verhindert HTTP/3 also lautlos.

Häufige Fragen

Welche Ports nutzen TCP und welche UDP?

Über TCP laufen unter anderem HTTP (80), HTTPS (443), SSH (22), SMTP (25), IMAP (143/993) und SMB (445). UDP nutzen DNS (53), DHCP (67/68), TFTP (69), NTP (123), SNMP (161/162) sowie QUIC auf Port 443.

Sind TCP-Port 53 und UDP-Port 53 derselbe Port?

Nein. TCP und UDP haben jeweils einen eigenen Nummernraum, also zwei verschiedene Endpunkte. Firewall-Regeln gelten immer pro Protokoll: Eine Freigabe für TCP 53 öffnet UDP 53 nicht mit.

Anzeige

Was ist der Unterschied zwischen TCP und UDP?

TCP ist verbindungsorientiert, bestätigt jedes Paket und sendet Verlorenes erneut — Daten kommen vollständig und geordnet an. UDP sendet ohne Handshake und ohne Bestätigung: schneller, aber ohne Zustellgarantie.

Ist TCP oder UDP schneller?

UDP. Es entfällt der Verbindungsaufbau, es gibt keine Empfangsbestätigungen und der Header ist mit 8 Byte statt 20 bis 60 Byte deutlich kleiner. TCP zahlt das Tempo für seine Zuverlässigkeit.

Wie sehe ich, welche Ports auf meinem Rechner offen sind?

Unter Windows zeigt netstat -ano alle Verbindungen mit Prozess-ID, in der PowerShell Get-NetTCPConnection und Get-NetUDPEndpoint. Unter Linux listet ss -tuln alle lauschenden TCP- und UDP-Ports.

Hintergrund: Wo sitzen TCP und UDP im Netzwerk?

Beide sitzen auf Schicht 4 des OSI-Modells, der Transportschicht, direkt über dem Internet Protocol. Die Arbeitsteilung ist prüfungsrelevant und im Alltag hilfreich: IP adressiert den Rechner und routet das Paket durchs Netz, TCP beziehungsweise UDP adressiert über den Port das Programm auf diesem Rechner. Fällt eine Verbindung aus, lässt sich damit eingrenzen, wo das Problem liegt — antwortet der Host auf Ping, aber der Dienst nicht, ist es kein Routing-, sondern ein Port-, Dienst- oder Firewall-Thema.

Der Größenunterschied der Header erklärt den Rest: 8 Byte bei UDP gegenüber 20 bis 60 Byte bei TCP. In diesen zusätzlichen Bytes stecken Sequenz- und Bestätigungsnummern, Fenstergröße und Steuerflags — also exakt die Buchführung, die TCP zuverlässig und UDP schnell macht.