Chapitre 3

L’architecture TCP/IP

3.1 GÉNÉRALITÉS
3.1.1 Origine

Cette architecture TCP/IP a été développée, dans le milieu des années 1970, par la DARPA
(Defense Advanced Research Project Agency – USA –) pour les besoins d’interconnexion des
systèmes informatiques de l’armée.
Il vient du nom de ses deux protocoles principaux (TCP, Transmission Control Protocol et IP,
Internet Protocol), et est un ensemble de protocoles permettant de résoudre les problèmes
d’interconnexion en milieu hétérogène. À cet effet, TCP/IP décrit un réseau logique (réseau IP) au-
dessus du ou des réseaux physiques réels auxquels sont effectivement connectés les ordinateurs.

Figure 3.1 Le réseau logique IP et sous-réseaux physiques réels.

Ce protocole standard utilisé par internet a remplacé en 1983 le protocole NCP(Network Control
Program) de l’ARPANET et aujourd’hui , il autorise les flux multimédia.

3.1.2 Principe architectural

L’architecture TCP/IP ne comprend que 2 couches :

• La couche transport : qui utilise le protocole TCP

• La couche interréseau : qui utilise le protocole IP

Figure 3.2 Le modèle OSI et l’architecture TCP/IP.

La couche transport sur laquelle s’appuie directement les applications fournit directement 2 types de
services :

• Un service en mode connecté (TCP) ;

• Un service de transport allégé (UDP User Datagram Protocol)

La couche réseau du modèle TCP/IP présente les mêmes fonctionnalités que la couche réseau du
modèle ISO en mode non connecté, c’est-à-dire en mode datagramme et les services rendus sont
comparables à ceux de la norme ISO IS8473 (couramment appelé CLNP/CLNS, Connectionless
Network Protocol/Connectionless Network Services).
3.1.3 Description générale de la pile et applications TCP/IP

A la base ce protocole ne s’appuyait que sur un réseau existant. Son utilisation massive a fait
apparaitre des réseaux tout IP et la nécessité de disposer d’un protocole de liaison (SLIP,PPP).

Ce protocole a été adapté aux protocoles « haut Débit » tels que Frame Relay et l’ATM.

Figure 3.3 Protocoles et applications de TCP/IP.

10.1.4 Les mécanismes de base de TCP/IP

Les concepteurs du modèle TCP/IP n’ont spécifié qu’une couche réseau en mode non connecté (mode
datagramme).
Ce mode de mise en relation optimise l’utilisation des ressources réseaux sans contrôler les erreurs et
les flux. Ces tâches sont reportées sur les réseaux physiques réels.
Pour les systèmes d’extrémité, c’est la couche TCP qui pallie donc aux insuffisances de la couche
interréseau (Internet) en assurant le contrôle d’erreur et de flux de bout en bout (mode connecté).

Figure 3.4 Réseau logique IP et modes de mise en relation.

L’encapsulation des données

L’encapsulation consiste à transporter les données d’une couche dans une unité de données de la
couche inférieure.

L’en-tête contient les informations nécessaires à l’entité homologue pour extraire et traiter les
données.

Dans le modèle TCP/IP, les données de l’application constituent des messages.

Ces messages sont transportés dans des segments pour être mis sur le réseau sous forme de
datagrammes.

Au niveau physique, on a la trame qui est l’unité de transport élémentaire.

L’unité de transport élémentaire est la trame qui constitue au niveau physique un train de bits.

Figure 3.5 L’encapsulation des données dans TCP/IP.

NB : Contrairement au modèle ISO, TCP/IP utilise des formats d’en-tête de taille fixe. Ces formats
d’en-tête relativement important pénalise le débit mais optimise le traitement ddes données dans les
systèmes relativement important .

Identification des protocoles

Dans un modèle OSI c’est le SAP (Service Access Point) qui organise le dialogue vertical.

Dans un modèle TCP/IP c’est un adressage qui organise le dialogue vertical. Ainsi, c’est :
 • Le port dans le segment TCP qui détermine l’instance locale de l’application ;
• L’identifiant de protocole dans le datagramme IP qui désigne le protcole de transport utiisé ;
• L’EtherType des trames « Ethernet » qui identifie le protocole du niveau réseau.

