VI Protocole UDP

1 UDP - User Datagram Protocol

UDP est l'acronyme de ``User Datagram Protocol'', il est défini dans la RFC 768 [Postel 1980]. Les données encapsulées dans un en-tête UDP sont des ``paquets UDP''.

1.1 Identification de la destination

Rappel : Au niveau de la couche Internet les datagrammes sont routés d'une machine à une autre en fonction des bits de l'adresse IP qui identifient le numéro de réseau. Lors de cette opération aucune distinction n'est faite entre les services ou les utilisateurs qui émettent ou recoivent des datagrammes, ie tous les datagrammes sont mélangés.

La couche UDP ajoute un mécanisme qui permet l'identification du service (niveau Application). En effet, il est indispensable de faire un tri entre les divers applications (services) : plusieurs programmes de plusieurs utilisateurs peuvent utiliser simultanément la même couche de transport et il ne doit pas y avoir de confusion entre eux.

Pour le système Unix les programmes sont identifiés de manière unique par un numéro de processus, mais ce numéro est éphémère, non prévisible à distance, il ne peut servir à cette fonction.

L'idée est d'associer la destination à la fonction qu'elle remplie. Cette identification se fait à l'aide d'un entier positif que l'on baptise port.

• Le système d'exploitation local a à sa charge de définir le mécanisme qui permet à un processus d'accéder à un port.

• La plupart des systèmes d'exploitation fournissent le moyen d'un accès synchrone à un port. Ce logiciel doit alors assurer la possibilité de gérer la file d'attente des paquets qui arrivent, jusqu'à ce qu'un processus (Application) les lise. A l'inverse, l'OS, `` Operating System '', bloque un processus qui tente de lire une donnée non encore disponible.

Pour communiquer avec un service distant il faut donc avoir connaissance de son numéro de port, en plus de l'adresse IP de la machine elle-même.

cm

On peut prévoir le numéro de port en fonction du service à atteindre, c'est l'objet du paragraphe 1.3.

cm

La figure VI.01 explicite la notion de port. La couche IP sépare les datagrammes SCTP, TCP et UDP grâce au champ PROTO^VI1 de son en-tête, l'association du protocole de transport et du numéro de port identifie un service sans ambiguïté.

cm

Conceptuellement on s'apperçoit alors que rien ne s'oppose à ce qu'un même service (Numéro de port) soit attribué conjointement aux trois protocoles (en pointillés sur la figure). Cette situation est d'ailleurs courante dans la réalité des serveurs.

cm figure VI.01 -- Numéro de port comme numéro de service

1.2 Description de l'en-tête

