Cours d'introduction à TCP/IP

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 reçoivent 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 diverses 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 remplit. 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. À 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.

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

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 de son entête, l'association du protocole de transport et du numéro de port identifie un service sans ambiguïté.

Conceptuellement on s'aperç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.

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 à fragmenter, un paquet UDP génère un datagramme IP et, c'est tout !

• 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.

Parmi les utilisations les plus courantes d'UDP, on peut signaler le serveur de noms(54), base de données réparties au niveau mondial, et qui s'accommode 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'entête.

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 comprenant l'entête et le message :
  • la longueur minimale 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 entête constitué de la manière suivante :

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

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édemment 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.

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(55), 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.

6-1-3-1. Attribution des ports « ancienne méthode »▲

6-1-3-2. Attribution des ports « nouvelle méthode »▲