Begriff
UDP (User Datagram Protocol)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
TCP ist der Buchhalter (sorgfältig, langsam). UDP ist der Marktschreier. Er wirft Pakete einfach raus. "Hier! Fang!" Er prüft nicht, ob sie angekommen sind. Er sendet sie nicht nochmal. Er sortiert sie nicht. Warum nutzt man so einen Chaoten? Weil er schnell ist. Extrem schnell. Kein Handshake, kein Warten auf "Bestätigung". Perfekt für:
- Video Streaming (Wenn ein Pixel fehlt, egal. Weiterspielen!).
- Gaming (Position des Gegners von vor 1 Sekunde ist eh egal. Ich brauche die jetzt).
- DNS (Nur eine kurze Frage, eine kurze Antwort).
Merksatz: Ein verbindungsloses, unzuverlässiges Transportprotokoll, das auf minimale Latenz optimiert ist und keine Garantien für Zustellung oder Reihenfolge bietet.
Discord Voice Chat nutzt UDP. Wenn das Netz schlecht ist, hörst du Roboter-Stimmen (Paketverlust), aber der Stream stoppt nicht (kein Buffering wie bei TCP Youtube). VPNs (WireGuard, OpenVPN) nutzen UDP, um TCP-in-TCP Tunnelprobleme ("Meltdown") zu vermeiden.
1. UDP Amplification Attack (DDoS)
Ein Hacker sendet ein kleines Paket (60 Byte) an einen offenen UDP Server (z. B. NTP oder DNS) mit gefälschter Absender-IP (die vom Opfer). Der Server antwortet dem Opfer mit einer riesigen Liste (3000 Byte). Faktor 50 Verstärkung. Das Opfer wird von Antworten überflutet, die es nie bestellt hat. Da UDP keinen Handshake macht, prüft der Server nie, ob die Absender-IP wirklich echt ist (Spoofing ist trivial).
2. QUIC (HTTP/3)
Das neue Web basiert auf UDP! Warum? Weil TCP zu langsam ist (Head-of-Line Blocking). QUIC baut auf UDP eine eigene Zuverlässigkeitsschicht (Reliability Layer) im User-Space. Es kombiniert die Geschwindigkeit von UDP mit der Sicherheit von TCP, aber ohne den Kernel-Overhead. Google hat das erfunden, weil sie TCP nicht mehr schneller machen konnten.
3. MTU & Fragmentation
Bei TCP verhandeln Sender und Empfänger die Größe (MSS). Bei UDP gibt es keine Verhandlung. Wenn du ein 2000 Byte UDP Paket sendest, aber das Netz nur 1500 erlaubt (MTU)... Muss IP fragmentieren (schlecht) oder es wird verworfen (Black Hole). Regel für UDP-Apps: Bleib unter 1400 Bytes Payload, um Fragmentierung weltweit zu vermeiden.
1. Jitter & Forward Error Correction (FEC)
Da UDP keine Pakete neu anfordert, muss die App mit Löchern klarkommen. Bei Audio-Calls (VoIP) ist das Hauptproblem der Jitter (Schwankungen in der Ankunftszeit). Pakete kommen mal schnell, mal langsam an. Die App nutzt einen Jitter Buffer, der die Pakete kurz sammelt und gleichmäßig abspielt. Um Lücken zu füllen, nutzt man FEC: Man sendet redundante Informationen mit. "Paket 3 enthält auch eine kleine Kopie von Paket 2." Wenn Paket 2 verloren geht, kann die App es aus Paket 3 rekonstruieren, ohne dass der User ein Knacken hört.
2. Path MTU Discovery (PMTUD) & Black Holes
Wenn ein Host ein großes UDP-Paket (z.B. 1472 Bytes + Header = 1500) sendet, aber ein Router im Internet nur 1400 Bytes erlaubt, würde das Paket normalerweise fragmentiert. Aber viele Firewalls blockieren Fragmente aus Sicherheitsgründen. Das Paket verschwindet einfach im Black Hole. Moderne UDP-Anwendungen setzen das "Don't Fragment" (DF) Bit und nutzen Techniken wie PLPMTUD. Sie fangen mit kleinen Paketen an und tasten sich langsam an die maximale Größe heran, die der Pfand durch das Internet zulässt, ohne fragmentiert zu werden.
3. Ephemeral Ports & NAT Traversal
Hinter einem Router (NAT) haben alle Geräte die gleiche öffentliche IP. Wenn dein PC ein UDP-Paket sendet, merkt sich der Router den Ephemeral Port (z. B. 54321) und leitet Antworten für eine kurze Zeit (oft nur 30-60 Sekunden) an deinen PC weiter (Connection Tracking). Danach löscht der Router den Eintrag wieder. Damit eine UDP-Verbindung (z. B. VPN) offen bleibt, muss die App ständig leere Pakete senden (NAT Keep-Alive), um das "Loch" in der Firewall des Routers offen zu halten. Fehlt dieser Heartbeat, bricht die Verbindung sofort ab, sobald 1 Minute lang keine Daten fließen.
Quick-Check
Ports bei UDP?
Ja. UDP hat Ports, genau wie TCP. Port 53 (DNS) ist klassisch. Aber Firewall-Regeln müssen explizit "UDP" erlauben. "Allow TCP 53" lässt kein UDP durch.Verbindungslos?
Es gibt keinen "Status" im Kernel. Der Server weiß nicht, wie viele Clients gerade zuhören. Er vergisst das Paket sofort nach dem Senden. Das spart extrem viel RAM (gut für IoT Server mit Millionen Geräten).Reihenfolge?
Nicht garantiert. Paket 2 kann vor Paket 1 ankommen. Die App (Skype) muss sie selbst sortieren (Jitter Buffer), wenn Reihenfolge wichtig ist.