RFC 768 : User Datagram
Protocol (UDP) - Specification
Crédits : J. Postel, ISI,
Traduction : V.G. FREMAUX
/ Ingénieur Professeur / EISTI
Statut : Standard
Note du traducteur :
La suprématie américaine en matière
d'Internet est elle un fatalité absolue. Il faut croire que nous
avons du mal, nous les francophones à comprendre la nécessité
impérieuse de défendre notre culture et de la transmission
de documentation.
J'ai donc entrepris ce travail colossal de traduire
(ne rêvons pas complètement ! j'en profite pour me former
également) les principales spécifications concernant les
technologies Internet.
D'autres RFC sont en préparation. Cela prendra
seulement un petit peu de temps.
Le texte suivant est la traduction intégrale
de la spécification UDP, telle qu'éditée par les auteurs
originaux du protocole, sans ajouts, commentaires, ni omissions. Ce document
est un standard reconnu et approuvé par la communauté Internet.
Introduction
Le protocole User Datagram Protocol (UDP) est défini
dans le but de fournir une communication par paquet unique entre deux processus
dans un environnement réseau étendu. Ce protocole suppose
l'utilisation du protocole IP comme support de base à la communication.
Ce protocole définit une procédure permettant
à une application d'envoyer un message court à une autre
application, selon un mécanisme minimaliste. Ce protocole est transactionnel,
et ne garantit ni la délivrance du message, ni son éventuelle
duplication. Les applications nécessitant une transmission fiabilisée
et ordonnée d'un flux de données implémenteront de
préférence le protocole TCP ( 1000 Transmission Control Protocol)
[2].
Format
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| Port | Port |
| Source | Destinataire |
+--------+--------+--------+--------+
| | |
| Longueur | Checksum |
+--------+--------+--------+--------+
| données ... |
+---------------- ... --------------+
En-tête UDP
Champs
Le Port Source est un champ optionnel. Lorsqu'il est
significatif, il indique le numéro de port du processus émetteur,
et l'on supposera, en l'absence d'informations complémentaires,
que toute réponse devra y être dirigée. S'il n'est
pas utilisé, ce champ conservera une valeur 0.
Le Port Destinataire a une signification dans le cadre
d'adresses Internet particulières.
La Longueur compte le nombre d'octets dans le datagramme
entier y compris le présent en-tête. (Et par conséquent
la longueur minimale mentionnée dans ce champ vaut huit, si le datagramme
ne transporte aucune donnée).
Le Checksum se calcule en prenant le complément
à un de la somme sur 16 bits des compléments à un
calculé sur un pseudo en-tête constitué de l'information
typique d'une en-tête IP, l'en-tête UDP elle-même, et
les données, le tout additionné d'un octet nul éventuel
afin que le nombre total d'octets soit pair.
La pré en-tête ajoutée avant l'en-tête
UDP contient l'adresse IP source, l'adresse IP destinataire, le code de
protocole, et la longueur du segment UDP. Cette information permet d'augmenter
l'immunité du réseau aux erreurs de routage de datagrammes.
La procédure de calcul du Checksum est la même que pour TCP.
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| adresse source |
+--------+--------+--------+--------+
| adresse destination |
+--------+--------+--------+--------+
| zéro |protocol| Longueur UDP |
+--------+--------+--------+--------+
Si le calcul du checksum vaut zéro, il sera transmis
tous ses bits à un (le complément à un). UN Checksum
transmis avec une valeur zéro a effectivement une signification
particulière. Dans ce cas, le segment indique c8f qu'aucun Checksum
n'a été calculé (pour des besoins de mise au point
ou pour des protocoles de niveaux supérieurs qui rendent cette vérification
inutile).
Interface Utilisateur
L'interface utilisateur doit permettre l'ouverture de
nouveaux ports de réception, la réception des données
et leur transmission ainsi que celle de l'adresse source à l'application
sur le port de réception mis en place, et doit mettre en place une
commande permettant l'émission d'un datagramme, par laquelle seront
spécifiés les données, l'adresse et ports source et
destination à utiliser.
Interface IP
Le module UDP doit extraire les adresses source et destination
de l'en-tête IP, et vérifier le numéro de protocole.
Une interface UDP/IP plausible pourrait retourner le datagramme entier
y compris l'en-tête Internet en réponse du datagramme reçu.
Une interface devra pour cela permettre à UDP de passer un datagramme
Internet complet avec une en-tête IP à la couche IP elle même
pour émission. IP n'aura plus qu'à vérifier la cohérence
des champs d'en-tête IP préparés par UDP et calculer
le Checksum.
Applications du Protocole
Ce protocole sera utilisé principalement pour
les communications avec les serveurs de noms de domaines [3], et dans les
transactions utilisant le protocole Trivial File Transfer [4].
Numéro de protocole
Ce protocole porte le numéro 17 (21 en octal)
lorsqu'il est transporté par le Protocole Internet. D'autres numéros
de protocoles pour d'autres couches support sont données dans la
référence [5].
Références
[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.