Mit Google fortfahren
UDP einfach erklärt: Ablauf, Header und Risiken
UDP (User Datagram Protocol) sendet einzelne Datagramme ohne vorherigen Verbindungsaufbau. Das spart Kontrollaufwand und vermeidet Wartezeit, aber UDP selbst bestätigt weder die Zustellung noch die richtige Reihenfolge. Du lernst, wie UDP arbeitet, wann es passt und welche Risiken du bei der Entscheidung beachten musst.
Hake ab, was du schon kannst — und komm am Ende hierher zurück!
Wie UDP ein Datagramm zustellt
Stell dir vor, ein Online-Spiel muss sofort eine neue Position senden. Eine verspätete alte Position hilft kaum noch. UDP kann die Daten direkt losschicken, ohne vorher einen Handshake, also einen Verbindungsaufbau mit dem Empfänger, abzuwarten.
UDP gehört zur Transportschicht. Die IP-Adresse bringt das Datagramm zum Zielrechner. Die Portnummer ordnet es dort dem richtigen Prozess oder Dienst zu. So wird aus der Host-zu-Host-Kommunikation eine Prozess-zu-Prozess-Kommunikation.
Der Ablauf ist kurz:
- Die Anwendung übergibt Nutzdaten und Ziel-Port an UDP.
- UDP setzt einen Header davor und übergibt das Datagramm an IP.
- Das Netzwerk versucht die Zustellung.
- Trifft das Datagramm ein, ordnet der Ziel-Port es der passenden Anwendung zu.
UDP baut dabei keine Verbindung auf, sendet keine UDP-eigene Empfangsbestätigung und fordert verlorene Datagramme nicht automatisch erneut an. Ein Datagramm kann fehlen, doppelt eintreffen oder von einem später gesendeten Datagramm überholt werden. Wenn das nicht akzeptabel ist, muss die Anwendung selbst reagieren oder ein anderes Transportprotokoll verwenden.
UDP verspricht: „Ich sende sofort.“ Es verspricht nicht: „Alles kommt genau einmal und in der richtigen Reihenfolge an.“
Was im UDP-Header steht
Der UDP-Header ist immer 8 Byte groß. Er besteht aus vier Feldern mit jeweils 16 Bit:
| Feld | Aufgabe |
|---|---|
| Quell-Port | Kennzeichnet den sendenden Prozess und ermöglicht eine Antwort; er kann bei nicht erwarteter Antwort auf 0 gesetzt sein. |
| Ziel-Port | Ordnet das Datagramm dem gewünschten Dienst auf dem Zielrechner zu. |
| Länge | Gibt die Gesamtlänge von Header und Nutzdaten in Byte an. |
| Prüfsumme | Dient dazu, Übertragungsfehler in den einbezogenen Daten zu erkennen. |
Die Nutzdaten oder Payload folgen auf den Header. Weil der Header selbst 8 Byte beansprucht, ist die kleinste UDP-Länge 8 Byte.
Das 16-Bit-Längenfeld kann höchstens $2^{16}-1=65\,535$ Byte darstellen. Daraus folgen theoretisch höchstens $65\,535-8=65\,527$ Byte Nutzdaten. Bezieht man bei IP die normalen Headergrößen mit ein, bleiben höchstens 65 507 Byte bei IPv4 und 65 487 Byte bei IPv6. Solche großen IP-Pakete können fragmentiert werden; die praktisch sinnvolle Datagrammgröße hängt deshalb vom darunterliegenden Netzwerk ab.
Eine Anwendung sendet 120 Byte Nutzdaten. Der UDP-Header ergänzt 8 Byte.
$$120\,\text{Byte}+8\,\text{Byte}=128\,\text{Byte}$$
Im UDP-Längenfeld steht also 128. IP fügt außerhalb des UDP-Datagramms noch seinen eigenen Header hinzu.
Für die Prüfsumme werden UDP-Header, Nutzdaten und ausgewählte Angaben aus dem IP-Header einbezogen. Diese IP-Angaben bilden einen Pseudo-Header: Er wird nur für die Berechnung verwendet und nicht als eigener Header übertragen. Bei einer ungeraden Zahl von Bytes wird nur für die Berechnung ein Nullbyte ergänzt; es gehört nicht zur Nutzlast.
Eine nicht passende Prüfsumme weist auf einen Übertragungsfehler hin; das Datagramm wird verworfen. Die Prüfsumme korrigiert den Fehler nicht und bietet weder Verschlüsselung noch einen Identitätsnachweis. Bei IPv4 kann ein Prüfsummenfeld mit 0 bedeuten, dass keine UDP-Prüfsumme berechnet wurde. Bei UDP über IPv6 ist die Prüfsumme grundsätzlich vorgeschrieben; eine Nullprüfsumme ist nur in eng begrenzten Sonderfällen zulässig.
Wann UDP und wann TCP passt
UDP und TCP lösen unterschiedliche Aufgaben auf der Transportschicht. Die Aussage „UDP ist besser“ oder „TCP ist besser“ ist deshalb zu pauschal. Entscheidend ist, was die Anwendung bei Verlust und Verzögerung braucht.
| Entscheidungspunkt | UDP | TCP |
|---|---|---|
| Beginn | ohne vorherigen Handshake | Verbindungsaufbau vor der Übertragung |
| Verlust | keine automatische Neuübertragung | erkennt fehlende Daten und fordert sie erneut an |
| Reihenfolge | nicht eingebaut | stellt die richtige Reihenfolge her |
| Schwerpunkt | wenig Kontrollaufwand, geringe Verzögerung | zuverlässige und geordnete Übertragung |
| Typische Fälle | Echtzeit-Audio, Video, Online-Spiel, DNS-Anfrage | E-Mail, Dateiübertragung, zuverlässiger Webverkehr |
Bei einer Live-Unterhaltung kann ein verlorener kurzer Audioteil weniger stören als eine späte Wiederholung. Bei einer Datei wäre ein fehlender Teil dagegen inakzeptabel. DNS nutzt für viele kurze Namensanfragen hauptsächlich UDP, weil ein zusätzlicher TCP-Verbindungsaufbau unnötigen Aufwand verursachen kann.
Du entwirfst zwei Anwendungen:
- Eine Live-Sensoranzeige wird jede Sekunde aktualisiert. Ein einzelner alter Messwert darf fehlen, der neueste Wert soll schnell erscheinen.
- Eine Konfigurationsdatei muss vollständig und in richtiger Reihenfolge ankommen.
Für die Anzeige kann UDP passen, wenn die Anwendung Ausfälle erkennt und toleriert. Für die Datei passt TCP, weil Vollständigkeit und Reihenfolge wichtiger sind als der schnelle Beginn.
Frage zuerst: „Was ist schlimmer: Warten oder fehlende Daten?“ Die Antwort führt meist zur passenden Transportstrategie.
Welche Sicherheitsrisiken entstehen
Verbindungslos bedeutet nicht automatisch unsicher, aber einige UDP-Eigenschaften können Angriffe erleichtern. Besonders wichtig sind drei Muster:
UDP-Flood
Sehr viele UDP-Datagramme überlasten ein Ziel. Bei zufälligen Ziel-Ports kann der Rechner zusätzlich ICMP-Antworten wie „Port nicht erreichbar“ erzeugen und dadurch weitere Arbeit leisten.
Reflection
Der Angreifer trägt die IP-Adresse des Opfers als gefälschte Quelladresse ein und sendet Anfragen an offene UDP-Dienste. Die Dienste schicken ihre Antworten an das Opfer: Der Verkehr wird zum Opfer „reflektiert“.
Amplification
Eine kleine Anfrage löst eine deutlich größere Antwort aus. Bei DNS-Amplification verbindet sich dieser Verstärkungseffekt mit Reflection, sodass viele große Antworten beim Opfer eintreffen.
Mögliche Schutzmaßnahmen sind: UDP-Verkehr überwachen, nur notwendige UDP-Dienste von außen erreichbar machen, Firewall-Regeln setzen, Antwortraten begrenzen und verteilte DDoS-Abwehr nutzen. Keine einzelne Maßnahme verhindert jeden Angriff; zu strenges Begrenzen kann auch legitimen Verkehr treffen.
Karteikasten
Überlege zuerst selbst und drehe die Karte anschließend zum Prüfen um.
Alles auf einen Blick
- UDP
- Arbeitsweise
- Datagramme ohne Handshake
- IP-Adresse zum Rechner, Port zum Dienst
- Stärken
- geringer Kontrollaufwand
- geringe Verzögerung
- Grenzen
- keine Garantie für Zustellung, Reihenfolge oder Einmaligkeit
- Anwendung muss Verluste und Duplikate behandeln
- Header
- Quell-Port und Ziel-Port
- Länge und Prüfsumme
- Einsatzentscheidung
- Echtzeit und Verlusttoleranz sprechen für UDP
- Vollständigkeit und Ordnung sprechen für TCP
- Risiken
- Flood
- Reflection und Amplification
- Arbeitsweise
Abschluss-Check
Wenn du UDP beurteilst, verbindest du drei Fragen: Wie schnell müssen Daten ankommen, welche Verluste kann die Anwendung verkraften und welche Schutzmaßnahmen braucht der erreichbare Dienst?