RFC 768 - Benutzerdatagrammprotokoll (User Datagram Protocol)
Veröffentlichungsdatum: 28. August 1980
Autor: J. Postel (ISI - Information Sciences Institute)
Status: Standardprotokoll (Standard Protocol)
Einführung (Introduction)
Dieses Benutzerdatagrammprotokoll (User Datagram Protocol, UDP) ist definiert, um einen Datagramm-Modus (Datagram Mode) der paketvermittelten Computerkommunikation in der Umgebung eines verbundenen Satzes von Computernetzwerken verfügbar zu machen. Dieses Protokoll setzt voraus, dass das Internet-Protokoll (Internet Protocol, IP) [1] als zugrundeliegendes Protokoll verwendet wird.
Dieses Protokoll bietet ein Verfahren für Anwendungsprogramme, um Nachrichten an andere Programme mit einem Minimum an Protokollmechanismen zu senden. Das Protokoll ist transaktionsorientiert (Transaction Oriented), und Zustellung sowie Duplikatschutz sind nicht garantiert. Anwendungen, die eine geordnete zuverlässige Zustellung von Datenströmen erfordern, sollten das Übertragungssteuerungsprotokoll (Transmission Control Protocol, TCP) [2] verwenden.
Format
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| | |
| Length | Checksum |
+--------+--------+--------+--------+
|
| data octets ...
+---------------- ...
User Datagram Header Format
Felder (Fields)
Source Port (Quellport)
Der Quellport (Source Port) ist ein optionales Feld; wenn aussagekräftig, gibt er den Port des sendenden Prozesses an und kann in Ermangelung anderer Informationen als der Port angenommen werden, an den eine Antwort adressiert werden sollte. Wenn nicht verwendet, wird ein Wert von Null eingefügt.
Destination Port (Zielport)
Der Zielport (Destination Port) hat eine Bedeutung im Kontext einer bestimmten Internet-Zieladresse.
Length (Länge)
Die Länge (Length) ist die Länge in Oktetten dieses Benutzerdatagramms einschließlich dieses Headers und der Daten. (Dies bedeutet, dass der Mindestwert der Länge acht ist.)
Checksum (Prüfsumme)
Die Prüfsumme (Checksum) ist das 16-Bit-Einerkomplement der Einerkomplement-Summe (One's Complement Sum) eines Pseudo-Headers (Pseudo Header) von Informationen aus dem IP-Header, dem UDP-Header und den Daten, bei Bedarf am Ende mit Null-Oktetten aufgefüllt, um ein Vielfaches von zwei Oktetten zu bilden.
Der Pseudo-Header, der konzeptionell dem UDP-Header vorangestellt ist, enthält die Quelladresse, die Zieladresse, das Protokoll und die UDP-Länge. Diese Informationen bieten Schutz vor fehlgeleiteten Datagrammen. Dieses Prüfsummenverfahren ist dasselbe wie bei TCP.
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| source address |
+--------+--------+--------+--------+
| destination address |
+--------+--------+--------+--------+
| zero |protocol| UDP length |
+--------+--------+--------+--------+
Wenn die berechnete Prüfsumme Null ist, wird sie als alle Einsen übertragen (das Äquivalent in Einerkomplement-Arithmetik). Ein übertragener Prüfsummenwert von allen Nullen bedeutet, dass der Sender keine Prüfsumme generiert hat (für Debugging oder für höhere Protokolle, denen es egal ist).
Benutzerschnittstelle (User Interface)
Eine Benutzerschnittstelle sollte Folgendes ermöglichen:
-
die Erstellung neuer Empfangsports (Receive Ports),
-
Empfangsoperationen auf den Empfangsports, die die Datenoktette und eine Angabe von Quellport und Quelladresse zurückgeben,
-
und eine Operation, die das Senden eines Datagramms ermöglicht, wobei die zu sendenden Daten, Quell- und Zielports sowie Adressen spezifiziert werden.
IP-Schnittstelle (IP Interface)
Das UDP-Modul muss in der Lage sein, die Quell- und Ziel-Internetadressen sowie das Protokollfeld aus dem Internet-Header zu bestimmen. Eine mögliche UDP/IP-Schnittstelle würde als Antwort auf eine Empfangsoperation das gesamte Internet-Datagramm einschließlich aller Internet-Header zurückgeben. Eine solche Schnittstelle würde es dem UDP auch ermöglichen, ein vollständiges Internet-Datagramm mit Header an das IP zum Senden zu übergeben. Das IP würde bestimmte Felder auf Konsistenz überprüfen und die Internet-Header-Prüfsumme berechnen.
Protokollanwendung (Protocol Application)
Die Hauptverwendungen dieses Protokolls sind der Internet-Namensserver (Internet Name Server) [3] und die triviale Dateiübertragung (Trivial File Transfer) [4].
Protokollnummer (Protocol Number)
Dies ist Protokoll 17 (21 oktal), wenn es im Internet-Protokoll verwendet wird. Andere Protokollnummern sind in [5] aufgeführt.
Referenzen (References)
[1] Postel, J., „Internet Protocol", RFC 760, USC/Information Sciences Institute, Januar 1980.
[2] Postel, J., „Transmission Control Protocol", RFC 761, USC/Information Sciences Institute, Januar 1980.
[3] Postel, J., „Internet Name Server", USC/Information Sciences Institute, IEN 116, August 1979.
[4] Sollins, K., „The TFTP Protocol", Massachusetts Institute of Technology, IEN 133, Januar 1980.
[5] Postel, J., „Assigned Numbers", USC/Information Sciences Institute, RFC 762, Januar 1980.
Verwandte Ressourcen
- Offizieller Text:
https://www.rfc-editor.org/rfc/rfc768.txt - Offizielle Seite:
https://datatracker.ietf.org/doc/html/rfc768