User Datagram Protocol

Das User Datagram Protocol (UDP) ist ein minimales, verbindungsloses Netzwerkprotokoll, das zur Transportschicht der Internetprotokollfamilie gehört. UDP ermöglicht Anwendungen den Versand von Datagrammen in IP-basierten Rechnernetzen.

UDP wurde 1980 von der Internet Engineering Task Force als Internetstandard veröffentlicht.^[1] Es wurde als Alternative zum Transmission Control Protocol für Anwendungen eingeführt, die keine zuverlässige Datenübertragung benötigen. Als frühe Anwendungszwecke wurden ein Vorläufer des Domain Name System und das Trivial File Transfer Protocol genannt.^[1] Zu den späteren Anwendungszwecken gehören unter anderem Onlinespiele und IP-Telefonie, da bei diesen Anwendungen eine geringe Verzögerungszeit wichtiger ist als eine zuverlässige Übertragung.

UDP verwendet Ports, um versendete Daten dem richtigen Programm auf dem Zielrechner zukommen zu lassen. Dazu enthält jedes Datagramm die Portnummer des Dienstes, der die Daten erhalten soll. Diese Erweiterung der Host-zu-Host-Übertragung des Internet Protocols auf eine Prozess-zu-Prozess-Übertragung wird als Anwendungsmultiplexen und -demultiplexen bezeichnet.

Zusätzlich bietet UDP die Möglichkeit einer Integritätsüberprüfung an, indem eine Prüfsumme mitgesendet wird. Dadurch können fehlerhaft übertragene Datagramme erkannt und verworfen werden.

UDP ist ein verbindungsloses, nicht-zuverlässiges und ungesichertes wie auch ungeschütztes Übertragungsprotokoll. Das bedeutet, es gibt keine Garantie, dass ein einmal gesendetes Paket auch ankommt, dass Pakete in der gleichen Reihenfolge ankommen, in der sie gesendet wurden, oder dass ein Paket nur einmal beim Empfänger eintrifft. Es gibt auch keine Gewähr dafür, dass die Daten unverfälscht oder unzugänglich für Dritte beim Empfänger eintreffen. Eine Anwendung, die UDP nutzt, muss daher gegenüber verlorengegangenen und unsortierten Paketen unempfindlich sein oder selbst entsprechende Korrekturmaßnahmen und ggf. auch Sicherungsmaßnahmen vorsehen.

Da vor Übertragungsbeginn nicht erst eine Verbindung aufgebaut werden muss, kann ein Partner oder können beide Partner schneller mit dem Datenaustausch beginnen. Das fällt vor allem bei Anwendungen ins Gewicht, bei denen nur kleine Datenmengen ausgetauscht werden müssen. Einfache Frage-Antwort-Protokolle wie DNS (das Domain Name System) verwenden zur Namensauflösung hauptsächlich UDP, um die Netzwerkbelastung gering zu halten und damit den Datendurchsatz zu erhöhen. Ein Drei-Wege-Handschlag wie bei TCP (dem Transmission Control Protocol) für den Aufbau der Verbindung würde in diesem Fall unnötigen Overhead erzeugen.

Daneben bietet die ungesicherte Übertragung auch den Vorteil von geringen Übertragungsverzögerungsschwankungen: Geht bei einer TCP-Verbindung ein Paket verloren, wird es automatisch neu angefordert. Das braucht Zeit, die Übertragungsdauer kann daher schwanken, was für Multimediaanwendungen schlecht ist. Bei VoIP z. B. käme es zu plötzlichen Aussetzern, bzw. die Wiedergabepuffer müssten größer angelegt werden. Bei verbindungslosen Kommunikationsdiensten bringen verlorengegangene Pakete dagegen nicht die gesamte Übertragung ins Stocken, sondern vermindern lediglich die Qualität.

Die maximale Größe eines UDP-Datagrammes beträgt theoretisch 65.535 Bytes, da das Length-Feld des UDP-Headers 16 Bit lang ist und die größte mit 16 Bit darstellbare Zahl gerade 65.535 (= 2¹⁶−1) ist. Solch große Segmente werden jedoch von IP fragmentiert übertragen. In der Praxis unterliegt die maximal mögliche Länge eines UDP-Datagramms weiteren Einschränkungen.

IP löscht Pakete etwa bei Übertragungsfehlern oder bei Überlast. Datagramme können daher fehlen. UDP bietet hierfür keine Erkennungs- oder Korrekturmechanismen, wie etwa TCP. Im Falle von mehreren möglichen Routen zum Ziel kann IP bei Bedarf neue Wege wählen. Dadurch ist es in seltenen Fällen möglich, dass später gesendete Daten früher gesendete überholen. Außerdem kann ein einmal abgesendetes Datenpaket mehrmals beim Empfänger eintreffen.

