4. Modélisation TCP/IP

Le nom de ce modèle de référence provient de ses deux principaux protocoles. Ce modèle est apparu en 1974 avec la construction de l'ancêtre militaire de l'Internet, l'ARPANET. Les objectifs principaux de cette modélisation sont :

  • relier des réseaux hétérogènes de façon transparente (lignes téléphoniques, réseaux locaux, etc),

  • garantir les connexions quel que soit l'état des lignes de transmission (commutation de paquets),

  • assurer le fonctionnement d'applications très différentes (transfert de fichier, multimédia, etc).

Modèle DoD
Network Access

La couche d'accès réseau a pour rôle de transmettre les données sur le média physique utilisé. En fonction du type de réseau, des protocoles différents peuvent être utilisés à ce niveau.

Internet

La couche inter-réseaux a pour rôle de transmettre les données à travers une série de réseaux physiques différents qui relient un hôte source avec un hôte destination. Les protocoles de routage sont étroitement associés à ce niveau. IP est le protocole routé de base sur l'Internet.

Host-to-Host

La couche hôte-à-hôte prend en charge la gestion de connexion, le contrôle de flux, la retransmission des données perdues et d'autres modes de gestion des flux. Les protocoles TCP et UDP sont dédiés à ces fonctions de transport.

Process/Application

La couche application sert à l'exécution des protocoles de niveau utilisateur tels que les échanges de courrier électronique (SMTP), le transfert de fichiers (FTP) ou les connexions distantes (telnet).

4.1. Point fort : les protocoles

Le fait que ce modèle porte le nom de ces protocoles est lourd de signification. Si la démarche de recherche de consensus dans le développement du modèle s'apparente à la démarche suivie pour le modèle OSI, les spécifications ont été directement accessibles pour un public beaucoup plus large.

C'est ce principe de publication de RFC ( Request for comments) qui a favorisé le développement des protocoles au profit du modèle. Tous les protocoles de l'Internet ont été «standardisés» à l'aide de ces documents. Lorsque quelqu'un met au point un protocole, il le soumet à la communauté à l'aide d'un document RFC. Ce travail est ensuite repris et amélioré par d'autres qui publient un nouveau RFC et ainsi de suite. C'est la démarche d'origine de développement des logiciels libres.

Ce travail à base de propositions ouvertes s'est montré très efficace puisqu'il a supplanté le modèle issu de l'ISO, l'organisme officiel de normalisation. Dès les premiers documents RFC, les piles de protocoles ont été illustrées.

Protocoles TCP/IP

4.2. Point faible : le modèle

La notion de modélisation n'est pas apparue comme une priorité relativement au développement des protocoles. Pour répondre aux objectifs du modèle Internet, ses développeurs ne se sont que très peu intéressés aux modes de transmission de l'information. Ils devaient utiliser l'existant de façon transparente. Le modèle Internet est donc très incomplet sur les aspects transmission.

En reprenant le principe à l'origine du réseau de communication militaire ARPANET, on doit pouvoir communiquer d'un point à un autre de l'Internet «quel que soit l'état du réseau». Une grande partie de l'infrastructure peut être détruite par une frappe nucléaire et les communications doivent toujours être possibles. C'est ce mode de fonctionnement singulier qui a conduit à l'adoption d'un réseau à commutation de paquets fonctionnant en mode non connecté sans aucune hiérarchie. Si un autre principe avec supervision, hiérarchie et mode connecté avait été retenu il suffirait qu'un point névralgique soit touché pour interrompre l'ensemble des communications.

C'est donc sur les couches basses qui traitent de la transmission de l'information que le modèle OSI conserve l'avantage. Le protocole IP est une implémentation particulière des fonctions de la couche réseau décrites dans le modèle OSI. De la même façon, les protocoles TCP et UDP sont des implémentations particulières des fonctions de la couche transport.

4.3. Couche Internet : le protocole IP

Pour répondre aux objectifs énoncés ci-dessus, le principe d'un réseau à commutation de paquets en mode non connecté a été retenu. Ce type de réseau correspond à un mode particulier d'utilisation de la couche réseau (3) du modèle OSI. Le fonctionnement de la couche réseau du modèle TCP/IP a été décrit pour la première fois dans le document standard RFC791 Internet Protocol.

Le rôle de la couche Internet est de transmettre des paquets sur n'importe quel type de liaison indépendamment les uns des autres. Les paquets émis dans un certain ordre peuvent ainsi être reçus dans un autre ordre en différents fragments.

