Universität Karlsruhe Fakultät für Informatik Universität Karlsruhe

Proseminar Grundlagen der Rechnerkommunikation

Das User Datagram Protokoll (UDP)

Christian Resag

Inhaltsverzeichnis

        Einleitung
        Probleme der Adressierung von Prozessen
        Ports
        Zuordnung von Port-Adressen
        Leistungsumfang des UDP-Protokolls
        Mögliche Probleme bei der Nutzung von UDP
        Der UDP-Header
        Die UDP-Prüfsumme
        Der Pseudo-Header
        Die UDP-Prüfsumme und das Schichten-Konzept
        Zusammenfassung
        Literatur

Einleitung

Grundlage eines Computer-Netzwerkes ist die Möglichkeit einzelner Rechner mit anderen Rechnern Daten auszutauschen. In Netzwerken, welche die TCP/IP-Protokollfamilie zur Grundlage haben, wird diese Funktionalität mit Hilfe der IP-Schicht realisiert. Zu verschickende Daten werden in Form von Paketen transportiert, welche durch die IP-Adressen des Empfängers eindeutig adressiert werden. Anhand dieser können die im Netzwerk befindlichen Rechner das einzelne Paket bis zu seinem Ziel weiterleiten.

Diese Funktionalität ist grundlegend, aber natürlich nicht ausreichend, wenn man bedenkt, dass es im eigentlichen Sinne nicht die Computer sind die verbunden werden sollen, sondern ihre Prozesse. Prozesse eines Rechners sollen mit Prozessen anderer, unabhängiger, räumlich evtl. stark getrennter Rechenanlagen kommunizieren und interagieren können.

Über die Adressierung eines einzelnen Rechners hinaus, wird also letztlich eine Methodik benötigt, die es ermöglicht einzelne Prozesse auf dem Endrechner gezielt anzusprechen. Um Daten direkt zu ihren wirklichen Empfängern transportieren zu können.

Für diese Funktionalität sieht das TCP/IP-Schichtenmodell die Transport-Schicht vor. Auf ihr bieten verschiedene Transportprotokolle (je nach Anwendungsgebiet mit verschiedenem Funktionsumfang ausgestattet) die Möglichkeit Daten an andere Prozesse zu verschicken.

UDP ist ein solches Transportprotokoll.

Probleme der Adressierung von Prozessen

Auf modernen (multitasking-)Betriebssystemen können zumeist mehrere Prozesse gleichzeitig laufen. Diese sollten jederzeit (somit auch gleichzeitig) im Netz kommunizieren können und müssen dazu also adressierbar sein. Beim Versuch einen Prozess an sich zu adressieren, ergibt sich jedoch eine nicht triviale Problematik. Es ist nämlich keinesfalls offensichtlich wie dies zu erfolgen hat. Direktes Adressieren bedeutet, der Sender muss Informationen über den Bestand von Prozessen des Zielrechners besitzen. Wie stellt man solche Informationen zur Verfügung? Wie hält man solche Informationen in großen Netzwerken konsistent? Prozesse können schließlich dynamisch entstehen und terminieren. Prozesse sind vielleicht auch in der Lage mehrere Funktionen zur Verfügung zu stellen. Diese sollten dann separat adressierbar sein. Und unter Umständen sollte die Möglichkeit bestehen, einen Prozess, der eine bestimmte Funktion zur Verfügung stellt, komplett auszutauschen, ohne verbundene Prozesse davon in Kenntnis setzen zu müssen.

Ein etwas abstrakterer Ansatz, der auch bei den TCP/IP-Protokollen Verwendung findet, betrachtet deshalb nicht wirklich die Prozesse als Endpunkte, sondern die von ihnen zur Verfügung gestellten Dienste. Eine zusätzliche Schnittstelle dient deshalb als Zielpunkt für eine Datenübertragung. Die Ports.

Ports

Um mehreren Prozessen gleichzeitig zu ermöglichen per UDP Daten zu verschicken und zu empfangen, Benutzt das UDP-Protokoll also eine Schnittstelle zu den eigentlichen Prozessen - die Ports. Jeder Prozess der per UDP das Netz benutzen möchte, erhält von der UDP-Schicht einen Port zugewiesen. Ports werden anhand von 16-bit-Integer Zahlen referenziert. Über diese besteht somit die Möglichkeit einen Prozess innerhalb eines Rechners zu adressieren. Die Portnummer zusammen mit der IP-Adresse eines Rechners ergibt einen Verbindungspunkt, der auch Socket genannt wird. Dieser stellt quasi die eindeutige Adresse eines Prozesses im gesamten Netzwerk dar. Wirklich eindeutig wird diese Adresse allerdings erst, wenn das für den Transport benutzte Protokoll bekannt ist. Denn da beim Aufschlüsseln der Empfangsadresse (in der IP-Schicht) zunächst nach Protokoll und erst später nach dem Port aufgeschlüsselt wird,