Neben den zu übertragenden Nutzdaten werden weitere Informationen mitgesendet, die sich immer am Anfang einer UDP-Botschaft befinden, im sogenannten Header. Der UDP-Header besteht aus vier Datenfeldern, die alle jeweils 16 Bit groß sind:

Quell-Port

gibt die Port-Nummer des sendenden Prozesses an. Diese Information wird benötigt, damit der Empfänger auf das Paket antworten kann. Da UDP verbindungslos ist, ist der Quell-Port optional und kann auf den Wert „0“ gesetzt werden (für den Fall, dass keine Antwortpakete erwartet werden und nur Pakete zum Empfänger gesendet werden sollen).

Ziel-Port

gibt an, welcher Prozess das Paket empfangen soll.

Längenfeld

gibt die Länge des Datagramms, bestehend aus den Daten und dem Header, in Oktetten an. Der kleinstmögliche Wert sind 8 Oktette (bzw. Byte). Das Längenfeld legt eine theoretische Obergrenze von 2¹⁶−1 = 65.535 Bytes (8 Byte Header + 65.527 Bytes Nutzdaten) fest. Die tatsächlich verfügbare Länge der Nutzdaten ist bedingt durch das zugrundeliegende IP-Protokoll jedoch auf 65.507 Bytes (65.535 – 8 Byte UDP Header – 20 Byte IP Header) bei Verwendung von IPv4 und 65.487 Bytes (65.535 – 8 Bytes UDP Header – 40 Bytes IPv6 Header) bei Nutzung von IPv6 beschränkt.^[2]

Prüfsummenfeld

es kann eine 16 Bit große Prüfsumme mitgesendet werden. Die Prüfsumme wird über den sogenannten Pseudo-Header, den UDP-Header und die Daten gebildet. Die Prüfsumme ist optional, wird aber in der Praxis fast immer benutzt. Wird die Prüfsumme nicht genutzt, wird diese auf „0“ gesetzt.^[1]

Datenfeld

es enthält die eigentlichen Nutzdaten, auch Payload genannt. Das Feld ist optional und kann theoretisch auch komplett fehlen, was in der Praxis aber eigentlich nie vorkommt. Das Datenfeld besteht immer aus einer geraden Anzahl Oktette. Am Ende freibleibende Oktette werden mit Nullen aufgefüllt.

Für die Übertragung des UDP-Paketes ist das Internet-Protokoll (IP) vorgesehen. Dieses Protokoll setzt vor das UDP-Paket seinerseits einen weiteren Header, in dem sich die von IP benötigten Daten befinden:

Für die Erzeugung der UDP-Prüfsumme werden Teile dieses IP-Headers in einen sogenannten „Pseudo-Header“ übernommen. Er dient nur zur Erzeugung der Prüfsumme und wird nicht übertragen.

Der Pseudo-Header hat bei IPv4 eine Größe von 12 Oktetts (96 Bit) und setzt sich zusammen aus Quell-IP-Adresse (32 Bit), Ziel-IP-Adresse (32 Bit), 8 Bit Leerfeld, 8 Bit Protokoll-ID (UDP hat die ID 17) und der Länge des UDP-Datagramms (16 Bit):

Bei IPv6 besitzt der Pseudo-Header eine Größe von 40 Oktetts (320 Bit). Er setzt sich dabei folgendermaßen zusammen:

Die Berechnung der Prüfsumme beim Sender erfolgt nach folgendem Algorithmus:

1. Setze das Prüfsummenfeld im UDP-Header auf 0000 0000 0000 0000.
2. Erzeuge eine vorzeichenlose 32-Bit-Zahl für die Prüfsumme, initialisiere sie mit Nullen.
3. Fasse direkt benachbarte Bytes des UDP-Paketes zu 16-Bit-Blöcken zusammen. Falls der letzte Block weniger als 16 Bit hat, dann fülle ihn von hinten mit Nullen auf, bis er 16 Bit hat.
4. Speichere das Ergebnis der Addition aller 16-Bit-Blöcke mit Übertrag in der Prüfsumme.
5. Fasse direkt benachbarte Bytes des Pseudo-Headers zu 16-Bit-Blöcken zusammen.
6. Speichere das Ergebnis der Addition dieser 16-Bit-Blöcke und der bisherigen Prüfsumme mit Übertrag in der Prüfsumme.
7. Fasse direkt benachbarte Bytes der Prüfsumme zu zwei 16-Bit-Blöcken zusammen, addiere diese und speichere das Ergebnis mit Übertrag in der Prüfsumme, bis kein Übertrag mehr bei der Addition entsteht.
8. Die signifikantesten 16 Bit der 32-Bit-Prüfsumme sind nun Nullen. Die weniger signifikanten Bits sind die eigentliche Prüfsumme; speichere diese als vorzeichenlose 16-Bit-Zahl.
9. Wenn diese 16-Bit-Zahl nicht nur aus Einsen besteht, dann speichere ihr Einerkomplement im UDP-Header (sowohl 1111 1111 1111 1111 und das Einerkomplement hiervon, 0000 0000 0000 0000, symbolisieren die Zahl 0). In IPv4 UDP wird 0000 0000 0000 0000 auch verwendet, um zu signalisieren, dass keine Prüfsumme berechnet wurde. IPv6-UDP-Pakete mit der Prüfsumme 0000 0000 0000 0000 sind ungültig (RFC 6935).^[3]