Par principe, ce protocole ne dispose que de mécanismes de détection d'erreur. La correction d'erreur et donc la fiabilisation des communications ne se joue pas au niveau réseau mais au niveau transport avec le protocole TCP.

Le recours à la commutation de paquets a une autre conséquence. Chaque paquet doit contenir les adresses de l'émetteur et du destinataire. Ces adresses servent non seulement à identifier les extrémités en communication, mais elles sont aussi utilisées par les routeurs pour prendre leurs décisions d'acheminement du trafic entre ces extrémités.

Aujourd'hui, il existe deux versions de protocole IP.

  • Le protocole IPv4, dont les adresses sont représentées sur 32 bits, est le plus largement utilisé mais son espace d'adressage arrive à épuisement puisque toutes les adresses disponibles ont déjà été attribuées par l'IANA.

    Le document Adressage IPv4 présente le format des adresses du protocole IPv4 ainsi que les différentes évolutions des mécanismes de découpage du plan d'adressage en groupes logiques adaptés aux différents usages.

  • Le protocole IPv6, dont les adresses sont représentées sur 128 bits, est adopté progressivement mais à un rythme très lent. Au delà du gain en espace d'adressage, l'en-tête IPv6 est plus simple que l'en-tête IPv4 et les traitements d'analyse doivent être plus légers et raccourcir les temps de commutation dans les équipements d'interconnexion.

En-tête paquet IPv4

En-tête paquet IPv4

En-tête paquet IPv4

Version : 4 bits

Version du protocole IP codée sur 4 bits : 0100 pour IPv4 et 0110 pour IPv6.

Internet Header Length : 4 bits, IHL

Longueur de l'en-tête en mots de 32 bits. Cette valeur est utilisée pour distinguer la partie en-tête de la partie données du paquet. La représentation usuelle de l'en-tête se fait sur 32 bits de largeur. Comme les champs Options et Padding ne sont pas obligatoires, la valeur minimum du champ IHL est 5 (0101).

Type Of Service : 8 bits, TOS

Champ découpé en 2 parties. Les 3 premiers bits sont appelés precedence et les 5 derniers représentent le type de service. La définition d'origine prévoyait 3 choix : low-delay, high-reliability et high-throughput. Ce «marquage» des paquets est utilisable pour définir des flux prioritaires sur une interconnexion réseau «sous contrôle». Sur l'Internet, les opérateurs définissent leurs propres priorités ; donc leurs propres valeurs pour ce champ. Voir le document HOWTO du routage avancé et du contrôle de trafic sous Linux.

Total Length : 16 bits

Longueur du datagramme : en-tête & données. La taille minimum est de 21 octets (en-tête + 1 octet de donnée). Comme se champ est représenté sur 16 bits, la taille maximum est de 2^16 - 1, soit 64 Ko.

Identification : 16 bits

Chaque paquet IPv4 reçoit un numéro d'identification à sa création. Il est possible qu'un paquet soit découpé en fragments avant d'atteindre sa destination finale. Chaque fragment appartient au même paquet IPv4. Chaque fragment possède le même numéro d'identification.

Flags : 3 bits

Ce champ contient 3 indicateurs d'état :

  • Reserved flag : doit toujours être à 0.

  • Don't Fragment (DF) : à 0 si le paquet peut être fragmenté ; à 1 s'il ne doit pas être fragmenté.

  • More Fragments (MF) : à 1 si d'autres fragments sont attendus ; à 0 s'il n'y a pas/plus de fragments.

Fragment Offset : 13 bits

Position du fragment dans le datagramme courant. Cette position est comptée en octets.

Time To Live : 8 bits, TTL

Ce compteur est décrémenté à chaque traversée de routeur. Si la valeur 0 est atteinte, le paquet est jeté. Cela signifie qu'il ne peut être délivré à sa destination finale. La valeur initiale du champ TTL dépend du système d'exploitation utilisé.

Protocol : 8 bits

Ce champ spécifie le protocole utilisé dans les données du paquet IP. Par exemple, la valeur 1 indique que le protocole utilisé est ICMP. On sait ainsi que ce paquet n'est pas destiné à une application. Les différentes valeurs de ce champs sont listées dans le fichier /etc/protocols sur les systèmes GNU/Linux ou *BSD.

Header Checksum : 16 bits

