Zum Hauptinhalt springen

RFC 768 - Benutzerdatagrammprotokoll (User Datagram Protocol)

Veröffentlichungsdatum: 28. August 1980
Autor: J. Postel (ISI - Information Sciences Institute)
Status: Standardprotokoll


Einführung (Introduction)

Dieses Benutzerdatagrammprotokoll (User Datagram Protocol, UDP) ist definiert, um einen Datagramm-Modus der paketvermittelten Computerkommunikation in der Umgebung eines miteinander verbundenen Satzes von Computernetzwerken verfügbar zu machen. Dieses Protokoll setzt voraus, dass das 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 und zuverlässige Zustellung von Datenströmen erfordern, sollten das Transmission Control Protocol (TCP) [2] verwenden.


Format (Format)

                  0      7 8     15 16    23 24    31  
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| | |
| Length | Checksum |
+--------+--------+--------+--------+
|
| data octets ...
+---------------- ...

User Datagram Header Format

Felder (Fields)

Quellport (Source Port)

Der Quellport (Source Port) ist ein optionales Feld; wenn er sinnvoll ist, gibt er den Port des sendenden Prozesses an und kann in Ermangelung anderer Informationen als der Port angesehen werden, an den eine Antwort gerichtet werden sollte. Wenn nicht verwendet, wird ein Wert von Null eingefügt.

Zielport (Destination Port)

Der Zielport (Destination Port) hat eine Bedeutung im Kontext einer bestimmten Internet-Zieladresse.

Länge (Length)

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 beträgt.)

Prüfsumme (Checksum)

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, der bei Bedarf am Ende mit Null-Oktetten aufgefüllt wird, um ein Vielfaches von zwei Oktetten zu ergeben.

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 das in TCP verwendete.

                  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 (zum Debuggen oder für höherwertige Protokolle, die dies nicht berücksichtigen).


Benutzerschnittstelle (User Interface)

Eine Benutzerschnittstelle sollte Folgendes ermöglichen:

  • die Erstellung neuer Empfangsports (Receive Ports),

  • Empfangsoperationen auf den Empfangsports, die die Datenoktette sowie 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 (MUST) 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 des gesamten Internet-Headers zurückgeben. Eine solche Schnittstelle würde es dem UDP auch ermöglichen, ein vollständiges Internet-Datagramm samt 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 Name Server [3] und das Trivial File Transfer [4].


Protokollnummer (Protocol Number)

Dies ist Protokoll 17 (21 oktett), wenn es im Internet Protocol verwendet wird. Andere Protokollnummern sind in [5] aufgeführt.


Referenzen (References)

[1] Postel, J., "Internet Protocol," RFC 760, USC/Information Sciences Institute, January 1980.

[2] Postel, J., "Transmission Control Protocol," RFC 761, USC/Information Sciences Institute, January 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, January 1980.

[5] Postel, J., "Assigned Numbers," USC/Information Sciences Institute, RFC 762, January 1980.


  • Offizieller Text: https://www.rfc-editor.org/rfc/rfc768.txt
  • Offizielle Seite: https://datatracker.ietf.org/doc/html/rfc768