RFC 768 · · Internet Standard
UDP, das Protokoll, das nichts verspricht.
Der offizielle Titel lautet "User Datagram Protocol." Worüber er wirklich entscheidet: wie man eine Nachricht durchs Internet schickt, ohne Handschlag, ohne Reihenfolge und ohne Zusage, dass sie ankommt. Drei Seiten, 1980 geschrieben, und bis heute Träger von DNS, Videoanrufen und HTTP/3.
Geschrieben von Noel Lang · IT-Trainer
Kurzfassung
RFC 768 definiert UDP, und er ist drei Seiten lang. Ein UDP-Paket besteht aus einem acht Byte großen Header, vier 16-Bit-Feldern (Quellport, Zielport, Länge, Prüfsumme), gefolgt von deinen Daten. Es gibt keine Verbindung, keine erneute Übertragung, keine Reihenfolge und keine Überlastkontrolle. Das klingt nach Schwäche, und genau deshalb wählen DNS, DHCP, Live-Video und HTTP/3 es: Sie behandeln Verluste lieber selbst, als zu warten.
Das Problem, das er löst
1980 hatte das Internet bereits RFC 793 , das einen Byte-Strom zuverlässig und in der richtigen Reihenfolge zustellt, ganz gleich, was das Netz damit anstellt. TCP ist großartig, und es ist teuer: Bevor ein einziges Byte deiner Daten fließt, tauschen beide Enden Begrüßungen aus, und danach halten sie Zustand über alles, was erneut gesendet werden könnte.
Für viel Verkehr kauft dieser Preis nichts. Eine DNS-Anfrage ist eine kleine Frage mit einer kleinen Antwort. Dafür eine Verbindung aufzubauen kostet mehr Umläufe, als zweimal zu fragen. Also bietet RFC 768 den anderen Handel an: einen Header, der so dünn ist, dass er fast nichts ist, und keinerlei Zusagen. Schick es los und hoffe.
Heraus kommt das Kleinste, was man sinnvoll auf IP setzen kann. Es fügt einem rohen IP-Paket genau zwei Ideen hinzu: Portnummern, damit eine Maschine mehr als einen Dienst betreiben kann, und eine Prüfsumme, damit Verfälschung auffällt. Alles andere überlässt es bewusst dir.
Die Postkarte
RFC 793 ist ein Einschreiben. Die Post bestätigt den Versand, verfolgt es, versucht es erneut, wenn es verloren geht, und meldet die Zustellung. All das kostet Zeit, Papierkram und einen Aktenschrank an jedem Ende.
UDP ist eine Postkarte. Du schreibst die Adresse, wirfst sie ein und gehst weiter. Niemand bestätigt die Ankunft, niemand bemerkt das Ausbleiben, und wenn du drei schickst, können sie in beliebiger Reihenfolge auftauchen. Die Postkarte ist kein defekter Brief. Sie ist das richtige Objekt, wenn die Nachricht klein ist, der Verlust verkraftbar und das Warten auf Bestätigung mehr kostet, als die Nachricht wert ist.
Die Analogie trägt bis in die unbequemen Ecken. Postkarten kann jeder mitlesen, und UDP hat keine eigene Verschlüsselung. Postkarten landen an der falschen Tür, und die Pseudo-Header-Prüfsumme von UDP existiert, um genau das zu bemerken. Und wenn du bei einer Postkarte wirklich Gewissheit brauchst, baust du dir dein eigenes Sendungsverfolgungssystem obendrauf. Genau das hat QUIC getan.
Das ganze Protokoll, in acht Byte
Vier 16-Bit-Felder, dann deine Daten. Vergleich das mit dem mindestens zwanzig Byte großen Header von RFC 793 , mit seinen Sequenznummern, Bestätigungen und Fenstergrößen, und die Philosophie ist auf einen Blick sichtbar.
Was der RFC wirklich sagt
Drei Seiten, und eine davon ist größtenteils das Diagramm von oben. Wenn du je einen Internet-Standard von vorn bis hinten lesen willst, fang hier an:
| Abschnitt | In einfachen Worten |
|---|---|
| Format | Ein Diagramm: vier 16-Bit-Felder, acht Byte, dann deine Daten. Dieses Diagramm ist der größte Teil des Protokolls. |
| Fields | Was jedes Feld bedeutet. Der Quellport ist optional und darf null sein. Die Länge zählt den Header mit, der kleinste gültige Wert ist also 8. |
| User Interface | Zwei Sätze darüber, was eine Anwendung anfordern können muss. Ein ungewöhnlich bescheidener Abschnitt. |
| IP Interface | Der Pseudo-Header-Trick: Die Prüfsumme deckt heimlich auch die IP-Quell- und Zieladresse ab, sodass ein falsch zugestelltes Paket auffällt. |
| Protocol Application | Nennt zwei Nutzer von UDP als Beispiel, einer davon der "Internet Name Server". 1980 hatte DNS seinen Namen noch nicht. |
| Protocol Number | Siebzehn. Das ist der ganze Abschnitt. |
Was oft falsch verstanden wird
-
"UDP ist unzuverlässig, also das schlechtere Protokoll."
Es ist unzuverlässig per Entwurf, was nicht dasselbe ist wie kaputt. UDP verliert deine Daten nicht absichtlich, es weigert sich nur, Verluste für dich zu beheben, und überlässt diese Entscheidung der Anwendung. Genau deshalb baut QUIC, und damit HTTP/3 und ein großer Teil des modernen Webs, auf UDP auf: Die Entwickler wollten Zuverlässigkeit, aber zu ihren eigenen Bedingungen statt zu denen von TCP.
-
"UDP hat keine Fehlerprüfung."
Es hat eine 16-Bit-Prüfsumme, und zwar eine raffinierte: Sie deckt den Header, die Daten und einen Pseudo-Header mit der IP-Quell- und Zieladresse ab, sodass ein an den falschen Host zugestelltes Paket auffällt. In IPv4 darf ein Sender lauter Nullen senden, was "nicht berechnet" heißt. In IPv6 ist die Prüfsumme Pflicht, weil IPv6 die Header-Prüfsumme entfernt hat, die solche Fehler eine Schicht tiefer abfing.
-
"UDP ist schneller als TCP."
Es hat geringere Latenz, was etwas anderes ist. Ohne Handschlag trägt das erste Paket echte Daten statt einer Begrüßung, und ohne erneute Übertragung wartet nichts auf einen Nachzügler. Auf einer sauberen Leitung schlägt eine große Dateiübertragung per TCP aber meist eine selbstgebaute über UDP, weil TCP vierzig Jahre gelernt hat, wie schnell es fahren darf.
Wo dir UDP begegnet
Bei jedem Namen, den du nachschlägst, und bei jedem Videoanruf. Ein Feldführer:
| Du siehst | Was passiert |
|---|---|
| Eine DNS-Abfrage auf Port 53 | Fast immer UDP. Frage raus, Antwort zurück, je ein Paket. Fällt nur auf TCP zurück, wenn die Antwort nicht hineinpasst. |
| HTTP/3 und QUIC auf Port 443 | Das moderne Web läuft über UDP. QUIC hat Zuverlässigkeit darauf neu gebaut, gerade weil es Kontrolle wollte, die TCP nicht hergab. |
| DHCP auf den Ports 67 und 68 | Ein Gerät ohne Adresse kann keinen TCP-Handschlag führen. UDP-Broadcast ist das Einzige, was vor der eigenen Identität funktioniert. |
| Syslog auf Port 514 | Log-Zeilen im Fire-and-forget-Verfahren. Eine verlorene Zeile in der Flut ist besser, als die schreibende Anwendung zu blockieren. |
| Ein Videoanruf, der klötzchenhaft wird | Pakete gingen verloren und niemand hat sie noch einmal angefordert. Ein zu spätes Bild ist wertlos, also lässt UDP es ziehen. |
traceroute unter Linux |
Die klassische Implementierung schickt UDP-Pakete an unwahrscheinlich hohe Ports und lauscht auf die zurückkommenden ICMP-Fehler. |
Fragen, die wirklich gestellt werden
Was ist RFC 768? +
RFC 768 ist die Spezifikation von UDP, dem User Datagram Protocol, aus dem Jahr 1980. Sie definiert eine minimale Art, eine Nachricht über IP zu senden: acht Byte Header mit Quellport, Zielport, Länge und Prüfsumme, und sonst nichts. Es gibt keinen Verbindungsaufbau, keine erneute Übertragung und keine Reihenfolge. Der RFC ist drei Seiten lang und weiterhin Internet Standard (STD 6).
Was ist der Unterschied zwischen UDP und TCP? +
TCP baut eine Verbindung auf, überträgt verlorene Daten erneut, bringt Pakete in die richtige Reihenfolge und drosselt bei Überlast. UDP tut nichts davon: Es reicht deine Nachricht an IP weiter und vergisst sie. TCP ist ein Einschreiben, UDP eine Postkarte. Nimm UDP, wenn ein verlorenes Paket weniger schmerzt als das Warten darauf, weshalb Live-Video und DNS es nutzen.
Hat UDP eine Prüfsumme? +
Ja. UDP trägt eine 16-Bit-Prüfsumme, die den Header, die Daten und einen Pseudo-Header mit der IP-Quell- und Zieladresse abdeckt. In IPv4 ist sie optional: Ein Sender darf lauter Nullen schicken, was "nicht berechnet" bedeutet. In IPv6 ist die Prüfsumme Pflicht, weil IPv6 die Header-Prüfsumme abgeschafft hat, die solche Fehler eine Schicht tiefer abfing.
Warum nutzen DNS und Videoanrufe UDP? +
Weil Nachfragen billiger ist als Warten. Eine DNS-Anfrage und ihre Antwort passen in je ein Paket; geht eines verloren, kostet erneutes Fragen weniger als ein TCP-Handschlag gekostet hätte. In einem Videoanruf ist ein zu spät eintreffendes Bild ohnehin wertlos, eine erneute Übertragung brächte also nichts. UDP überlässt der Anwendung die Entscheidung über Verluste, statt allen dieselbe Antwort aufzuzwingen.
Verweise hierher
Andere Erklärseiten auf dieser Website, die auf diesen RFC zurückverweisen:
Wie RFC 768 zusammenhängt
Seine Gegenstücke
-
RFC 793 · das vorsichtige Geschwister
TCP, die andere Wahl
Dasselbe Jahr, dieselbe Schicht, die entgegengesetzte Philosophie. TCP garantiert Zustellung und Reihenfolge, zum Preis von Latenz und Zustand. Fast jede Entwurfsentscheidung des einen ist das Spiegelbild der anderen.
-
RFC 9868 · aktualisiert diesen
Optionen für ein Protokoll ohne Optionen
Aus dem Jahr 2025: doch noch ein Weg, UDP optionale Felder zu geben, untergebracht im Raum zwischen dem Längenfeld und dem Ende des IP-Pakets. Fünfundvierzig Jahre später bekam das Protokoll, das nichts versprach, eine Tasche.
Teil eines geführten Clusters: Die Netzwerk-Grundlagen, erklärt