A chaque création ou modification d'un paquet, une somme de contrôle (cyclic redundancy check) est calculée sur son en-tête. Lorsque le paquet arrive à destination, cette somme est recalculée. Si le résultat diffère, c'est que le paquet a été endommagé lors de son trajet.

Source Address : 32 bits

Adresse IPv4 de l'hôte qui a émis le paquet.

Destination Address : 32 bits

Adresse IPv4 de l'hôte qui doit recevoir le paquet.

Options and Padding

Cette partie de l'en-tête est optionnelle. Ce champ est utilisé pour fournir des instructions spécifiques de distribution du paquet qui ne sont pas couvertes par les autres champs de l'en-tête. La taille maximum de ces instructions est limitée à 40 octets regroupés en double mots de 32 bits. Les bits de padding servent à compléter le dernier double mot de 32 bits.

Data

C'est le dernier champ du paquet IPv4. Il contient les données vues de la couche réseau. Celles ci peuvent débuter par un en-tête de couche transport (4) ou un message ICMP.

4.4. Couche Host-to-Host : les protocoles TCP & UDP

Avec la couche transport, on aborde le domaine des communications de bout en bout indépendantes de l'état du sous-réseau. Les paquets de la couche réseau peuvent être acheminés à destination par des chemins différents et dans le désordre. Par nature, le protocole IP n'offre pas de garantie. Les routeurs peuvent se débarrasser des paquets suivant plusieurs critères tels que des erreurs sur les sommes de contrôle, des congestions de trafic sur les interfaces réseau ou des adresses ne correspondant à aucune route connue. Tous les programmes et services de la couche application ne peuvent se contenter d'un mode de fonctionnement aussi «fragile». C'est une des raisons pour laquelle deux protocoles distincts ont été développés pour la couche transport.

4.5. Protocole TCP

Historiquement, TCP est le premier protocole de transport développé pour l'Internet. Les premières spécifications ARPANET prévoyaient un transport de l'information très fiable indépendant du type et de l'état du réseau. Le fonctionnement du protocole TCP a été décrit dans le document RFC793 Transmission Control Protocol.

  • Protocole de bout en bout. Les processus pairs des couches transport de deux équipements connectés dialoguent l'un avec l'autre sans rien connaître du réseau sous-jacent. Les numéros de port source et destination présents dans l'en-tête de segment servent à adresser les processus de couche application en communication.

  • Protocole orienté connexion. La fiabilité du transport TCP dépend de l'établissement d'une connexion entre les processus pairs qui veulent dialoguer. L'établissement d'une connexion est réalisé par l'échange d'informations telles que les numéros de ports, les numéros de séquence et la taille de fenêtre.

  • Multiplexage à l'aide des numéros de ports. Les numéros de ports constituent le mécanisme d'adressage de la couche transport. Ils servent à désigner le processus de la couche application utilisé pour l'émission ainsi que celui utilisé pour la réception.

  • Transfert de données segmenté et ordonné. Le flux des données issues de la couche application est segmenté et comptabilisé lors de l'encapsulation puis délivré dans le même ordre au processus qui le reçoit.

  • Récupération sur erreur. L'utilisation des numéros de séquence et d'acquittement permet de comptabiliser les données transmises et de reprendre l'émission des données non reçues.

  • Contrôle de flux avec fenêtrage. La combinaison de l'utilisation des numéros de séquence et d'acquittement avec la notion de fenêtre permet de contrôler la quantité de données à transmettre avant de procéder à un acquittement. Au début des échanges, la taille de fenêtre est réduite. Si aucune erreur ne survient, cette taille de fenêtre augmente suivant une règle définie. Au contraire, si des erreurs surviennent, la taille de fenêtre diminue de façon à augmenter le nombre des contrôles.

En-tête TCP

Les fonctions d'établissement, de maintien, de libération et de contrôle des échanges ont conduit au développement d'un en-tête comprenant un grand nombre de champs.

En-tête segment TCP
Source Port : 16 bits

Numéro du port source. Ce numéro correspond au point de communication (socket inet) utilisé par le service de la couche application de l'émetteur.

Destination Port : 16 bits

Numéro du port destination. Ce numéro correspond au point de communication (socket inet) utilisé par le service de la couche application du destinataire.

Sequence Number : 32 bits

Le protocole TCP a besoin de garder une trace de toutes les données qu'il reçoit de la couche application de façon à être sûr qu'elles ont bien été reçues par le destinataire. De plus, le protocole doit être sûr que ces données ont été reçues dans l'ordre dans lequel elles ont été envoyées. Il doit retransmettre toute donnée perdue.