kann das im IP-Header für die Portnummer vorgesehene 16-bit-Feld prinzipiell von jedem Transport-Protokoll unabhängig benutzt werden. (d.h. UDP und TCP könnten theoretisch die selben Ports benutzen, ohne sich gegenseitig zu behindern) In der Praxis ist man jedoch seit einigen Jahren bestrebt die Zuordnung der Portnummer (und damit der Socketnummer) zwischen den einzelnen Protokollen zu koordinieren, um so nur noch wirklich eindeutige Sockets zu vergeben.

Zuordnung von Port-Adressen

Die Portnummer wird zum adressieren eines Prozesses benötigt. Also muss ein sendender Prozess wissen, welchen Port der von ihm anzusprechende Dienst belegt. Insofern ist es also wichtig, wie die Portnummern zugewiesen werden. Und dafür existieren zwei prinzipiell unterschiedliche Verfahren.

Zum einen kann durch eine zentrale Vergabe von Portnummern sozusagen "global" festgelegt werden, welche Dienste welche Portnummern erhalten. Vorteil einer solchen Standardisierung ist ein relativ einfacher Zugriff auf diese Dienste. Nachteilig ist allerdings eine schlechte Erweiterbarkeit. Soll in diesem Modell ein Dienst angesprochen werden, der keinen Standard-Port benutzt, so muss zuvor eine Anfrage an den betreffenden Rechner gesandt werden auf welchen Port der gewünschte Dienst zu erreichen ist. Ein zweiter Ansatz ist die dynamische Vergabe von Portnummern zur Laufzeit. In TCP/IP-Netzwerken bestehen beide Verfahren nebeneinander. Einige Port-Adressen sind fest vorgegeben und referenzieren bestimmte Standard-Dienste. (z.B. für Server) Andere wiederum sind frei zur dynamischen Vergabe. (z.B für Clienten)

Leistungsumfang des UDP-Protokolls

Das UDP-Protokoll ist schlicht und stellt lediglich grundlegende Funktionen zur Verfügung, um mit minimalem Aufwand Daten zwischen kommunizierenden Parteien austauschen zu können. Es setzt direkt auf dem IP-Protokoll auf und genau wie dieses verschickt es zu transportierende Daten in Paketform. Dabei wird jedes einzelne Paket mit einem UDP-Header versehen, der unter anderem die Portnummer von Sender und Empfänger beinhaltet. Im Folgenden wird jedes Paket an des IP-Protokoll übergeben, das den Versand an den Zielrechner übernimmt.

Wie das IP-Protokoll gehört UDP demnach zu den verbindungslosen Protokollen. Im Gegensatz zu verbindungsorientierten, bietet es somit keinerlei Kontrollmechanismus, die tatsächliche Ankunft versendeter Pakete zu überprüfen. Der einzige Sicherheitsmechanismus den das UDP-Protokoll überhaupt zur Verfügung stellt, ist eine optionale Prüfsumme, die prinzipiell wie die Prüfsumme des IP-Protokolls berechnet wird, dabei aber den Datenbereich einschließt.

Die fehlenden Kontrollmechanismen (insbesondere die fehlende Empfangsbestätigung), machen UDP für einige Anwendungsgebiete - eben jene, die eine sichere Datenübertragung benötigen - ungeeignet. In anderen Bereichen jedoch, bietet gerade der simple Aufbau entscheidende Performance-Vorteile.

Die Applikations-Schicht, die wiederum auf dem UDP-Protokoll aufbauen kann, bekommt mit UDP ein einfaches Werkzeug, Daten netzwerkunabhängig zu versenden. Anders als bei der stream-orientierten Ein- und Ausgabe, resultiert hier jedoch jede Ausgabeaktion der Applikationsschicht in genau einem durch UDP versendetem Paket.

Mögliche Probleme bei der Nutzung von UDP

Auf Grund der quasi nicht vorhandenen Kontrollen, ergeben sich potentielle Probleme, die von der jeweiligen Applikation selbst geregelt werden müssen.

Der UDP-Header

Der UDP-Header besteht aus lediglich vier 16-bit Feldern. Der Reihenfolge nach beinhalten sie : Die Portnummer des Senders, die Portnummer des Empfängers, die Länge des UDP-Paketes sowie die UDP-Prüfsumme.


Der UDP-Header

Die Länge eines UDP-Paketes wird in Byte gezählt und beträgt aufgrund des Headers mindestens acht. Sowohl die Sender-Portnummer als auch die Prüfsumme sind optional. Diese Felder sollten Null enthalten, sofern ihre Funktion nicht benötigt wird. Da die Prüfsumme im Einerkomplement vorliegt, stellt dies keine Einschränkung dar. Ist eine berechnete Summe null, so wird die Darstellung der Null verwendet, bei der alle Bits gesetzt sind.

Die UDP-Prüfsumme

