User Datagram Protocol

Grundidee und Zweck

Das User Datagram Protocol (UDP) ist ein minimales, verbindungsloses Netzwerkprotokoll der Transportschicht in der Internetprotokollfamilie. Es ermöglicht Anwendungen, Datagramme, also einzelne Datenpakete, in IP-basierten Rechnernetzen zu versenden. UDP gehört damit zur gleichen Schicht wie TCP, arbeitet aber deutlich einfacher: Vor dem Senden wird keine Verbindung aufgebaut, und das Protokoll garantiert nicht, dass Daten zuverlässig ankommen.

UDP wurde 1980 von der Internet Engineering Task Force als Internetstandard veröffentlicht und ist in RFC 768 beschrieben. Es wurde als Alternative zum Transmission Control Protocol (TCP) für Anwendungen eingeführt, die keine zuverlässige Datenübertragung durch das Transportprotokoll benötigen. Genannt werden als frühe Anwendungszwecke ein Vorläufer des Domain Name System und das Trivial File Transfer Protocol. Spätere Anwendungsbereiche sind unter anderem Onlinespiele und IP-Telefonie, weil dort eine geringe Verzögerungszeit oft wichtiger ist als eine vollständig zuverlässige Übertragung.

Funktionsweise mit Ports

UDP verwendet Ports, um Daten dem richtigen Programm auf dem Zielrechner zuzuordnen. Ein Port ist dabei eine Nummer, die einen bestimmten Dienst oder Prozess kennzeichnet. Jedes UDP-Datagramm enthält die Portnummer des Dienstes, der die Daten erhalten soll.

Dadurch erweitert UDP die einfache Host-zu-Host-Übertragung des Internet Protocols zu einer Prozess-zu-Prozess-Übertragung. Diese Zuordnung mehrerer Anwendungen über dasselbe Netzwerkprotokoll wird Anwendungsmultiplexen und -demultiplexen genannt: Beim Multiplexen werden Daten verschiedener Anwendungen über ein gemeinsames Netz gesendet, beim Demultiplexen werden sie auf der Empfängerseite wieder dem richtigen Programm zugeteilt.

Zusätzlich kann UDP eine Integritätsüberprüfung durchführen. Dafür wird eine Prüfsumme mitgesendet. Eine Prüfsumme ist ein berechneter Kontrollwert, mit dem der Empfänger erkennen kann, ob ein Datagramm bei der Übertragung fehlerhaft verändert wurde. Fehlerhafte Datagramme können erkannt und verworfen werden.

Eigenschaften und Folgen

UDP ist verbindungslos, nicht zuverlässig sowie ungesichert und ungeschützt. Verbindungslos bedeutet, dass vor dem Datenaustausch keine feste Verbindung zwischen Sender und Empfänger aufgebaut wird. Nicht zuverlässig bedeutet: Es gibt keine Garantie, dass ein gesendetes Paket ankommt, dass Pakete in der ursprünglichen Reihenfolge ankommen oder dass ein Paket nur einmal beim Empfänger eintrifft. Außerdem garantiert UDP nicht, dass Daten unverfälscht oder vor Dritten geschützt ankommen.

Eine Anwendung, die UDP nutzt, muss deshalb selbst damit umgehen können, dass Pakete verloren gehen, doppelt eintreffen oder in falscher Reihenfolge ankommen. Falls nötig, muss die Anwendung eigene Korrekturmaßnahmen und gegebenenfalls Sicherungsmaßnahmen vorsehen.

Der Vorteil dieser Einfachheit ist Geschwindigkeit. Da kein Verbindungsaufbau nötig ist, können ein Partner oder beide Partner schneller mit dem Datenaustausch beginnen. Das ist besonders nützlich, wenn nur kleine Datenmengen übertragen werden. Einfache Frage-Antwort-Protokolle wie DNS nutzen UDP hauptsächlich zur Namensauflösung, um die Netzwerkbelastung gering zu halten und den Datendurchsatz zu erhöhen. Ein Drei-Wege-Handschlag wie bei TCP würde hier unnötigen Overhead erzeugen.

