TCP vs. UDP #

Überblick #

TCP (Transmission Control Protocol) und UDP (User Datagram Protocol) sind zwei zentrale Transportprotokolle im TCP/IP-Stack. Beide arbeiten oberhalb von IP und sorgen dafür, dass Anwendungsdaten von einem Prozess auf einem Host zu einem Prozess auf einem anderen Host transportiert werden. UDP ist als datagrammbasiertes Protokoll standardisiert, während TCP ein verbindungsorientiertes, zuverlässiges Transportprotokoll ist. TCP wird heute in RFC 9293 als Internet Standard beschrieben; UDP ist in RFC 768 spezifiziert.

Einfach gesagt:

• TCP priorisiert Zuverlässigkeit, Reihenfolge und Kontrolle
• UDP priorisiert geringen Overhead, Geschwindigkeit und Einfachheit

Darum ist TCP typisch für Dinge wie Webseitenabrufe, Dateiübertragungen, APIs, E-Mail, Datenbanken, während UDP oft für DNS, VoIP, Live-Streaming, Online-Gaming oder als Basis für moderne Protokolle wie QUIC verwendet wird. QUIC ist ausdrücklich als UDP-basiertes Transportprotokoll standardisiert.

1. Einordnung im Netzwerkstack #

TCP und UDP liegen in der Transportschicht. Diese Schicht stellt der Anwendung einen Ende-zu-Ende-Transport zwischen Prozessen bereit, typischerweise identifiziert über Portnummern. UDP verwendet Quell- und Zielport im Header; TCP ebenfalls.

Vereinfacht:

Anwendung         HTTP, HTTPS, DNS, SMTP, RTP, ...
Transport         TCP oder UDP
Internet          IP
Netzzugang        Ethernet, WLAN, Mobilfunk, ...

Die zentrale Rolle von TCP/UDP ist also nicht das Routing durchs Internet, sondern der Transport für Anwendungen auf den Endsystemen.

2. Die Kerndifferenz in einem Satz #

TCP #

TCP ist verbindungsorientiert und stellt einen zuverlässigen, geordneten Byte-Stream mit Mechanismen wie Sequenznummern, Bestätigungen, Wiederholungen, Flusskontrolle und Überlastkontrolle bereit.

UDP #

UDP ist verbindungslos und stellt einen einfachen Datagramm-Dienst bereit: Nachrichten werden gesendet, aber das Protokoll selbst garantiert weder Zustellung noch Reihenfolge noch Duplikatfreiheit.

3. TCP im Detail #

3.1 Grundidee #

TCP wurde für Anwendungen entworfen, die einen zuverlässigen Datentransport benötigen. Das bedeutet:

• Daten sollen ankommen
• Daten sollen in der richtigen Reihenfolge ankommen
• verlorene Segmente sollen neu übertragen werden
• Sender und Empfänger sollen sich auf die Übertragungskapazität abstimmen
• das Netzwerk soll nicht unnötig überlastet werden

Dafür bringt TCP deutlich mehr Logik mit als UDP. RFC 9293 beschreibt TCP als wichtiges Transportprotokoll des Internet-Stacks und fasst die historisch gewachsene Spezifikation zusammen, inklusive Retransmission, Flow Control und Congestion Control.

3.2 Verbindungsorientierung #

Bevor Anwendungsdaten übertragen werden, baut TCP normalerweise eine Verbindung auf. Das geschieht klassisch mit dem Three-Way Handshake:

Client -> Server : SYN
Server -> Client : SYN-ACK
Client -> Server : ACK

Danach gilt die Verbindung als aufgebaut. Beide Seiten kennen nun Initialwerte und können Daten austauschen. Das ist ein wesentlicher Unterschied zu UDP, wo keine solche Verbindung im Protokoll nötig ist. Die TCP-Spezifikation beschreibt genau diese verbindungsorientierte Arbeitsweise mit Zuständen wie LISTEN, SYN-SENT, ESTABLISHED, FIN-WAIT und weiteren.

3.3 Zuverlässigkeit #

