inetdoc.net

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.

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.

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.

En-tête paquet IPv4

En-tête paquet IPv4

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.

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.

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.

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

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.

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.

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.