Ein weiterer Vorteil ist die geringe Schwankung der Übertragungsverzögerung. Bei TCP wird ein verlorenes Paket automatisch neu angefordert, was Zeit kostet und die Übertragungsdauer schwanken lässt. Für Multimediaanwendungen kann das ungünstig sein. Bei VoIP würden sonst zum Beispiel plötzliche Aussetzer entstehen oder Wiedergabepuffer müssten größer sein. Bei verbindungslosen Diensten blockieren verlorene Pakete nicht die gesamte Übertragung, sondern vermindern nur die Qualität.

Die maximale Größe eines UDP-Datagramms beträgt theoretisch 65.535 Bytes, weil das Length-Feld im UDP-Header 16 Bit lang ist und die größte mit 16 Bit darstellbare Zahl 65.535 (= 2^16−1) ist. Solche großen Segmente werden von IP fragmentiert übertragen. In der Praxis gibt es weitere Einschränkungen.

Aufbau des Datagramms

Ein UDP-Datagramm besteht aus den Nutzdaten und einem Header am Anfang der Nachricht. Der UDP-Header enthält vier Datenfelder, die jeweils 16 Bit groß sind: Quell-Port, Ziel-Port, Länge und Prüfsumme. Danach folgt das Datenfeld.

Der Quell-Port gibt die Portnummer des sendenden Prozesses an. Diese Information braucht der Empfänger, wenn er auf das Paket antworten soll. Da UDP verbindungslos ist, ist der Quell-Port optional und kann auf „0“ gesetzt werden, wenn keine Antwort erwartet wird.

Der Ziel-Port gibt an, welcher Prozess das Paket empfangen soll. Das Längenfeld gibt die Länge des gesamten Datagramms an, also Header plus Daten, gemessen in Oktetten. Der kleinstmögliche Wert sind 8 Oktette beziehungsweise Byte, denn der Header allein ist 8 Byte groß.

Das Längenfeld legt theoretisch 2^16−1 = 65.535 Bytes fest. Davon entfallen 8 Byte auf den UDP-Header, sodass theoretisch 65.527 Bytes Nutzdaten möglich sind. Wegen des darunterliegenden IP-Protokolls ist die tatsächlich verfügbare Nutzdatenlänge jedoch kleiner: bei IPv4 65.507 Bytes, berechnet als 65.535 – 8 Byte UDP Header – 20 Byte IP Header; bei IPv6 65.487 Bytes, berechnet als 65.535 – 8 Bytes UDP Header – 40 Bytes IPv6 Header.

Das Prüfsummenfeld kann eine 16 Bit große Prüfsumme enthalten. Sie wird über den Pseudo-Header, den UDP-Header und die Daten gebildet. Die Prüfsumme ist optional, wird in der Praxis aber fast immer genutzt. Wenn sie nicht genutzt wird, wird sie auf „0“ gesetzt. Das Datenfeld enthält die eigentlichen Nutzdaten, auch Payload genannt. Es ist optional und kann theoretisch fehlen, was praktisch aber kaum vorkommt. Das Datenfeld besteht immer aus einer geraden Anzahl Oktette; freie Oktette am Ende werden mit Nullen aufgefüllt.

Pseudo-Header und Prüfsumme

Für die Übertragung eines UDP-Pakets wird das Internet Protocol (IP) verwendet. IP setzt vor das UDP-Paket einen eigenen Header mit Informationen, die IP benötigt. Für die Berechnung der UDP-Prüfsumme werden Teile dieses IP-Headers in einen sogenannten Pseudo-Header übernommen. Dieser Pseudo-Header wird nicht übertragen; er dient nur der Prüfsummenbildung.

Bei IPv4 ist der Pseudo-Header 12 Oktetts beziehungsweise 96 Bit groß. Er enthält die Quell-IP-Adresse mit 32 Bit, die Ziel-IP-Adresse mit 32 Bit, ein 8-Bit-Leerfeld, die 8-Bit-Protokoll-ID und die Länge des UDP-Datagramms mit 16 Bit. UDP hat dabei die Protokoll-ID 17.

Bei IPv6 ist der Pseudo-Header 40 Oktetts beziehungsweise 320 Bit groß. Er besteht aus der Quell-IP-Adresse, der Ziel-IP-Adresse, der Upper-Layer Packet Length, einem Feld mit 0 über 24 Bit und dem Feld Next Header.

