TCP vs. UDP für Entwickler – Wann das Protokoll tatsächlich wichtig ist

Sie bauen ein Mehrspieler-Spiel. Spieler beschweren sich über Verzögerungen. Sie haben Ihren Servercode optimiert, die Anzahl der Datenbankabfragen reduziert und die Latenz bei 99 Prozent ist in Ordnung. Das Problem ist einfacher: Sie verwenden TCP. Das ist alles. Das ist die Verzögerung.

TCP und UDP sind nicht einfach zwei Kästen auf einer Protokollliste – sie repräsentieren grundlegend unterschiedliche Wetten über das Verhalten des Netzwerks. Die falsche Wahl kostet nicht nur Leistung. Sie verändert die Art und Weise, wie Fehler bei Problemen auftreten.

Die Wette, die TCP wagt

TCP verspricht Ihnen einen zuverlässigen, geordneten Bytestrom. Wenn ein Paket verloren geht, wird es von TCP erneut gesendet. Wenn Pakete in falscher Reihenfolge eintreffen, werden sie von TCP neu geordnet. Ihre Anwendung sieht immer saubere, sequenzielle Daten.

Diese Garantie kostet Ihnen drei Dinge:

• Handshake-Verzögerung — TCP erfordert ein dreifaches Handshake, bevor ein einzelnes Byte der Anwendungsdaten bewegt wird. Auf einem Netzwerk mit einer Rundfahrt von 50ms verbrannt man 150ms, bevor der erste Anfrage überhaupt beginnt.
• Head-of-line-Blockierung — Dies ist das, was Spiele tötet. Wenn Paket #5 verloren geht, hält TCP Pakete #6, #7 und #8 in einem Puffer, bis #5 erneut gesendet und eingetroffen ist. Der Strom wird blockiert. Die Positionseingabe des Spielers aus 100ms herunter sitzt in einem Puffer, während das Netzwerk sich selbst sortiert.
• Konfliktsicherheitsüberhead — TCPs Konfliktsicherheitsfensteralgorithmus (CUBIC, BBR usw.) reduziert die Sendgeschwindigkeit, wenn er Verluste erkennt. Auf einem verlustanfälligen Netzwerk bedeutet das, dass TCP die Durchsatzrate genau dann reduziert, wenn das Netzwerk Schwierigkeiten hat – genau jene Zeit, in der Ihre Benutzer es am stärksten spüren.

Was UDP tatsächlich bietet

UDP sendet ein Datagram und schaut nicht zurück. Kein Handshake, keine Bestätigung, keine Wiederholung. Wenn ein Paket verloren geht, ist es verschwunden. Der Empfänger erhält das, was eintritt, in der Reihenfolge, in der es eintritt.

Das ist keine Einschränkung – es ist der Punkt. Wenn Sie mehr Latenz als Liefergarantie benötigen, ermöglicht UDP diese Entscheidung explizit. Die Zuverlässigkeit wird in Ihre Anwendungsschicht verlegt, wo Sie intelligenter Entscheidungen über das, was tatsächlich erneut gesendet werden soll, treffen können.

In einem Spiel ist eine Positionseingabe aus 50ms herunter wertlos – Sie wollen die aktuelle. Mit TCP würden Sie warten und buffer. Mit UDP senden Sie den aktuellen Zustand und überspringen alles Veraltete. Die Erfahrung ist unter höherem Paketverlust glatter.

TCP vs UDP: das wirklich wichtige Vergleich

Eigentum	TCP	UDP
Verbindungsaufbau	Dreifaches Handshake (fördert 1,5× RTT vor dem ersten Byte)	Kein Handshake – sofort starten
Liefergarantie	Ja – Wiederholung bei Verlust	Nein – senden und vergessen
Paketreihenfolge	Verordnet durch die Stack	Ihr Problem
Head-of-line-Blockierung	Ja – ein verlorenes Paket blockiert den Strom	Nein – jedes Datagram ist unabhängig
Konfliktsicherheit	Inbegriffen (CUBIC, BBR usw.)	Keine – implementieren Sie Ihre eigene oder lassen Sie sie weg
Typische Latenzüberhead	150–300ms bei kalten Verbindungen	Sub-millisecond
Anwendungsfälle	HTTP/1.1, HTTP/2, Datenbanken, Dateiübertragung, E-Mail	DNS, Gaming, Live-Video, HTTP/3 (QUIC)

Wo jeder Protokoll tatsächlich gehört

DNS läuft über UDP – und daraus eine Lektion

Jede DNS-Anfrage, die Ihre Anwendung macht, erfolgt standardmäßig über UDP. Die Anfrage passt in ein einziges Paket, die Antwort passt in ein einziges Paket, und Sie erhalten Ihre Antwort in einer Rundfahrt. Kein Handshake-Überhead, kein Zustand, den der Server halten muss.

Wenn die Antwort zu groß ist (DNSSEC-Records, viele A-Records), fällt DNS zurück auf TCP. Aber der häufige Fall – eine Hostnamensuche – ist rein UDP, weil die Abwägung offensichtlich ist: das dreifache Handshake dauert länger als die eigentliche Anfrage.

Sie können dieses Verhalten mit dem IO Tools DNS Lookup Tool — geben Sie einen Domainnamen ein und beobachten Sie, wie schnell einzelne Datentypen gelöst werden. Diese Geschwindigkeit ist UDP, die einen vollständigen Rundfahrt-Handshake-Überhead eliminiert.

Gaming: UDP ist die einzige echte Lösung