Un paquet UDP est conçu pour être encapsulé dans un datagramme IP et permettre un échange de données entre deux applications, sans échange préliminaire. Ainsi, si les données à transmettre n'obligent pas IP
`a fragmenter (cf page ), un paquet UDP génère un datagramme IP et c'est tout !

cm figure VI.02 -- UDP encapsulé dans IP

• UDP apporte un mécanisme de gestion des ports, au dessus de la couche Internet.

• UDP est simplement une interface au dessus d'IP, ainsi l'émission des messages se fait-elle sans garantie de bon acheminement. Plus généralement, tous les défauts d'IP recensés au chapitre précédent sont applicables à UDP.

  Plus particulièrement, les paquets à destination d'une application UDP sont conservés dans une pile de type FIFO. Si l'application destinatrice ne les ``consomme'' pas assez rapidement, les plus anciens paquets risquent d'être écrasés par les plus récents...Un risque supplémentaire (par rapport aux propriétés d'IP déjà connues) de perte de données.

• Il n'y a aucun retour d'information au niveau du protocole pour apporter un quelconque moyen de contrôle sur le bon acheminement des données.

  C'est au niveau applicatif qu'il convient de prendre en compte cette lacune.

• UDP est aussi désigné comme un mode de transport ``non connecté'', ou encore mode datagramme, par opposition à TCP ou SCTP que nous examinerons dans les prochains chapitres.

Parmis les utilisations les plus courantes d'UDP on peut signaler le serveur de noms^VI2, base de données répartie au niveau mondial, et qui s'accomode très bien de ce mode de transport.

En local d'autres applications très utiles comme tftp ou nfs sont également susceptibles d'employer UDP.

La figure VI.03 décrit la structure de l'en-tête.

cm figure VI.03 -- Structure de l'en-tête UDP

UDP SOURCE PORT

Le numéro de port de l'émetteur du paquet. Ce champ est optionnel, quand il est spécifié il indique le numéro de port que le destinataire doit employer pour sa réponse. La valeur zéro (0) indique qu'il est inutilisé, le port 0 n'est donc pas celui d'un service valide.

UDP DESTINATION PORT

Le numéro de port du destinataire du paquet.

MESSAGE LENGTH

C'est la longueur du paquet, donc comprennant l'en-tête et le message.

• La longueur minimal est 8
• La longueur maximale est 65 535 - H(IP). Dans le cas courant (IP sans option) cette taille maximale est donc de 65 515.

CHECKSUM

Le checksum est optionnel et toutes les implémentations ne l'utilisent pas. S'il est employé, il porte sur un pseudo en-tête constitué de la manière suivante :

cm figure VI.04 -- Cas du checksum non nul

Ce pseudo en-tête est prévu initialement pour apporter une protection en cas de datagrammes mal routés !

1.3 Ports réservés -- ports disponibles

Le numéro de port est un entier 16 bits non signé, les bornes sont donc [0,65535], par construction. Nous avons vu précédement que le port 0 n'est pas exploitable en tant que désignation de service valide, donc le segment réellement exploitable est [1,65535].

Toute machine qui utilise la pile TCP/IP se doit de connaître un certain nombre de services bien connus, repérés par une série de ports bien connus ou ``well known port numbers'', pour pouvoir dialoguer avec les autres machines de l'Internet (vs Intranet). Sur une machine Unix, cette liste de services est placée dans le fichier /etc/services et lisible par tous les utilisateurs et toutes les applications.

En effet, comme nous l'examinerons en détail dans le cours de programmation, un service (comprendre un programme au niveau applicatif) qui démarre son activité réseau (et qui donc est considéré comme ayant un rôle de serveur) s'attribue le (les) numéro(s) de port qui lui revient (reviennent) conformément à cette table.

Nom	Port	Proto	Commentaire
echo	7	tcp
echo	7	udp
ftp-data	20	tcp	#File Transfer [Default Data]
ftp-data	20	udp	#File Transfer [Default Data]
ftp	21	tcp	#File Transfer [Control]
ftp	21	udp	#File Transfer [Control]
ssh	22	tcp	#Secure Shell Login
ssh	22	udp	#Secure Shell Login
smtp	25	tcp	mail #Simple Mail Transfer
smtp	25	udp	mail #Simple Mail Transfer
domain	53	tcp	#Domain Name Server
domain	53	udp	#Domain Name Server
http	80	tcp	www www-http #World Wide Web HTTP
http	80	udp	www www-http #World Wide Web HTTP
pop3	110	tcp	#Post Office Protocol - Version 3
pop3	110	udp	#Post Office Protocol - Version 3
imap	143	tcp	#Interim Mail Access Protocol
imap	143	udp	#Interim Mail Access Protocol
https	443	tcp	#Secure World Wide Web HTTP
https	443	udp	#Secure World Wide Web HTTP

cm

Le tableau de la figure VI.05 présente quelques uns des ports bien connus plus connus les plus utilisés, il y en a quantité d'autres...

Une autorité, l'IANA^VI3, centralise et diffuse l'information relative à tous les nombres utilisés sur l'Internet via une RFC. La dernière en date est la RFC 1700, elle fait plus de 200 pages !

Par voie de conséquence cette RFC concerne aussi les numéros de ports.

1.3.1 Attribution des ports ``ancienne méthode''

Historiquement les ports de 1 à 255 sont réservés aux services bien connus, plus récemment, ce segment à été élargi à [1,1023]. Aucune application ne peut s'attribuer durablement et au niveau de l'Internet un numéro de port dans ce segment, sans en référrer à l'IANA, qui en contrôle l'usage.

À partir de 1024 et jusqu'à 65535, l'IANA se contente d'enregistrer les demandes d'usage et signale les éventuels conflits.

1.3.2 Attribution des ports ``nouvelle méthode''

Devant l'explosion du nombre des services enregistrés l'IANA a modifié la segmentation^VI4qui précède. Désormais les numéros de ports sont classés selon les trois catégories suivantes :

1. Le segment [1,1023] est toujours réservés aux services bien connus.

   Les services bien connus sont désignés par l'IANA et sont mis en uvre par des applications qui s'exécutent avec des droits privilégiés (root sur une machine Unix)

2. Le segment [1024,49151] est celui des services enregistrés.

   Ils sont énumérés par l'IANA et peuvent être employés par des processus ayant des droits ordinaires.

   Par exemple :

   Nom	Port	Proto	Commentaire
   bpcd	13782	tcp	VERITAS NetBackup
   bpcd	13782	udp	VERITAS NetBackup

   
   

3. Le segment [49152, 65535] est celui des attributions dynamiques et des services privés ; nous en examinerons l'usage dans le cours de programmation.

2 Bibliographie

Pour en savoir plus :

RFC 768

``User Datagram Protocol.'' J. Postel. Aug-28-1980. (Format: TXT=5896 bytes) (Status: STANDARD)

RFC 1035

``Domain names - concepts and facilities.'' P.V. Mockapetris. Nov-01-1987. (Format: TXT=129180 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Obsoleted by RFC1065, RFC2065) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181) (Status: STANDARD)

RFC 1700

``ASSIGNED NUMBERS.'' J. Reynolds,J. Postel. October 1994. (Format: TXT=458860 bytes) (Obsoletes RFC1340) (Also STD0002) (Status: STANDARD)

RFC 1918

``Address Allocation for Private Internets.'' Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot & E. Lear. February 1996. (Format: TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005) (Status: BEST CURRENT PRACTICE)

Sans oublier :

• W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols - Addison-Wesley -- 1994

• Douglas Comer - Internetworking with TCP/IP - Principles, protocols, and architecture - Prentice-Hall