TCP nummeriert gesendete Daten und bestätigt empfangene Daten. Fehlt eine Bestätigung oder erkennt TCP einen Verlust, werden Daten neu übertragen. Genau dadurch ist TCP robust gegenüber Paketverlusten auf dem Weg durchs Netz. Retransmission Timeout und Verlustbehandlung sind fester Bestandteil der TCP-Spezifikation.

3.4 Reihenfolge #

TCP liefert den Anwendungen einen geordneten Datenstrom. Selbst wenn IP-Pakete im Netz in anderer Reihenfolge ankommen, sortiert TCP sie anhand der Sequenzinformationen wieder korrekt ein, bevor die Anwendung sie liest.

3.5 Flusskontrolle #

TCP besitzt Flow Control, damit ein schneller Sender einen langsameren Empfänger nicht überfordert. Dafür wird ein Window verwendet: Der Empfänger teilt mit, wie viele Daten er aktuell noch puffern kann.

3.6 Überlastkontrolle #

TCP besitzt zusätzlich Congestion Control. Sie soll verhindern, dass zu viele Daten auf einmal ins Netz gepumpt werden und Router oder Leitungen überlaufen. Diese Fähigkeit ist einer der Gründe, warum TCP im offenen Internet so wichtig wurde. RFC 9293 listet Congestion Control ausdrücklich als Teil der TCP-Kommunikation.

3.7 Byte-Stream statt Nachrichten #

Ein oft missverstandener Punkt: TCP transportiert keine einzelnen Nachrichten im semantischen Sinn, sondern einen kontinuierlichen Bytestrom. Die Anwendung muss selbst wissen, wo eine Nachricht beginnt und endet, zum Beispiel über:

• Längenfelder
• Zeilenenden
• feste Strukturen
• Serialisierungsformate

Beispiel:
Eine Anwendung sendet dreimal "Hallo", " ", "Welt". Der Empfänger kann das je nach Timing als einen zusammenhängenden Stream oder in anderen Blockgrößen lesen. TCP garantiert den Inhalt und die Reihenfolge, aber nicht dieselben Lesegrenzen wie beim Senden. Diese Stream-Natur ist Teil der TCP-Spezifikation.

4. UDP im Detail #

4.1 Grundidee #

UDP ist absichtlich minimalistisch. Es stellt einen einfachen, verbindungslosen Datagramm-Dienst bereit. Ein Datagramm wird gesendet, aber UDP kümmert sich nicht darum, ob es ankommt, doppelt ankommt, verspätet ankommt oder in anderer Reihenfolge ankommt. Genau das beschreibt RFC 768 als „datagram mode of packet-switched computer communication“.

4.2 Verbindungslos #

Es gibt bei UDP keinen eingebauten Verbindungsaufbau wie bei TCP. Eine Anwendung kann sofort Daten senden:

Client -> Server : UDP-Datagramm

Das spart Zeit und Protokoll-Overhead.

4.3 Nachrichtenorientiert #

Im Gegensatz zu TCP ist UDP nachrichtenorientiert. Ein gesendetes Datagramm bleibt aus Sicht der Anwendung eine Einheit. Liest die Anwendung das Datagramm, bekommt sie genau diese Datagramm-Grenze. Das ist für viele Echtzeit- oder Anfrage/Antwort-Protokolle praktisch. Der UDP-Header ist sehr klein und enthält im Wesentlichen Quellport, Zielport, Länge und Checksumme.

4.4 Keine eingebaute Zuverlässigkeit #

UDP bietet von sich aus nicht:

• keine Bestätigungen
• keine Wiederholungen
• keine geordnete Zustellung
• keine Flusskontrolle
• keine Überlastkontrolle wie TCP

Das bedeutet aber nicht, dass UDP „schlecht“ ist. Es bedeutet nur, dass die Anwendung oder ein höheres Protokoll diese Logik selbst ergänzen muss, falls nötig.

4.5 Warum UDP trotzdem extrem wichtig ist #

Gerade weil UDP so schlank ist, eignet es sich hervorragend für Situationen, in denen geringe Latenz wichtiger ist als perfekte Zuverlässigkeit.

Beispiele:

• DNS-Anfragen: klein, schnell, oft lieber neuer Versuch als komplexer Verbindungsaufbau
• VoIP / Videokonferenz: ein altes Paket ist oft wertlos; Echtzeit zählt mehr
• Online-Gaming: aktuelle Positionsdaten sind wichtiger als perfekte Nachlieferung alter Zustände
• Streaming / Telemetrie / Sensorik
• QUIC: baut moderne Zuverlässigkeits- und Sicherheitsmechanismen selbst auf UDP auf

5. Vergleich auf einen Blick #

5.1 Kurzvergleich #

Die Unterschiede ergeben sich direkt aus den Spezifikationen von TCP und UDP.

5.2 Merksatz #

TCP = sicherer, kontrollierter, schwergewichtiger
UDP = einfacher, schneller, leichter

6. Header und Protokollaufbau #

6.1 UDP-Header #

UDP hat einen sehr kleinen Header mit nur vier Grundfeldern:

• Source Port
• Destination Port
• Length
• Checksum

Genau diese vier Felder definiert RFC 768. Das ist ein Hauptgrund für den geringen Overhead.

Vereinfacht:

0      15 16     31
+--------+--------+
| Source | Dest   |
| Port   | Port   |
+--------+--------+
| Length | Check  |
|        | sum    |
+--------+--------+

6.2 TCP-Header #

TCP besitzt deutlich mehr Felder, unter anderem für:

• Source/Destination Port
• Sequence Number
• Acknowledgment Number
• Data Offset
• Flags/Control Bits
• Window
• Checksum
• Urgent Pointer
• Optionen

Diese zusätzliche Struktur ist nötig, um Verbindungszustand, Reihenfolge, Bestätigungen und Steuerung abzubilden. RFC 9293 beschreibt TCP entsprechend umfassend; die modernen Control Bits wurden gegenüber RFC 793 im Laufe der Zeit fortgeführt und konsolidiert.

Vereinfacht:

+-------------------------------+
| Source Port | Destination Port|
+-------------------------------+
| Sequence Number               |
+-------------------------------+
| Acknowledgment Number         |
+-------------------------------+
| Offset | Flags | Window       |
+-------------------------------+
| Checksum | Urgent Pointer     |
+-------------------------------+
| Options (optional)            |
+-------------------------------+
| Data ...                      |
+-------------------------------+

7. Warum TCP oft langsamer wirkt #

TCP ist nicht „langsam“, aber es hat mehr Aufgaben:

1. Verbindungsaufbau
2. Sequenzierung
3. Bestätigungen
4. Wiederholungen bei Verlust
5. Flusskontrolle
6. Überlastkontrolle

Diese Mechanismen kosten Zeit und Headerplatz, erhöhen aber die Zuverlässigkeit massiv. UDP spart genau diesen Aufwand ein. Deshalb fühlt es sich oft schneller an, vor allem bei kleinen, einmaligen oder zeitkritischen Daten.

Wichtig: In realen Netzen ist „schneller“ nicht immer dasselbe wie „besser“. Eine korrupt oder unvollständig geladene Datei ist wertlos. Ein verlorenes Sprachpaket in einem Live-Call dagegen oft verkraftbar.

8. Typische Einsatzgebiete #

8.1 Typische TCP-Anwendungen #

Web und HTTPS #

Traditionell laufen HTTP/1.1 und HTTP/2 über TCP. Für Webseiten ist zuverlässige, vollständige Übertragung entscheidend: fehlende Bytes machen HTML, CSS, JavaScript oder Dateien unbrauchbar.

Dateiübertragung #

Dateien müssen bitgenau vollständig ankommen. TCP eignet sich deshalb für klassische Dateiübertragungen hervorragend.

E-Mail #

E-Mail-Protokolle übertragen strukturierte Daten, die nicht teilweise verloren gehen dürfen.

Datenbanken und APIs #

Anfragen und Antworten müssen vollständig und korrekt eintreffen.

8.2 Typische UDP-Anwendungen #

DNS #

UDP passt gut für kurze Anfrage/Antwort-Muster mit möglichst wenig Verzögerung. RFC 768 beschreibt genau die datagrammbasierte Natur, die solche Einsatzzwecke begünstigt.

VoIP und Videokonferenzen #

Ein verspätetes Paket ist oft nutzlos. Hier ist es besser, kleine Verluste zu tolerieren als auf Wiederholungen zu warten.

Online-Gaming #

