L’Internet est construit autour de son protocole de réseau, IP(Internet Protocol), et de son principal protocole de transport, TCP(Transmission Control Protocol).
Le protocole IP correspond à la couche 3 du modèle OSI, la couche réseau. La
« pile » TCP/IP (comme une pile de couches... empilées) n’obéit pas strictement à la nomenclature du modèle OSI : elle comporte une couche liaison de données qui englobe les couches 1 et 2 de l’OSI, la couche IP (réseau) correspond à la couche 3 de l’OSI, la couche TCP1 (transport) correspond à la couche 4 de l’OSI. La couche « applications » englobe tout ce qui relève des couches hautes de l’OSI.
L’architecture de TCP/IP peut être vue sous l’angle suivant. À partir d’un message émis par un utilisateur, chaque couche en partant de la plus haute lui ajoute des en-tête qui contiennent les informations nécessaires à son fonctionnement, ce que montre la figure 6.3 page suivante.
Ainsi, un message électronique sera d’abord doté par votre logiciel de courrier des en-tête applicatifs, en l’occurrence tels que décrits par la RFC 822 révisé en 2822 (ce sont les lignesFrom:,To:,Subject:, etc. qui figurent en tête des messages).
Votre logiciel de courrier mettra également, si besoin est, le contenu de message en forme, toujours afin d’adhérer à ce standard qu’est le RFC 2822. Un message complexe, par exemple mélangeant texte et image, pourra être formaté selon le standard MIME.
VOCABULAIRE Les RFC
LesRequests for Comments (RFC)sont les documents de référence pour le fonctionnement du ré-seau. Citons ici le nom de Jon Postel, éditeur des RFC depuis la première, en 1969, jusqu’à sa mort en 1998, et auteur ou coauteur de 204 d’entre elles, ce qui lui a conféré une influence considérable sur la physionomie du réseau. Toutes les RFC sont accessibles par l’URL(Universal Resource Loca-tor)http://www.ietf.org/rfc/ou sur de nombreux sites miroirs. Nous ne saurions trop en
1. ... ou UDP, autre couche transport disponible au-dessus d’IP.
Message de couche application
Trame de couche liaison de données (Ethernet par exemple) En−tête
conseiller la lecture ; même si la qualité de leur style est inégale, elles fournissent sur l’Internet une information de première main, souvent exposée très clairement, et dont la citation dans les dîners en ville vous assurera une réputation de gourou du réseau.
Après ces transformations, ce message, devenu conforme à la RFC 2822, doit être transporté afin de parvenir jusqu’à son destinataire légitime. Pour cela, votre sys-tème de courrier électronique s’appuie sur un autre standard, le protocole SMTP défini dans la RFC 2821 (qui met à jour la RFC 821). Le protocole SMTP décrit les échanges qui vont se dérouler entre les parties (le système de messagerie de l’expéditeur et celui du destinataire).
C’est cet ensemble structuré qui représente les « données utilisateur » du protocole SMTP et qui sera découpé en segments TCP, chacun doté de l’en-tête convenable décrit à la figure 6.4 page suivante.
Chaque segment TCP sera empaqueté dans un ou plusieurs paquets IP, qui pos-sèdent chacun un en-tête, décrit à la figure 6.5 page 115 pour la version 4 du protocole IP, et à la figure 6.6 page 115 pour la version 6. Et chaque paquet sera
32 bits
(*) UAPRSF : champs de 6 bits de contrôle : URG ACK PSH RST SYN FIN
Données Options
Port d’origine Port de destination
Numéro de séquence Numéro d’acquittement
somme de contrôle
Taille de la fenêtre UAPRSF(*)
Figure 6.4 En-tête de segment TCP
expédié sur la couche liaison de données qui correspond au support physique, Ethernet par exemple.
Le protocole réseau IP fournit à la couche transport un service non fiable non connecté de datagrammes. Le terme datagramme signifie que le flux de bits re-mis par la couche transport (TCP) est découpé en morceaux (les datagrammes) acheminés indépendamment les uns des autres. En général les datagrammes sont transmis en entier sur le réseau, mais le protocole prévoit que tous les segments du réseau n’admettent pas forcément la même taille de données à transmettre, auquel cas il peut arriver qu’un datagramme soit découpé en plusieurs paquets, mais la plupart du temps un datagramme correspond à un paquet, les deux termes sont quasiment synonymes. Notons cependant que cette possibilité de fragmenter les datagrammes est parfois utilisée par les pirates pour dissimuler leurs attaques.
Par « non fiable » nous entendons que la couche IP ne fournit aucune garantie de remise des datagrammes ni aucun contrôle d’erreur, et par « non connecté » nous entendons que la couche IP ne maintient aucune information d’état sur une
32 bits
longueur du paquet
Adresse IP de l’origine du paquet Adresse IP de la destination du paquet
Options éventuelles
normalement un segment TCP ou UDP Données, de longueur variable ;
somme de contrôle vers.
32 bits
Adresse IP de la destination du paquet
normalement un segment TCP ou UDP Données, de longueur variable ;
Adresse IP de l’origine du paquet vers. prio.
(128 bits)
(128 bits) suivant (*)
(*) Le champ « en−tête suivant » permet d’identifier le protocole de couche supérieure pour les données.
Figure 6.5
En-tête de paquet IPv4
Figure 6.6
En-tête de paquet IPv6
transmission de données en cours, et notamment qu’elle ne garantit pas la remise des datagrammes dans l’ordre dans lequel ils ont été émis.
Ces caractéristiques sont de nature à inquiéter les néophytes, et semblent cu-rieuses, d’autant plus que la couche de liaison de données fournit à la couche réseau, pour chaque segment physique d’un chemin de données utilisé par un da-tagramme, un service fiable de flux de bits remis dans le bon ordre.
En fait, la couche IP ne fournit pas de contrôle d’erreur parce que de toute façon la couche TCP devra en effectuer, ainsi que la vérification du bon ordre de remise des datagrammes au terminus de la transmission, et que de tels contrôles au niveau de la couche 3 seraient redondants. Son ascétisme et sa désinvolture confèrent à la couche IP la simplicité, la légèreté et la souplesse qui font son efficacité.