Figure 3.6 Identification des protocoles dans TCP/IP.

Taille du segment de données échangé

La MTU (Maximum Transfert Unit) ou taille d’un segment de données maximum varie d’un réseau à
un autre. Pour certains réseaux tel que Ethernet, cette taille est normalisée, MTU = 1 500 octets ;

Mais pour des réseaux WAN, cette taille est déterminée par l’opérateur en fonction des
caractéristiques de ses éléments actifs (buffers …).

Question : Vu que les datagrammes peuvent transiter sur plusieurs réseaux avant d’atteindre leur
destination, que se passerait-il si la taille du datagramme était supérieure à la MTU du réseau ?

Réponse : Il appartiendrait au commutateur d’accès de fractionner (segmenter) l’unité de données

pour la rendre compatible avec les capacités de transport du réseau (figure 10.7).

Figure 3.7 Principe de la segmentation sous IP.

Vu que dans un réseau la probabilité qu’un nœud soit responsable de l’envoi de tous les fragments
d’un même datagramme ne soit pas égale à 1, il appartiendrait donc à l’utilisateur finale de regrouper
ces fragments pour restituer le datagramme.

Le routage de chaque fragment étant indépendant du précédent et du suivant, aucun noeud n’a la
certitude de recevoir tous les fragments ; dans ces conditions, seul le destinataire a la capacité de
rassembler les différents fragments.
NB : En mode datagramme, lorsque le fragment d’un datagramme est perdu, il faudrait retransmettre
tout le segment TCP d’origine.

Si la connexion est locale, afin d’éviter la reprise complète d’un segment TCP, on définit une taille de
segment correspondant à taille maximale que peut supporter le réseau.

Cette taille est fixée à 576 octets dont 536 utiles pour l’interconnexion via les réseaux de transport.

Lors de l’établissement de la connexion de transport, une option de TCP permet l’annonce et non la
négociation, de la taille maximale de segment que le système d’extrémité peut admettre (MSS,
Maximum Segment Size). La figure 10.8 illustre la relation entre MSS et MTU pour la valeur par
défaut de 576 octets de MTU. La MTU de 576 octets garantit une charge utile minimale de 512 octets
aux données de l’application.

Figure 3.8 Relation entre MTU et MSS (Valeur implicite).

3.2 L’ADRESSAGE DU RÉSEAU LOGIQUE

3.2.1 Principe de l’adressage IP

Chaque machine (host), raccordée au réseau logique IP, est identifiée par un identifiant logique ou
adresse IP (@IP) indépendant de l’adressage physique utilisé dans le réseau réel (figure 10.9).
Le réseau logique IP masquant le réseau physique, pour assurer l’acheminement des données, il est
nécessaire de définir des mécanismes de mise en relation de l’adresse logique, seule connue des
applications, avec l’adresse physique correspondante (résolution d’adresses).

Figure 3.9 Nécessité d’une résolution d’adresses

Pour obtenir l’adresse physique du destinataire, la machine source diffuse un message du type
broadcast (diffusion à tous).

Vu que toutes les machines du même réseau reconnaitront cette adresse de broadcast alors elles
répondront en indiquant leur adresse physique.

L’émetteur mémorisera donc les correspondances pour une utilisation ultérieure (cache ARP)

Figure 3.10 Résolution d’adresses dans les réseaux à diffusion.

Donc pour assurer le rroutage dans le réseeau logique IP, le protocole IP doit pouvoir identifier :

• Le réseau logique IP concerné (Net_ID) ;

• La machine cible (Host_ID).

Figure 3.11 L’adressage dans le réseau logique IP.

10.2.2 Les techniques d’adressage dans le réseau IP

Les classes d’adressage

Figure 3.12 Les classes d’adresse IP.

Il existe deux méthodes d’écriture des masques de sous-réseaux, qui sont équivalentes :

• Réseau : 10.0.0.0, masque de sous-réseau 255.255.240.0 ;

• ou plus simplement 10.0.0.0/20, le préfixe 20 indique la longueur en bits du masque de sous-
réseau (longueur du préfixe réseau ou simplement préfixe). Cette dernière écriture, plus
simple, est à préférer à la précédente.