Spielzustände ändern sich ständig. Die aktuellste Information ist wichtiger als perfekte Vollständigkeit alter Informationen.

QUIC / HTTP/3 #

Moderne Protokolle wie QUIC laufen auf UDP und bringen Zuverlässigkeit, Multiplexing, Sicherheit und Verlustbehandlung selbst mit. RFC 9000 definiert QUIC ausdrücklich als „UDP-Based Multiplexed and Secure Transport“.

9. Praxisbeispiele #

9.1 Beispiel: Datei herunterladen #

Du lädst ein ISO-Image oder ein ZIP-Archiv herunter.

Anforderung:

• kein Byte darf fehlen
• Reihenfolge muss stimmen
• Fehler müssen korrigiert werden

Geeignet: TCP

Denn:

• verlorene Segmente werden neu gesendet
• Daten werden in korrekter Reihenfolge geliefert
• der Empfänger bekommt einen vollständigen Stream

9.2 Beispiel: Videotelefonie #

Du bist in einem Live-Call.

Anforderung:

• sehr geringe Verzögerung
• einzelne Paketverluste sind akzeptabel
• alte Pakete nachzuliefern bringt wenig

Geeignet: häufig UDP-basierte Verfahren

Denn:

• aktuelle Daten sind wichtiger als perfekte Wiederherstellung
• Wiederholungen würden die Latenz erhöhen

9.3 Beispiel: DNS-Namensauflösung #

Der Client fragt: „Welche IP gehört zu example.org?“

Anforderung:

• kurze Nachricht
• schnelle Antwort
• lieber bei Bedarf erneut fragen

Geeignet: oft UDP

9.4 Beispiel: Chat-System #

Ein Chat kann unterschiedlich gebaut sein.

• klassische zuverlässige Chat-Nachrichten → gut mit TCP
• Live-Präsenzdaten, Tippindikatoren, Game-State → oft gut mit UDP oder UDP-basierten Protokollen

10. TCP-Handshakes, Verbindungsabbau und Zustände #

10.1 Aufbau #

Wie oben erwähnt:

1. Client sendet SYN
2. Server antwortet SYN-ACK
3. Client bestätigt mit ACK

Danach ist die TCP-Verbindung etabliert. TCP verwaltet dafür definierte Zustände; die Zustandsmaschine ist ein wesentlicher Bestandteil der Spezifikation.

10.2 Abbau #

Der Verbindungsabbau erfolgt typischerweise mit FIN/ACK in mehreren Schritten. Auch das zeigt: TCP ist ein zustandsbehaftetes Protokoll.

UDP braucht das alles nicht. Ein Prozess kann jederzeit ein Datagramm senden und wieder aufhören.

11. Reihenfolge, Verlust, Duplikate #

11.1 TCP #

TCP kümmert sich aktiv um:

• Reihenfolge
• Verlusterkennung
• Neuübertragung
• Duplikatbehandlung

Das macht TCP für viele geschäftskritische Anwendungen ideal.

11.2 UDP #

UDP kümmert sich nicht aktiv darum. Das bedeutet:

• Datagramme können verloren gehen
• Datagramme können vertauscht ankommen
• Datagramme können doppelt ankommen

Falls eine Anwendung das nicht tolerieren kann, muss sie selbst Mechanismen dafür entwickeln.

Beispiel eines einfachen eigenen Protokolls über UDP:

Nachricht:
[Nachrichten-ID][Zeitstempel][Payload]Empfänger:
- verwirft doppelte IDs
- ignoriert zu alte Zeitstempel
- bestätigt optional den Empfang

So bauen viele Echtzeitprotokolle oder Spiele ihre eigene Logik über UDP.

12. Latenz vs. Zuverlässigkeit #

Das ist die vielleicht wichtigste praktische Abwägung.

TCP bevorzugt Zuverlässigkeit #

Bei Verlust wird neu gesendet. Das ist gut für Korrektheit, kann aber Verzögerung erhöhen.

UDP bevorzugt Frische #

Verlorene Pakete werden oft einfach hingenommen. Das ist gut für Echtzeit, kann aber Qualitätseinbußen verursachen.

Faustregel #

