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
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.
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.
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.
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)
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.
Auf Grund der quasi nicht vorhandenen Kontrollen, ergeben sich
potentielle Probleme, die von der jeweiligen Applikation selbst
geregelt werden müssen.
- Datenpakete können schlicht verlorengehen. Das UDP-Protokoll
erfährt hiervon nichts und interessiert sich auch nicht dafür. Ein
erneuter Versand der Daten bleibt aus.
- Wird die Prüfsumme verwendet, und ist diese bei ihrer Überprüfung
falsch, wird das betroffene Datenpaket lediglich verworfen. Auch hier
bleibt ein erneuter Versand aus.
- Auf Grund der Struktur des Internets, kann ein einzelnes Paket auf
verschiedenen Wegen sein Ziel mehrfach erreichen, sich also faktisch
duplizieren.
- Da die einzelnen Datenpakete vollkommen unabhängig voneinander
versendet werden, ist die Reihenfolge ihrer Ankunft praktisch
unbekannt.
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 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 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.
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.
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.
- [CO]:
Douglas E. Comer:
Internetworking with TCP/IP volume
1 principles, protocols and architecture.
Prentice-Hall, New Jersey,
1995.
- [ST]:
W. Richard Stevens:
TCP/IP Illustrated, Volume 1 The
Protocols.
1994 Addison Wesley Longman, Inc.
- [MN]:
Matthew Naugle:
Network Protocol Handbook.
1994
McGraw-Hill, Inc.
|
Letzte Änderung: 2000-10-25 10:38:22
|