On affecte un numéro de séquence à chaque octet de donnée pour en garder une trace lors du processus de transmission, réception et acquittement. Dans la pratique, ce sont des blocs d'octets qui sont gérés en utilisant les numéros de séquence de début et de fin de bloc.

Les numéros de séquence sont nécessaires à la mise en œuvre du système de fenêtre glissante du protocole TCP. C'est ce système qui garantit fiabilité et contrôle de flots de données.

Acknowledgment Number : 32 bits

Le rôle des numéros d'acquittement est le même que celui des numéros de séquence. Simplement, chaque extrémité en communication initie son propre jeu de numéros. Ainsi chaque extrémité assure la fiabilisation et le contrôle de flux de façon autonome.

Data Offset : 4 bits

Nombre de mots de 32 bits contenus dans l'en-tête TCP. Indication du début des données. Tout en-tête TCP, avec ou sans options, est un multiple de mots de 32 bits.

Reserved : 6 bits

Champ réservé pour une utilisation ultérieure. Les 6 bits doivent être à 0.

Control bits : 6 bits

Ces bits sont les indicateurs d'état qui servent à l'établissement, au maintien et à la libération des connexions TCP. Leur rôle est essentiel dans le fonctionnement du protocole.

  • URG : indique que le champ Urgent Pointer est significatif. Une partie des données du segment sont urgentes.

  • ACK : indique que le champ Acknowledgment field est significatif. Le segment acquitte la transmission d'un bloc de d'octets.

  • PSH : indique à l'hôte en réception de «pousser» toutes les informations en mémoire tampon vers l'application en couche supérieure. L'émetteur notifie le récepteur qu'il a transmis toutes ses données «pour l'instant».

  • RST : indique un arrêt ou un refus de connexion.

  • SYN : indique une demande de synchronisation de numéro de séquence. Demande d'ouverture de connexion TCP.

  • FIN : indique que l'émetteur n'a plus de données à transmettre. Demande de libération de connexion.

Window : 16 bits

Nombre d'octets de données à transmettre à partir de celui indiqué par le champ Acknowledgment.

Checksum : 16 bits

Somme de contrôle sur 16 bits de l'en-tête et des données.

Urgent Pointer : 16 bits

Ce champ est interprété uniquement si le bit de contrôle URG est à 1. Le pointeur donne le numéro de séquence de l'octet qui suit les données urgentes.

Options : variable entre 0 et 44 octets

Il existe 2 formats d'options : un seul octet de catégorie d'option ou un octet de catégorie d'option suivi d'un octet de longueur d'option et de l'octet des données de l'option.

4.6. Protocole UDP

Le protocole UDP est apparu avec le développement des réseaux locaux dont la fiabilité est connue à priori. Il permet de s'affranchir des fonctions de contrôle. C'est un protocole minimum sans garantie de délivrance des messages et sans séquencement. En conséquence, l'en-tête est très nettement simplifié et le nombre de champs est très réduit.

Ce protocole présente un grand intérêt dans les applications orientées temps réel dans la mesure où il n'introduit aucune latence relativement aux fonctions de contrôle de flux de TCP.

En-tête UDP

En-tête datagramme UDP

Les numéros de ports constituent le mécanisme d'adressage pour les communications de bout en bout comme dans le cas du protocole TCP.

4.7. Unités de données

Les protocoles listés ci-avant échangent des données entre eux lors du passage d'une couche à l'autre. On parle d'unité de donnée de protocole ou Protocol Data Unit (PDU) propre à chaque couche. De nos jours, on ne retrouve l'acronyme PDU que dans le contexte de l'étude du protocole Spanning Tree au niveau liaison de données.

Avec l'utilisation systématique des protocoles de l'Internet, l'acronyme PDU a laissé la place à des termes spécifiques à chaque couche. Voici un schéma sur lequel figure ces termes ainsi que les dimensions en octets de chaque élément.

Encapsulation et unités de données

Cette représentation fait apparaître le format de trame Ethernet. Même si la technologie Ethernet n'est pas directement liée aux protocoles de l'Internet, son format de trame tend à devenir universel. On le retrouve avec les technologies Wifi, les connexions ADSL ou FTTH avec PPPoE et même de plus en plus sur les réseaux étendus.

Avant 1997, date à laquelle l'IEEE a incorporé le format «historique» de trame Ethernet dans le standard officiel, on devait systématiquement distinguer deux formats de trames suivant le champ Type/Longueur.