• Ist jede Information wertvoll, auch verspätet? → eher TCP
• Ist nur die neueste Information wertvoll? → eher UDP

13. Head-of-Line-Blocking und moderne Entwicklungen #

Bei TCP kann ein verlorenes Segment spätere Daten ausbremsen, weil die Anwendung den Stream geordnet erhält. Dieses Verhalten ist einer der Gründe, warum moderne Transportprotokolle wie QUIC über UDP entwickelt wurden. QUIC bringt eigene Mechanismen für Zuverlässigkeit und Multiplexing mit und ist als UDP-basiertes Transportprotokoll standardisiert.

Das ist ein wichtiger Praxispunkt:
UDP bedeutet nicht automatisch „unzuverlässige Anwendung“.
Es bedeutet nur, dass die Zuverlässigkeit nicht direkt von UDP selbst bereitgestellt wird, sondern gegebenenfalls auf einer höheren Ebene.

14. Sicherheit #

Weder TCP noch UDP sind für sich allein ein vollständiger Sicherheitsmechanismus.

• Über TCP wird oft TLS verwendet, etwa bei HTTPS
• Über UDP können ebenfalls sichere Protokolle laufen, zum Beispiel QUIC, das eigene Sicherheitsmechanismen mitbringt

Wichtig ist also:
Sicherheit ist meist Sache eines darüberliegenden Protokolls, nicht von TCP oder UDP allein.

15. Ports bei TCP und UDP #

Sowohl TCP als auch UDP verwenden Portnummern, um Dienste und Anwendungen auf einem Host zu adressieren. Ein Server kann also gleichzeitig:

• TCP Port 443 für HTTPS
• UDP Port 443 für QUIC/HTTP/3

verwenden, weil Protokoll und Port zusammen betrachtet werden. UDP- und TCP-Portfelder sind jeweils im Header definiert.

16. Häufige Missverständnisse #

„UDP ist immer schneller“ #

Nicht pauschal. UDP hat weniger Overhead, aber die Anwendung muss eventuell Verluste, Reihenfolge oder Wiederholungen selbst lösen. Je nach Szenario kann das Gesamtsystem komplexer werden.

„TCP ist immer besser“ #

Auch nicht. Für Echtzeitdaten kann TCP ungeeignet sein, weil verspätete Wiederholungen mehr schaden als helfen.

„UDP ist unsicher“ #

UDP ist nicht per se unsicherer als TCP. Sicherheit hängt meist vom darüberliegenden Protokoll ab.

„TCP hat Nachrichten“ #

Nicht direkt. TCP liefert einen Byte-Stream, keine bewahrten Nachrichtengrenzen.

„UDP ist nur für kleine Spielereien“ #

Falsch. UDP ist Grundlage sehr wichtiger realer Systeme, darunter DNS, Echtzeitkommunikation und moderne Protokolle wie QUIC.

17. Anschauliche Analogie #

TCP wie ein Einschreiben mit Sendungsverfolgung #

Du willst sicherstellen, dass alles vollständig und nachweisbar ankommt.

• Empfang wird bestätigt
• fehlende Teile werden nachgesendet
• Reihenfolge bleibt nachvollziehbar

UDP wie Zurufe über Funk #

Du rufst Informationen schnell rüber.

• sehr direkt
• wenig Formalität
• manche Informationen gehen verloren
• dafür extrem schnell und unkompliziert

Diese Analogie ist technisch nicht perfekt, trifft aber den Charakter gut.

18. Beispiel mit derselben Anwendungsidee #

Stell dir eine Tracking-Anwendung vor, die jede Sekunde GPS-Daten sendet.

Mit TCP #

• jede Nachricht soll ankommen
• bei Verlust wird nachgesendet
• aber ältere Positionsdaten können sich aufstauen
• die Anzeige hinkt eventuell hinterher

Mit UDP #

• jede Sekunde wird einfach der neueste Standort gesendet
• verlorene Daten werden ignoriert
• dafür bleibt die Anzeige aktuell

Für Live-Tracking ist UDP oft attraktiver, sofern kleine Verluste tolerierbar sind.

19. Vor- und Nachteile #

TCP – Vorteile #

