TCP und UDP sind die beiden dominierenden Transportprotokolle des Internets. Beide bewegen Daten zwischen Endpunkten, aber sie tun es mit völlig unterschiedlicher Philosophie: TCP setzt auf Verbindungsaufbau, Ordnung und Zuverlässigkeit; UDP auf minimale Latenz und geringen Overhead. In diesem Leitfaden bekommst du eine strukturierte, tiefgehende und praxisnahe Übersicht – von Aufbau und Headern über Fluss- und Staukontrolle bis hin zu konkreten Einsatzszenarien und Entscheidungshilfen.
Die Transportschicht (Layer 4) im Überblick
Die Transportschicht ist die Brücke zwischen Anwendungen (z. B. Webserver, VoIP, Spiele) und der darunterliegenden Internetschicht (IP). Sie kümmert sich – je nach Protokoll – um:
- Segmentierung/Fragmentierung: Zerlegen der Anwendungsdaten in Pakete/Segmente.
- Ende-zu-Ende-Transport: Zustellung zwischen Quell- und Zielprozess mittels Ports.
- Fehlererkennung: Prüfsummen in TCP und UDP.
- Flusskontrolle: Verhindern, dass Sender den Empfänger überlastet (TCP).
- Verbindungsmanagement: Auf-, Abbau und Überwachung von Sessions (TCP).
Merke: Layer 4 stellt Prozesse auf Endsystemen einander zu. Ports sind dabei die Adressen auf Anwendungsebene – typischerweise Source Port und Destination Port.
Fundamentale Unterschiede: Verbindungsorientiert vs. verbindungslos
Die grundlegende Unterscheidung prägt alle weiteren Eigenschaften:
- TCP: Verbindungsorientiert, zuverlässig, geordnet. Vor dem Datentransfer erfolgt ein Drei-Wege-Handshake. Pakete werden bestätigt (ACK), neu angefordert (Retransmit) und korrekt zusammengesetzt. Fluss- und Staukontrolle sind integraler Bestandteil.
- UDP: Verbindungslos, „best effort“, ungeordnet. Keine Handshakes, keine Bestätigungen, keine automatische Neuübertragung. Minimaler Overhead für maximale Geschwindigkeit und niedrige Latenz – auf Kosten potenzieller Paketverluste oder vertauschter Reihenfolge.
| Eigenschaft | TCP | UDP |
|---|---|---|
| Verbindungsmodus | Verbindungsorientiert (Handshake) | Verbindungslos (kein Handshake) |
| Zuverlässigkeit | Ja (ACK, Retransmit, Ordnung) | Nein (Anwendung muss es ggf. selbst lösen) |
| Header-Overhead | Mindestens 20 Byte (plus Optionen) | 8 Byte fest |
| Latenz | Höher (Handshake, ACKs, Steuerung) | Niedrig (direktes Senden, kein ACK) |
| Stau-/Flusskontrolle | Integriert (Sliding Window, Congestion Control) | Nicht vorhanden (muss Anwendung/Netz machen) |
| Broadcast/Multicast | Nicht unterstützt | Unterstützt |
| Typische Use Cases | HTTP(S), E-Mail, Dateiübertragung, APIs | DNS, VoIP, Streaming, Online-Games, Tunneling |
TCP im Detail: Zuverlässiger Transport mit Kontrolle
Drei-Wege-Handshake: Verbindungsaufbau
Bevor Daten fließen, synchronisiert TCP beide Endpunkte mit einem standardisierten Ablauf:
- SYN: Client → Server: Verbindungswunsch mit Initial Sequence Number (ISN).
- SYN-ACK: Server → Client: Bestätigung und eigene ISN.
- ACK: Client → Server: Bestätigung des Servers – Verbindung steht.
| Schritt | Sender | Empfänger | Flags | Zweck |
|---|---|---|---|---|
| 1 | Client | Server | SYN | Start der Verbindung, ISN des Clients |
| 2 | Server | Client | SYN, ACK | Server bestätigt und sendet eigene ISN |
| 3 | Client | Server | ACK | Client bestätigt – Datenübertragung kann beginnen |
Praxis-Tipp: Der Handshake dient auch zur RTT-Schätzung und zur Aushandlung von Optionen (z. B. MSS, Window Scaling, SACK). Firewalls/NATs lernen hier typischerweise den Zustand (stateful inspection).
TCP-Header und Flags
Ein typischer TCP-Header ist mindestens 20 Byte groß. Optionen können ihn erweitern (z. B. für MSS, Window Scaling, SACK).
| Feld | Größe | Beschreibung |
|---|---|---|
| Source Port | 16 Bit | Quellprozess |
| Destination Port | 16 Bit | Zielprozess |
| Sequence Number | 32 Bit | Position im Datenstrom, Ordnungssicherung |
| Acknowledgement Number | 32 Bit | Nächste erwartete Byte-Sequenz (kumulativ) |
| Header Length | 4 Bit | Größe des TCP-Headers |
| Flags (URG, ACK, PSH, RST, SYN, FIN) | 6 Bit | Steuerbits für Kontrolle/Status |
| Window Size | 16 Bit | Empfangsfenster (Flusskontrolle) |
| Checksum | 16 Bit | Fehlererkennung (Header + Daten + Pseudo-Header) |
| Urgent Pointer | 16 Bit | Position dringender Daten (selten genutzt) |
| Options | variabel | MSS, Window Scaling, SACK, Timestamps u. a. |
- SYN: Aufbau und Synchronisation.
- ACK: Bestätigungen (kumulativ).
- FIN: Geordneter Abbau einer Richtung (Half-Close).
- RST: Sofortiges Zurücksetzen (Fehler/Inkonsistenz).
- PSH: „Push“ – sofort an die Anwendung weiterreichen.
- URG: Dringende Daten; veraltet/selten.
Segmentgröße, MSS und MTU
Auf Ethernet mit 1.500-Byte-MTU bleibt – ohne Optionen – bei IPv4 üblicherweise eine MSS (Maximum Segment Size) von 1.460 Byte für die TCP-Nutzlast (1.500 − 20 Byte IP-Header − 20 Byte TCP-Header). Größere MSS sind bei größeren MTUs (Jumbo Frames) möglich. Die richtige MSS verhindert Fragmentierung und reduziert Retransmission-Kosten bei Verlusten.
Flusskontrolle: Sliding Window
Die Window Size teilt dem Sender mit, wie viele Bytes der Empfänger ohne weitere Bestätigung puffern kann. Das Fenster „rutscht“ mit jedem ACK voran:
- Sender darf bis zur Fenstergröße senden, ohne auf ACKs zu warten.
- Empfänger bestätigt kumulativ (z. B. ACK=501 bedeutet: Alles bis Byte 500 ist angekommen).
- Fenstergröße kann dynamisch variieren (Empfängerlast, Pufferstatus).
Merke: Flusskontrolle ist endpunktbezogen (Empfänger-Kapazität), Staukontrolle ist netzbezogen (Überlast im Netz). Beides sind unterschiedliche Mechanismen.
Staukontrolle: Vom Slow Start bis Fast Recovery
TCP drosselt oder steigert die Sendeleistung abhängig von Verlusten/Latenz, um Netzüberlast zu vermeiden. Klassische Phasen und Mechanismen:
- Slow Start: Exponentielle Erhöhung des Congestion Window (cwnd) bis zu einem Schwellwert.
- Congestion Avoidance: Lineares Wachstum, um Staus sanfter zu umschiffen.
- Fast Retransmit: Schnelle Neuübertragung bei mehrfachen Duplikat-ACKs (ohne auf Timeout zu warten).
- Fast Recovery: Schnellere Erholung nach erkannten Verlusten ohne kompletten Neustart.
Diese Logik sorgt für Fairness im Netz und verhindert, dass einzelne Verbindungen den verfügbaren Durchsatz „überfahren“.
Fehlererkennung und Retransmission
TCP berechnet eine Checksumme über Header und Nutzdaten (plus Pseudo-Header). Bei Fehlern verwirft der Empfänger das Segment. Bleibt das ACK aus, sendet der Sender nach Timeout neu. Selective Acknowledgements (SACK) verbessern dabei die Effizienz, indem sie Lücken im Empfang explizit markieren und gezielt einzelne Segmente erneut anfordern.
Verbindungsabbau (Vier-Wege-Sequenz)
Da TCP duplex ist, beendet jede Richtung separat:
- FIN → ACK (Richtung A beendet Senden; B bestätigt)
- FIN → ACK (Richtung B beendet Senden; A bestätigt)
Dieses Vier-Paket-Muster stellt sicher, dass beide Seiten alle Daten vollständig erhalten, bevor die Verbindung freigegeben wird.
UDP im Detail: Schlank, schnell, minimalistisch
UDP-Header und Datagramm-Struktur
UDP hat einen festen 8-Byte-Header – das reduziert Overhead und Latenz.
| Feld | Größe | Beschreibung |
|---|---|---|
| Source Port | 16 Bit | Optional (kann 0 sein, wenn keine Antwort erwartet wird) |
| Destination Port | 16 Bit | Zielprozess |
| Length | 16 Bit | Gesamtlänge (Header + Daten) |
| Checksum | 16 Bit | Fehlererkennung; bei IPv4 optional (0 = nicht genutzt), bei IPv6 verpflichtend |
Größen und Grenzen
- Theoretische Maximalgröße des UDP-Datagramms: 65.535 Byte (inkl. UDP-Header).
- Praktische Obergrenze bei IPv4 für Nutzdaten: ca. 65.507 Byte (65.535 − 20 Byte IP-Header − 8 Byte UDP-Header).
- Realität im Ethernet: MTU 1.500 Byte → viel kleinere effektive Nutzdaten pro Paket. Größere Pakete führen zu IP-Fragmentierung und erschweren Fehlerbehandlung.
Kein Verbindungsaufbau, keine Garantien
UDP sendet einfach. Es gibt keine Reihenfolgegarantie, keine Duplikatunterdrückung, keine Neuübertragungen. Das ist ideal, wenn du unmittelbare Reaktion brauchst und ein paar Verluste verkraftbar sind (z. B. Live-Streaming, Sprachpakete).
Broadcast und Multicast
UDP kann ein Paket an viele Empfänger liefern (Broadcast/Multicast). Das ist für Dienste wie Service-Discovery oder Live-Übertragungen nützlich. TCP kann das nicht.
Praxis-Tipp: Wenn du über UDP selbst Zuverlässigkeit brauchst, kannst du auf Anwendungsebene Bestätigungen, Sequenznummern, (selektive) Retransmissions und FEC (Forward Error Correction) hinzufügen – mit exakt auf deinen Use Case abgestimmter Logik.
Bandbreite, Latenz, Overhead: Wie sich TCP und UDP in der Praxis verhalten
- Bandbreiten-Nutzung: TCP verschickt neben den Nutzdaten regelmäßig ACKs und verwaltet Zustände (Übertragungsfenster, Retransmits). Dieser Zusatztraffic erhöht den Overhead. UDP ist „nackt“ und benötigt keine Bestätigungen – das senkt Protokolloverhead.
- Latenz: TCP hat initiale Verzögerung (Handshake) und kann bei Verlusten warten (bis Retransmit/ACK). UDP startet sofort und ignoriert Verluste – in Latenz-sensitiven Szenarien ein Vorteil.
- Jitter: TCPs Nachlieferungen (Retransmits) und Ordnungsgarantien können variable Verzögerungen einführen. UDP hat meist geringeren Jitter, sofern das Netz nicht überlastet ist.
| Kriterium | TCP | UDP |
|---|---|---|
| Startverzögerung | Handshake erforderlich | Keine – sofortiges Senden |
| Overhead pro Paket | ≥ 20 Byte + Optionen, plus ACK-Traffic | 8 Byte, keine ACKs |
| Verhalten bei Verlust | Neuübertragung, geordnete Zustellung | Keine Neuübertragung – Anwendung entscheidet |
| Durchsatzsteuerung | Automatisch (Congestion + Flow Control) | Keine – muss extern/asymmetrisch erfolgen |
Typische Anwendungen: Wann was einsetzen?
Du wählst das Protokoll nach den Anforderungen deiner Anwendung: Integrität und Ordnung vs. Geschwindigkeit und Toleranz gegenüber Verlusten.
| Anwendung | Bevorzugtes Protokoll | Begründung |
|---|---|---|
| Web (HTTP/HTTPS), APIs | TCP | Geordnete, vollständige Übertragung – jeder Byte zählt |
| E-Mail (SMTP, IMAP, POP3) | TCP | Zuverlässigkeit hat Vorrang |
| Dateiübertragung (FTP/SFTP) | TCP | Integrität und Vollständigkeit sind zwingend |
| DNS-Abfragen | UDP (meist) | Kurz, klein, verlusttolerant; Wiederholungen billig |
| VoIP, Video-Calls | UDP | Niedrige Latenz wichtiger als perfekte Vollständigkeit |
| Live-Streaming | UDP | Kontinuierlicher Fluss wichtiger als Retransmits |
| Online-Gaming | UDP | Sofortige Reaktion hat Priorität, Verluste tolerierbar |
| VPN-Tunnel | UDP | Kein doppeltes TCP-in-TCP; geringerer Overhead |
Hinweis: Auch innerhalb einer Anwendung sind Mischmodelle sinnvoll: Steuerdaten über TCP, Echtzeit-Medien über UDP. Oder moderne Lösungen wie QUIC (über UDP), die Zuverlässigkeit, Verschlüsselung und Handshake-Optimierung kombinieren.
Sicherheit: Fehlererkennung vs. Vertraulichkeit
- Fehlererkennung: Sowohl TCP als auch UDP besitzen Prüfsummen. TCP geht weiter: Ordnung, ACKs und Retransmissions sichern die Datenintegrität auf Transportebene.
- Keine Verschlüsselung per se: Weder TCP noch UDP verschlüsseln. Für Vertraulichkeit/Integrität im kryptografischen Sinn brauchst du TLS (über TCP) oder DTLS (über UDP). Moderne Protokolle wie QUIC integrieren Verschlüsselung standardmäßig.
NAT, Firewalls und QoS: Betriebsaspekte
- Stateful Firewalls: TCP-Verbindungen sind leicht zu tracken (Handshake, Flags). UDP erfordert heuristische Zeitfenster, da es keinen Zustand auf Protokollebene gibt – dadurch können UDP-Flows schneller „vergessen“ werden, wenn Keepalives fehlen.
- NAT: UDP-Mappings in NATs haben oft kurze Timeouts. Regelmäßige Keepalives sind Pflicht bei andauernden UDP-Flows (VoIP, Games).
- QoS: Echtzeitverkehr (UDP) profitiert von Priorisierung (DSCP/CoS), um Jitter zu reduzieren.
Skalierbarkeit und Architektur
- TCP: Pro Verbindung hält der Server Zustand (Puffer, Fenster, Retransmit-Queue). Das kostet Speicher und CPU – ist aber für transaktionale Dienste hervorragend handhabbar und kontrollierbar.
- UDP: Verbindungslos bedeutet weniger per-Flow-Overhead auf Server-Seite. Das ist für sehr viele parallele, leichte Anfragen (z. B. DNS) attraktiv – erfordert aber Stabilität und Robustheit in der Anwendung, um Verluste/Spikes zu managen.
Entscheidungshilfe: So wählst du zwischen TCP und UDP
- Benötigst du geordnete, vollständige Zustellung und willst möglichst wenig Logik in der Anwendung? → TCP.
- Benötigst du niedrigste Latenz und tolerierst einzelne Verluste? → UDP.
- Viele gleichzeitige Empfänger (Broadcast/Multicast)? → UDP.
- Willst du Verschlüsselung + geringe Latenz + Zuverlässigkeit ohne TCP-Handshakes? → Schau dir QUIC über UDP an.
| Anforderung | Empfehlung | Begründung |
|---|---|---|
| Datei/Transaktion muss 100% korrekt ankommen | TCP | Transportseitige Integrität, Neuübertragungen, Ordnung |
| Interaktive, latenzkritische Kommunikation | UDP | Kein Handshake/ACK-Overhead, Latenz minimal |
| Skalierung auf viele Empfänger gleichzeitig | UDP | Broadcast/Multicast möglich |
| Firewall/NAT-Durchdringung mit robustem Zustand | TCP | Einfacheres State-Tracking, längere Timeouts |
| Moderne Web-Low-Latency mit Security | QUIC (UDP) | 0-RTT-Optionen, integrierte Verschlüsselung, Verlustresilienz |
Merke: „TCP vs. UDP“ ist selten ein Entweder-oder. Häufig ist es ein Sowohl-als-auch – je nach Datenklasse im selben System.
Häufige Missverständnisse – kurz erklärt
- „UDP ist unsicher, TCP ist sicher“: Falsch im Sinne von Kryptografie. Beide sind unverschlüsselt. Sicherheit bieten TLS/DTLS/QUIC.
- „UDP ist immer schneller“: Nicht zwingend. Bei Verlusten und Fragmentierung kann UDP ineffizient sein. In sauberen, latenzsensitiven Netzen ist es jedoch oft überlegen.
- „TCP ist immer zuverlässig“: Sofern die Verbindung besteht, ja. Aber anhaltende Störungen können zu Abbrüchen führen. Zudem begrenzen Congestion-Mechanismen den Durchsatz.
Implementierungs- und Betriebs-Tipps
- TCP: Achte auf MSS/MTU-Anpassung, Window Scaling in Hochlatenz-Hochdurchsatz-Strecken, sowie auf sinnvolle Puffergrößen. Beachte Interaktionen wie Nagle’s Algorithmus und Delayed ACKs.
- UDP: Implementiere – falls nötig – Sequenznummern, optionale ACKs, FEC oder adaptive Bitraten. Sende regelmäßige Keepalives bei NAT/Firewall.
- Monitoring & Debugging: Mit tcpdump oder Wireshark Header/Flags analysieren; Metriken wie RTT, Retransmits, Out-of-Order, Jitter und Lossrate beobachten.
Fazit
TCP und UDP adressieren unterschiedliche Anforderungen: TCP liefert dir verlässlichen, geordneten Byte-Strom mit integrierter Fluss- und Staukontrolle – ideal für Integrität, Dateien, Web und APIs. UDP ist radikal schlank, verzichtet bewusst auf Bestätigungen und setzt auf Geschwindigkeit – top für Echtzeit, Streaming, Gaming und Multicast-Szenarien. Wähle das Protokoll entlang deiner Prioritäten: Datenintegrität und Ordnung → TCP, minimale Latenz und Verlusttoleranz → UDP. In komplexen Systemen kombinierst du beides – oder setzt auf QUIC über UDP, wenn du geringe Latenz, moderne Verschlüsselung und zuverlässige Übertragung in einem Paket willst. So nutzt du die Stärken beider Welten gezielt aus.
FAQ: Die wichtigsten Fragen zu TCP und UDP
Ist UDP wirklich „schneller“ als TCP?
UDP hat weniger Overhead (kein Handshake, keine ACKs) und daher potenziell geringere Latenz. In stabilen Netzen ist es oft schneller für Echtzeitdaten. Bei Verlusten oder Fragmentierung kann der Vorteil schrumpfen oder kippen.
Wofür steht TCPs „Zuverlässigkeit“ konkret?
Zuverlässigkeit bedeutet: geordnete Zustellung, Neuübertragung bei Verlust, Erkennung von Duplikaten, Fehlerprüfung per Checksumme und Bestätigungen (ACK). Das entlastet die Anwendung.
Kann ich UDP „zuverlässig“ machen?
Ja, auf Anwendungsebene: Füge Sequenznummern, Bestätigungen, Retransmits und ggf. FEC hinzu. Vorteil: Du regelst genau, was wie zuverlässig sein muss – flexibel und oft effizienter als TCP für spezielle Echtzeit-Workloads.
Warum nutzen DNS-Anfragen meist UDP?
Weil sie klein, kurz und verlusttolerant sind. Geht eine Anfrage verloren, wird sie erneut gesendet. Bei großen Antworten oder speziellen Fällen weicht DNS auf TCP aus.
Warum ist UDP manchmal durch Firewalls/NAT problematisch?
UDP ist zustandslos. Viele Geräte halten UDP-Mappings nur kurz. Ohne Keepalives „vergisst“ das NAT die Zuordnung, und eingehende Antworten verwirft die Firewall.
Wie groß darf ein UDP-Paket sein – und soll ich das ausnutzen?
Maximal etwa 65.507 Byte UDP-Nutzdaten bei IPv4. In der Praxis solltest du dich an die MTU (z. B. 1.500 Byte) halten, um Fragmentierung zu vermeiden – sonst steigen Verlust- und Retry-Risiken.
Was ist der Unterschied zwischen Flusskontrolle und Staukontrolle in TCP?
Flusskontrolle schützt den Empfänger (Pufferkapazität). Staukontrolle schützt das Netz vor Überlast (Verluste/Latenzen signalisieren Drosselungsbedarf).
Welche Rolle spielen TCP-Flags wie SYN, FIN, RST, PSH?
SYN startet Verbindungen, FIN beendet sie geordnet, RST bricht sie sofort ab, PSH „pusht“ Daten zur Anwendung. ACK bestätigt, URG markiert dringende Daten (heute selten).
Was ist QUIC und wie passt es zu TCP/UDP?
QUIC läuft über UDP, bringt aber Zuverlässigkeit, Verschlüsselung (TLS 1.3) und schnellere Handshakes mit. Ziel: Web- und API-Performance verbessern, ohne die Nachteile klassischer TCP-Handshakes.
Warum ist TCP „teurer“ in Sachen Bandbreite?
Weil TCP zusätzlich zu den Nutzdaten ACKs, Retransmits, Fenster- und Staukontrolle mitführt. Das erhöht Overhead, verhindert aber auch Doppelarbeit und Fehlübertragungen auf Anwendungsebene.
Kann ich für Dateiübertragungen UDP nutzen?
Ja, wenn du die Zuverlässigkeit selbst implementierst – üblich sind aber TCP oder darauf aufbauende Protokolle (SFTP, HTTPS), weil sie diese Aufgabe bereits robust lösen.
Weshalb eignet sich UDP besonders für Broadcast/Multicast?
Weil es verbindungslos ist und ein Paket an mehrere Empfänger adressiert werden kann. TCP kennt nur Punkt-zu-Punkt-Verbindungen und bietet keine eingebaute Multicast-Unterstützung.
Wie erkenne ich in der Praxis TCP- und UDP-Probleme?
Mit Tools wie tcpdump und Wireshark: Achte bei TCP auf Retransmits, Window-Size, DupACKs; bei UDP auf Paketverluste, Jitter und eventuelle Fragmentierung. Metriken wie RTT und Lossrate helfen beim Tuning.