Jede große Spielnetzwerk-Bibliothek – Valve’s GameNetworkingSockets, Epics EOS-Transport, Unity’s UTP – basiert auf UDP. Der Grund ist die Head-of-line-Blockierung.

In einem wettbewerbsorientierten FPS senden Sie Positionseingaben alle 64 Ticks – alle 15ms. Wenn ein Paket verloren geht und TCP die nächsten fünf Pakete hält, während es auf eine Wiederholung wartet, haben Sie 75ms Stutter in genau dem falschen Moment eingeführt. Mit UDP senden Sie das nächste Update sofort. Der Client interpoliert über den Abstand. Die Erfahrung ist glatt.

Die meisten Spielnetzwerk-Code, die auf UDP basieren, implementieren ihre eigene selektive Zuverlässigkeit – Sequenznummern, Prioritätsqueues, selektive ACKs – aber nur für Daten, die tatsächlich benötigt werden: Chat-Nachrichten, Gegenstände, Spielzustand. Positionsdaten sind durch Design unzuverlässig. Ein veralteter Wert ist schlimmer als kein Wert.

Video-Streaming: es hängt von der Anwendung ab

Live-Streaming (Twitch, Sportübertragungen) verwendet UDP-basierte Protokolle – RTP, WebRTC, SRT – weil einige verlorene Frames akzeptabel sind, aber Latenz nicht. Sie können nicht 30 Sekunden eines Live-Matches buffer, um eine glatte Lieferung zu gewährleisten.

VOD (Netflix, YouTube) verwendet tatsächlich TCP, weil Buffering die Kosten verdeckt. Ein paar Sekunden Vorab-Buffer machen die TCP-Wiederholungsüberhead unsichtbar – Sie sehen nur glatte Wiedergabe. Die Latenzpenalität spielt keine Rolle, wenn Sie etwas sehen, das gestern stattgefunden hat.

HTTP/3 läuft über UDP – und es verändert die Webperformance

HTTP/3 läuft über QUIC, das über UDP läuft. Google hat QUIC speziell entwickelt, um das Head-of-line-Blockierungsproblem von TCP für Webverkehr zu beheben. Mit HTTP/2 über TCP wird ein verlorenes Paket alle multiplexierten Streams, die diese Verbindung teilen, blockieren. QUIC implementiert Stream-Multiplexing auf Transportebene mit unabhängigen Bestätigungen – ein verlorenes Paket blockiert nur einen Stream, nicht alle.

QUIC integriert auch TLS in den Handshake, reduziert die kalte Verbindungsaufbau auf eine Rundfahrt (0-RTT bei Sitzungserneuerung). Auf verlustanfälligen Netzwerken – Mobilverbindungen, überlastete WiFi – ist dies eine sinnvolle Verbesserung. Bis 2024 unterstützen etwa 30% von Websites HTTP/3und alle großen Browser aktivieren es standardmäßig. Wenn Sie hinter Cloudflare oder einem modernen CDN bereitgestellt sind, servieren Sie wahrscheinlich bereits HTTP/3, ohne es explizit zu konfigurieren.

Die praktische Entscheidungsbaum

Wenn Sie eine Verbindung für ein neues Protokoll oder Dienst wählen, ist die Frage nicht „TCP oder UDP?“ – sondern „welche Fehlern kann ich tolerieren?“

• Jeder Byte muss einreichen, in der richtigen Reihenfolge, sonst scheitert die Operation → TCP. Dateiuploads, Datenbankverbindungen, API-Aufrufe, E-Mail. Verlorene Daten bedeuten korrupte Daten oder einen Parse-Fehler.
• Latenz ist wichtiger als garantierte Lieferung → UDP. Spiele, Live-Video, Sprachanrufe, Sensor-Telemetrie. Ein veralteter Wert ist schlimmer als kein Wert.
• Sie benötigen beide, pro Nachricht → Bauen Sie auf UDP mit selektiver Zuverlässigkeit. QUIC macht das. WebRTC’s SCTP-Datenkanal macht das. Bibliotheken wie ENet und GameNetworkingSockets machen das ebenfalls – allerdings ist die selbstständige Implementierung nicht trivial und leicht falsch zu machen.

Ein Fehler, den man erwähnen sollte: die Annahme, dass „interne Verkehr“ bedeutet, dass man UDP leichtfertig verwenden kann. Paketverluste innerhalb eines Datacenters sind selten, aber nicht null – Hardwarefehler, Netzwerküberlastung bei Spitzenlast, falsch konfigurierte Switches. Wenn Ihre Anwendung Daten bei Verlusten schlicht korrupt macht, hilft ein internes Netzwerk nicht.

Zusammenfassung

TCP ist die richtige Standardwahl für die meisten Anwendungscodes. Wenn Sie API-Aufrufe, eine Datenbank oder Dateiübertragungen machen, sind die Garantien von TCP genau das, was Sie brauchen, und der Aufwand ist auf menschlichen Zeitskalen unsichtbar.

UDP ist die richtige Wahl, wenn Latenz eine harte Beschränkung ist und Ihre Anwendung ihre Beziehung zu Zuverlässigkeit selbst kontrollieren kann. Das ist eine spezifische Menge von Problemen – Echtzeit-Spiele, Live-Medien, benutzerdefinierte Protokolle – nicht eine allgemeine Leistungssteigerung, die Sie nutzen, wenn TCP langsam erscheint.

Der eigentliche Fehler ist nicht, TCP zu verwenden, wenn UDP schneller wäre. Es ist nicht zu wissen, welches Sie wählen und warum, und sich überraschen, wenn das Fehlverhalten eintritt.

Das könnte Ihnen auch gefallen