• zuverlässige Zustellung
• geordnete Datenlieferung
• Wiederholungen bei Verlust
• Flusskontrolle
• Überlastkontrolle
• ideal für korrekte, vollständige Datenübertragung

TCP – Nachteile #

• höherer Overhead
• Verbindungsaufbau nötig
• höhere Latenz in manchen Szenarien
• Stream-Modell erfordert Nachrichtenrahmung in der Anwendung

UDP – Vorteile #

• sehr schlank
• geringer Overhead
• kein Verbindungsaufbau
• gut für Echtzeit und einfache Datagramm-Kommunikation
• Nachrichtengrenzen bleiben erhalten

UDP – Nachteile #

• keine garantierte Zustellung
• keine garantierte Reihenfolge
• keine automatische Wiederholung
• Anwendung muss bei Bedarf selbst Zusatzlogik liefern

Diese Eigenschaften ergeben sich direkt aus der jeweiligen Protokolldefinition.

20. Technische Entscheidungshilfe #

Eher TCP, wenn … #

• Vollständigkeit wichtiger ist als minimale Latenz
• Daten geordnet ankommen müssen
• Fehlerkorrektur automatisch erfolgen soll
• Anwendungen klassisch request/response oder dateibasiert arbeiten

Eher UDP, wenn … #

• sehr geringe Latenz entscheidend ist
• kleine Verluste tolerierbar sind
• Nachrichtengrenzen nützlich sind
• die Anwendung selbst Zuverlässigkeitslogik bauen kann oder gar nicht braucht

21. Mini-Entscheidungsmatrix #

22. TCP und UDP in der modernen Praxis #

Früher war die Faustregel oft sehr simpel:

• Web = TCP
• Echtzeit = UDP

Heute ist es etwas spannender:

• klassisches HTTPS kann TCP-basiert sein
• HTTP/3 verwendet QUIC
• QUIC läuft über UDP
• QUIC bringt aber wieder eigene Zuverlässigkeit und Steuerung mit

Das zeigt sehr schön:
Die eigentliche Designfrage lautet nicht nur TCP oder UDP, sondern oft eher:
Welche Transporteigenschaften braucht die Anwendung wirklich?

23. Fazit #

TCP und UDP lösen dasselbe Grundproblem auf zwei sehr unterschiedliche Arten:

• TCP liefert einen zuverlässigen, geordneten, kontrollierten Transport
• UDP liefert einen einfachen, schnellen, verbindungslosen Datagramm-Transport

Darum gibt es kein allgemeines „besser“. Es gibt nur passender für den jeweiligen Einsatzzweck.

In einem Satz: #

• TCP für Korrektheit und Vollständigkeit
• UDP für Geschwindigkeit, Einfachheit und Echtzeitnähe

24. Sehr kurze Zusammenfassung für ganz oben im Wiki #

TCP ist verbindungsorientiert, zuverlässig und geordnet, aber schwergewichtiger.
UDP ist verbindungslos, leichtgewichtig und schnell, aber ohne eingebaute Garantie für Zustellung oder Reihenfolge.
Deshalb nutzt man TCP meist für Web, Dateien und APIs, UDP dagegen oft für DNS, Echtzeitkommunikation, Gaming und moderne UDP-basierte Transporte wie QUIC.

25. Kompakte ASCII-Grafik für dein Wiki #

TCP
---
Verbindung aufbauen  -> ja
Zustellung garantiert -> ja
Reihenfolge garantiert -> ja
Wiederholungen         -> ja
Flow Control           -> ja
Congestion Control     -> ja
Typisch für            -> Web, Dateien, APIsUDP
---
Verbindung aufbauen  -> nein
Zustellung garantiert -> nein
Reihenfolge garantiert -> nein
Wiederholungen         -> nein
Flow Control           -> nein
Congestion Control     -> nicht eingebaut wie bei TCP
Typisch für            -> DNS, VoIP, Gaming, QUIC als Basis

26. Quellen #

• UDP ist in RFC 768 als datagrammbasiertes Transportprotokoll definiert.
• TCP ist historisch in RFC 793 beschrieben und modern konsolidiert in RFC 9293, das TCP als aktuellen Internet-Standard zusammenfasst.
• QUIC ist in RFC 9000 als UDP-basiertes Transportprotokoll spezifiziert.