Die Prüfsumme des UDP-Protokolls verdient besonderes Augenmerk, denn ihr kommt gewissermaßen ein Doppelrolle zu. Sie wird als Summe von 16-bit Wörtern gebildet. Sollte die Anzahl der Bytes im Datenpaket ungerade sein, wird deshalb ein extra Nullbyte angehängt. Dieses Byte wird nicht mit übertragen und findet sich deshalb auch nicht in der Länge des UDP-Paketes wieder.

Wie bei der IP-Prüfsumme werden die 16-bit Zahlen aufaddiert und zuletzt von der Summe das Einerkomplement gebildet. Dadurch müssen bei der Kontrolle der Prüfsumme lediglich alle 16-bit Wörter des Datenpaketes auf die Prüfsumme aufaddiert werden. Sind danach nicht alle Bits gesetzt, liegt ein Prüfsummenfehler vor.

Da die UDP-Prüfsumme (anders als die IP-Prüfsumme) auch den Datenbereich des Paketes abdeckt, können mit ihr so kleinere Übertragungsfehler bemerkt werden.

Wie schon erwähnt hat diese Prüfsumme allerdings eine erweiterte Funktionalität. Denn bevor sie tatsächlich berechnet wird, wird dem Datenpaket ein zusätzlicher Header - ein sogenannter "Pseudo-Haeder" - angefügt. Dieser wird ebenfalls nicht übertragen und bei der Länge nicht eingerechnet.

Der Pseudo-Header

Der Pseudo-Header besteht aus sechs 16-bit Worten.


Der UDP-Pseudo-Header

Zunächst zwei 32-bit-IP-Adressen - die des Senders und die des Empfängers - dann ein Nullbyte (für spätere Erweiterungen) gefolgt von einem Byte für die Nummer des Protokolltyps und 16 Bit für die Länge des gesamten UDP-Paketes. Diese Daten müssen zum Testen der Prüfsumme aus dem IP-Header ausgelesen und in Form des Pseudo-Headers zum UDP-Paket hinzugefügt werden.

Da die Prüfsumme so mit der ursprünglichen Adresse berechnet und mit der letztlich tatsächlich erreichten überprüft wird, ergibt sich eine zusätzliche Kontrolle, ob das Paket auch sein wirkliches Ziel erreicht hat. Durch die Nummer des Protokolltyps wird zusätzlich erkannt, falls die IP-Schicht das Paket an das falsche Transportprotokoll weitergeleitet haben sollte.

Die UDP-Prüfsumme und das Schichten-Konzept

Um den Pseudo-Header zu erstellen der für die Berechnung der Prüfsumme notwendig ist, benötigt das UDP-Protokoll eine Information der IP-Schicht. Während die Ziel-IP dem Sender bekannt und die Nummer des Protokolltyps für UDP eindeutig ist, ist die Senderadresse nur der IP-Schicht bekannt. Das UDP-Protokoll kann nun einfach diese Adresse erfragen, den Pseudo-Header erstellen und ihn nach Berechnung der Prüfsumme verwerfen. Effizienter ist es jedoch, wenn das UDP-Protokoll das eigene Datenpaket bereits mit einem IP-Header versieht, in den es die bekannten Werte einsetzt und das Paket danach an das IP-Protokoll weiter reicht, welches nun nur noch die fehlenden Werte initialisieren braucht. Eine solche Implementation verletzt natürlich das Schichten-Modell, mit dem Konzept der strikten Trennung der einzelnen Schichten und ihrer Funktionen. Dennoch ist sie als praktischer Kompromiss zu diesem Konzept vertretbar. Denn sie ändert prinzipiell nichts am Aufbau und der Funktionsweise der Protokollstruktur.

Zusammenfassung

Das UDP-Protokoll ist ein Transportprotokoll der TCP/IP-Protokollfamilie. Es setzt direkt auf dem IP-Protokoll auf und obwohl das Schichten-Konzept eine strikte Trennung der Schichten vorsieht, arbeiten die beiden eng zusammen. Zur Adressierung des Sender- und des Empfängerprozesses werden 16-Bit-Integer-Portnummern verwendet. Das UDP-Protokoll stellt grundlegende Funktionen zur Verfügung, um der Applikations-Schicht einen netzwerkunabhängigen Datenversand mit dem verbindungslosen IP-Protokoll zu ermöglichen. Das komplette UDP-Paket wird dazu einfach im Datenbereich eines IP-Paketes versendet, wodurch das UDP-Protokoll keinerlei Kontrolle über die sichere Ankunft versendeter Daten bietet. Zum Erkennen von Datenübertragungsfehlern beinhaltet es lediglich eine optionale Prüfsumme. Jegliche weiteren Sicherheitsmaßnahmen obligen der Applikation und somit dem Programmierer.

Literatur

  [Universität Karlsruhe] [Institut für Technische Informatik] [E-Mail an Autor]  
Letzte Änderung: 2000-10-25 10:38:22