Der Empfänger prüft zunächst, ob das Prüfsummenfeld des empfangenen Paketes nur aus Nullen besteht. Wenn ja, kann er das Paket als richtig empfangen werten, da keine Prüfsumme vorhanden ist. Wenn nicht, so wendet er den oben beschriebenen Algorithmus auf das empfangene Paket und den zugehörigen Pseudo-Header an, lässt den letzten Schritt weg und addiert die selbst berechnete Prüfsumme auf die im Prüfsummenfeld empfangene, was durch die Einerkomplementdarstellung einer Subtraktion entspricht. Erhält der Empfänger 0 als Ergebnis der Addition (bzw. Subtraktion), so wertet er die empfangenen Daten als mit den gesendeten übereinstimmend.

Das Lightweight User Datagram Protocol (UDP-Lite) nach RFC 3828^[4] ist eine Variation von UDP, speziell für die Übertragung von Daten, bei denen es auf geringe Verzögerung ankommt, kleinere Fehler jedoch toleriert werden können. Das ist etwa bei Liveaudio- und -videoübertragungen der Fall, die oft UDP als Transportprotokoll verwenden. Ist ein Bit in einem UDP-Datenpaket fehlerhaft, so werden alle Daten des Pakets, d. h. bis zu mehreren tausend Bits, verworfen. Würde das Paket mit dem fehlerhaften Bit dagegen verwendet, wäre der Fehler, je nach Codec, unhörbar bzw. unsichtbar. Durch die Verwendung von UDP-Lite sollte die Überprüfung bestimmter Teile der Datenpakete durch die unteren Schichten, effektiv nur für UDP-Lite-Pakete, unterdrückt werden. Auf Ethernet-Ebene betrifft dies die CRC-Überprüfung der Pakete.

UDP-Lite ist kompatibel zu UDP, interpretiert jedoch das Längenfeld als Länge, über die die Prüfsumme berechnet wird (checksum coverage). Ein normales UDP-Paket entspricht immer auch den Spezifikationen von UDP-Lite. Dies ist umgekehrt nicht zwingend so, da UDP-Lite einen höheren Freiheitsgrad definiert. Die Länge eines UDP- bzw. UDP-Lite-Pakets kann mit Hilfe der Information aus dem Internet-Protocol-Layer berechnet werden, die IP-Länge ist die Summe aus IP-Headergröße und UDP-Paketgröße. Ergibt sich bei UDP-Lite eine größere Länge aus dem IP-Header als im Längenfeld des UDP(-Lite)-Headers, so enthält das Paket zusätzliche, ungeprüfte Daten. Ein Längenfeld von acht bedeutet zum Beispiel, dass die Prüfsumme nur über den Header berechnet wird. Mit dem Wert Null wird die Prüfsumme über das gesamte Paket berechnet. Die Werte 1, …, 7 sind nicht erlaubt, d. h. der UDP-Lite-Header ist immer in der Prüfsumme enthalten. Die Beschränkung der maximalen Paketgröße aus UDP (65.535 Bytes) entfällt. Die Prüfsumme kann in diesem Fall entweder über das gesamte Paket oder maximal über die ersten 65.535 Bytes berechnet werden.

• RFC 768 – User Datagram Protocol. 1980 (englisch).
• RFC 3828 – The Lightweight User Datagram Protocol (UDP-Lite). (englisch).

• Liste der Portnummern mit allen von der IANA standardisierten und inoffiziellen UDP-Ports
• Stream Control Transmission Protocol (SCTP)
• Datagram Congestion Control Protocol (DCCP)

• Beispielcode für ein einfaches UDP-Client-Server-Paar unter Unix. abc.se

1. ↑ ^{a b c d} RFC 768 – User Datagram Protocol. 1980 (englisch).
2. ↑ RFC 5405 – Unicast UDP Usage Guidelines. (englisch).
3. ↑ RFC 6935 – IPv6 and UDP Checksums for Tunneled Packets. April 2013 (englisch).
4. ↑ RFC 3828 – The Lightweight User Datagram Protocol (UDP-Lite). (englisch).