Zur Berechnung der Prüfsumme setzt der Sender zunächst das Prüfsummenfeld im UDP-Header auf 0000 0000 0000 0000 und bildet eine vorzeichenlose 32-Bit-Zahl, die mit Nullen initialisiert wird. Direkt benachbarte Bytes des UDP-Pakets werden zu 16-Bit-Blöcken zusammengefasst; ein zu kurzer letzter Block wird von hinten mit Nullen aufgefüllt. Die 16-Bit-Blöcke werden mit Übertrag addiert. Danach werden auch die Bytes des Pseudo-Headers zu 16-Bit-Blöcken zusammengefasst und zur bisherigen Prüfsumme addiert. Anschließend werden die Teile der 32-Bit-Prüfsumme so lange weiter mit Übertrag addiert, bis kein Übertrag mehr entsteht. Die weniger signifikanten 16 Bit bilden die eigentliche Prüfsumme. Wenn diese 16-Bit-Zahl nicht nur aus Einsen besteht, wird ihr Einerkomplement im UDP-Header gespeichert.

In IPv4 kann 0000 0000 0000 0000 anzeigen, dass keine Prüfsumme berechnet wurde. IPv6-UDP-Pakete mit der Prüfsumme 0000 0000 0000 0000 sind nach RFC 6935 ungültig. Der Empfänger prüft zuerst, ob das Prüfsummenfeld nur Nullen enthält. Wenn ja, kann er das Paket als richtig empfangen werten, weil keine Prüfsumme vorhanden ist. Andernfalls wendet er den Algorithmus auf das empfangene Paket und den zugehörigen Pseudo-Header an, lässt den letzten Schritt weg und addiert die berechnete Prüfsumme zur empfangenen. Ergibt sich 0, gelten die empfangenen Daten als mit den gesendeten übereinstimmend.

UDP-Lite und Standards

Das Lightweight User Datagram Protocol (UDP-Lite) nach RFC 3828 ist eine Variation von UDP. Es ist für Daten gedacht, bei denen geringe Verzögerung wichtig ist und kleinere Fehler toleriert werden können. Als Beispiele nennt der Artikel Liveaudio- und Livevideoübertragungen. Bei normalem UDP wird ein ganzes Paket verworfen, wenn ein Bit fehlerhaft ist. Bei Audio oder Video könnte ein einzelner Bitfehler je nach Codec jedoch unhörbar oder unsichtbar sein.

UDP-Lite soll deshalb ermöglichen, dass nur bestimmte Teile eines Datenpakets geprüft werden. Auf unteren Schichten soll die Überprüfung bestimmter Paketbereiche effektiv nur für UDP-Lite-Pakete unterdrückt werden; auf Ethernet-Ebene betrifft dies die CRC-Überprüfung.

UDP-Lite ist kompatibel zu UDP, interpretiert das Längenfeld aber anders: Es gibt die Länge an, über die die Prüfsumme berechnet wird, also die checksum coverage. Ein normales UDP-Paket entspricht immer auch den Spezifikationen von UDP-Lite. Umgekehrt gilt das nicht zwingend, weil UDP-Lite mehr Freiheit erlaubt. Ergibt sich aus dem IP-Header eine größere Länge als aus dem Längenfeld des UDP-Lite-Headers, enthält das Paket zusätzliche, ungeprüfte Daten. Ein Längenfeld von acht bedeutet, dass die Prüfsumme nur über den Header berechnet wird. Der Wert Null bedeutet, dass die Prüfsumme über das gesamte Paket berechnet wird. Die Werte 1 bis 7 sind nicht erlaubt, damit der UDP-Lite-Header immer in der Prüfsumme enthalten ist.

Die UDP-Beschränkung der maximalen Paketgröße auf 65.535 Bytes entfällt bei UDP-Lite. Die Prüfsumme kann dann entweder über das gesamte Paket oder höchstens über die ersten 65.535 Bytes berechnet werden. Die wichtigsten genannten Spezifikationen sind RFC 768 – User Datagram Protocol von 1980 und RFC 3828 – The Lightweight User Datagram Protocol (UDP-Lite).