Réseau Informatique Semestre 2, 3

Les VLAN
Table des matières
1. Introduction......................................................................................................................................2
2. VLAN de niveau 1............................................................................................................................4
3. VLAN de niveau 2............................................................................................................................5
4. VLAN de niveau 3............................................................................................................................6
5. VLAN par protocole.........................................................................................................................6
7. La norme IEEE 802.1Q....................................................................................................................6
[Link] d’application....................................................................................................................11
7.1. Énoncé.....................................................................................................................................12
7.2. Correction................................................................................................................................14

1. Introduction
Les réseaux virtuels (Virtual LAN) sont apparus comme une nouvelle fonctionnalité dans
l’administration réseau avec le développement des commutateurs.
La notion de VLAN est un concept qui permet de réaliser des réseaux de façon indépendante
du système de câblage. Ces réseaux permettent de définir des domaines de diffusions
restreints, cela signifie qu’un message émis par une station du VLAN ne pourra être reçu
que par les stations de ce même VLAN.
Un VLAN (Virtual Local Area Network) est un réseau local regroupant un ensemble de machines
de façon logique et non physique. Dans un réseau local la communication entre les
différentes machines est régie par l'architecture physique. Grâce aux réseaux virtuels, il est
possible de s'affranchir des limitations de l'architecture physique (contraintes
géographiques, contraintes d'adressage, ...) en définissant une segmentation logique (logicielle)
basée sur un regroupement de machines grâce à des critères (adresses MAC, numéros de port,
protocole, etc.).

[Link] 1
 Réseau Informatique Semestre 2, 3

2. Comparaison subdivision réseau « subnetting » et VLAN

Il est intéressant de découper (segmentation logique) une classe d’adresse IP en sous-réseaux afin
de compenser les problèmes de distribution de l’espace d’adressage IP, cloisonner les
domaines de diffusion et limiter ainsi la propagation de code malveillant à l’aide de la
technique appelée « subnetting ».
Un domaine de collision désigne une partie du réseau dans laquelle toutes les trames sont vues
par tous les équipements. Il comprend les bus et les « hubs » ou concentrateurs et est limité par
les « switchs » ou commutateurs et les routeurs.
Un domaine de diffusion désigne la partie du réseau dans laquelle les trames de « broadcast »
sont vues par tous les équipements.
Il est constitué des bus, des « hubs » et des « switchs », il est limité par les routeurs.
Les domaines de collisions appartiennent au même domaine de diffusion.
L’utilisation d’un routeur permet de segmenter les domaines de collision et de diffusion.
Cependant, ce mode d’interconnexion n’est pas sans inconvénients. Les sous-réseaux sont
définis physiquement par les « hubs », si bien que les utilisateurs sont groupés
géographiquement : l’organisation logique du sous-réseau est donc définie par sa géographie.
Par ailleurs, la mobilité d’une machine d’un sous-réseau à l’autre implique un changement
d’adresse si bien que le plan d’adressage est difficile à gérer.

Remarques : Les hubs (ou concentrateur) sont devenus aujourd’hui obsolètes et ont laissé place au
switch (ou commutateur) permettant ainsi de réduire la taille des domaines de collision. Les machines
actives utilisant une liaison partagée (avec hub par exemple) se répartissent le débit binaire.

[Link] 2
 Réseau Informatique Semestre 2, 3
Les réseaux locaux virtuels résolvent plusieurs problèmes communs sur les réseaux locaux :
• beaucoup d’utilisateurs sont aujourd’hui mobiles et la situation géographique d’un utilisateur
n’a pas forcément de lien avec son appartenance logique : deux collaborateurs situés aux
deux extrémités de l’entreprise peuvent souhaiter appartenir au même domaine de diffusion,
donc au même LAN qui devient ainsi virtuel car il n’a plus de réalité géographique. Il n’est
plus nécessaire de reconfigurer sa machine pour changer de VLAN ;
• les trafics de diffusion sont généralement importants. Les protocoles ARP et DHCP y ont
recours et beaucoup de serveurs en génèrent pour décrire leurs services. Or la plupart des
trames de « broadcast » n’intéresse qu’un nombre restreint de machine. Sur les réseaux en
mode diffusion (bus ou étoile avec hub), ce type de trafic gaspille le débit binaire, augmente
la latence et consomme inutilement de la puissance de calcul ;
• enfin, à l’intérieur d’un domaine de diffusion, le trafic peut être visualisé par toute station
dont la carte réseau supporte le « promiscuous mode » ou encore en utilisant un « sniffer »
tel que « WireShark » par exemple. Des problèmes de confidentialités peuvent donc exister.
Un VLAN redéfinit les domaines de diffusion de façon à regrouper les utilisateurs de
manière logique ou à économiser le débit binaire, améliorer la confidentialité des données et
faciliter la gestion de la mobilité. Il est implémenté sur un « switch » et réalise un domaine «
logique » de diffusion.
Dans l’exemple ci-dessous, les machines « PC1 à PC4 » sont connectées au même switch sur
lequel sont définis deux VLANs : VLAN1 contenant PC1 et PC3, et VLAN2 contenant PC2 et
PC4.
Lorsque PC1 émet une trame de diffusion, requête ARP par exemple, celle-ci est transmise
uniquement vers les machines du VLAN1, donc ici à PC3.
Les machines PC2 et PC4 ignorent le trafic du VLAN1.

Les VLANs peuvent être construits à l’image de l’organisation de l’entreprise.

Dans l’exemple, on peut imaginer que le VLAN1 est attribué au service Production et le VLAN2
au service Administration. Les trafics des deux services de la société sont isolés, même si leurs
machines sont reliées à un même switch.

[Link] 3
 Réseau Informatique Semestre 2, 3
2. VLAN de niveau 1
Dans un VLAN de niveau 1, aussi appelé VLAN par port, l’appartenance d’une machine à
un VLAN est définie par le port auquel elle est connectée. Le switch est équipé
d’une table « port/VLAN » remplie par l’administrateur qui précise le VLAN affecté à
chaque port. Dans cette situation toutes les machines reliées à un même port (cas de l’Ethernet
partagé) doivent appartenir au même VLAN.
C’est une contrainte qu’il faut gérer lorsque le réseau s’agrandit.

Table
Port VLAN
1 1
2 2
3 1
4 2
5 1;2

Si l’on souhaite faire appartenir un port à plusieurs VLAN, il est alors nécessaire de procéder
à du marquage de trames. Les machines doivent être « VLAN-aware » et être capable de
rajouter dans l’en-tête Ethernet de la trame un marqueur (tag) identifiant le VLAN auquel elle
appartient.
Dans l’exemple le serveur appartient aux deux VLANs. Il rajoute à ses trames un marqueur
indiquant à quel VLAN elle est destinée. Les autres machines n’ont pas besoin de gérer le tag.
Lorsque le switch reçoit une trame marquée du serveur, il trouve les ports de sortie et y réémet la
trame à laquelle il a enlevé le marqueur.
Si le serveur souhaite diffuser une même information aux deux VLANs, il doit générer deux
trames : l’une portant le marqueur du VLAN1, l’autre portant le marqueur du VLAN2.
Le VLAN de niveau 1 est simple à mettre en place mais présente quelques inconvénients :
• l’extension est difficile ;
• si une machine doit changer de VLAN (déplacement logique), il faut réaffecter manuellement
le port ;
• si une machine est physiquement déplacée sur le réseau, il faut désaffecter son ancien port et
réaffecter son nouveau port, ce qui nécessite deux manipulations de la part de l’administrateur.

[Link] 4
 Réseau Informatique Semestre 2, 3

3. VLAN de niveau 2
Les VLAN de niveau 2 sont aussi nommés VLAN par adresse MAC. Dans cette méthode,
l’adresse MAC d’une machine est affectée à un VLAN. En pratique, c’est encore le port qui est
affecté à un VLAN, mais de manière dynamique. En effet, l’administrateur saisit dans la table du
switch le couple adresse MAC/VLAN. Lorsque le switch découvre sur quel port est connecté la
machine, il affecte dynamiquement le port au VLAN. Il gère donc une deuxième table, la table
port/VLAN. Cette structure permet également de définir plusieurs VLAN par port à condition
d’utiliser le marquage.

Table créée dynamiquement Table construite par l’administrateur

Port VLAN VLAN1 VLAN2
1 1 @ MAC PC1 @ MAC PC2
2 2 @ MAC PC3 @ MAC PC4
3 1
4 2
5 1;2
Ce procédé présente plusieurs avantages. Lorsqu’une machine change de VLAN, il suffit de
modifier l’entrée correspondante de la table d’adresse/VLAN ; la table port/VLAN sera mise à jour
dynamiquement. En outre, ce fonctionnement est bien adapté aux équipements mobiles, puisque la
reconfiguration du port se fera sans intervention manuelle de l’administrateur en cas de
déplacement physique.
Cependant plusieurs inconvénients demeurent :
• le switch doit procéder à une analyse de l’adresse MAC, ce qui rend le VLAN de niveau 2
plus lent que le VLAN par port ;
• l’administrateur doit procéder à la saisie des adresses MAC : la procédure est longue et les
erreurs sont probables ;
• enfin, les switchs sur le réseau doivent procéder à l’échange de leurs tables adresse/VLAN,
ce qui peut provoquer une surcharge sur le réseau.

[Link] 5
 Réseau Informatique Semestre 2, 3

4. VLAN de niveau 3
Dans les VLAN de niveau 3, aussi nommé VLAN de sous-réseau, l’adresse IP est affectée a
un VLAN. Par exemple, le VLAN1 contient les machines d’adresse 10.1.x.x, le VLAN2
celles d’adresses 10.2.x.x. Comme dans le VLAN de niveau 2, l’administrateur remplit une table
d’adresse/VLAN. Lorsque le switch identifie le port auquel appartient la machine, il l’affecte a
son VLAN. Le VLAN de niveau 3 est plus lent que le VLAN de niveau 2 car le switch
doit accéder aux informations de la couche réseau.

Table créée dynamiquement Table construite par l’administrateur

Port VLAN VLAN1 VLAN2
1 1 @ IP 10.1.x.x @ IP 10.2.x.x
2 2
3 1
4 2
5. VLAN par protocole
Une dernière catégorie de VLAN est constituée des VLANs par protocole dans lesquels
l’appartenance au VLAN dépend du protocole utilisé par la machine. Les protocoles considérés
sont des protocoles de niveau 3 ou supérieur un VLAN VoIP pour le protocole H.323 par exemple,
ou encore par SSID dans le cas du WiFi.
Évidemment, les performances de ces VLANs sont dégradés en raison de l’analyse des niveaux 3
ou supérieurs qu’ils nécessitent.

6. Marquage ou Étiquetage du réseau VLAN

6.1 Qu’est-ce qu’un marquage ou une étiquette ?
Après avoir abordé la manière dont les VLANs facilitent la mise en œuvre de politiques de contrôle
d’accès et de filtrage du trafic, il est important de comprendre le mécanisme qui rend tout cela
possible : l’étiquetage des trames. Ce processus est au cœur de la gestion des VLANs et permet une
mise en œuvre efficace des politiques de sécurité et de contrôle d’accès.
L’étiquetage des trames avec des identifiants de VLAN, ou étiquettes VLAN, est une partie
importante du fonctionnement des VLANs en mode accès. Lorsqu’une trame de données arrive
sur un port du switch, celui-ci ajoute une «étiquette» spéciale à la trame pour indiquer à quel
VLAN elle appartient.

[Link] 6
 Réseau Informatique Semestre 2, 3
Cette étiquette contient des informations spécifiques au VLAN, notamment un identifiant de VLAN
(ou VID pour VLAN ID), qui est un numéro unique attribué au VLAN. Cette pratique d’ajouter des
informations supplémentaires à la trame est appelée «étiquetage» ou “tagging” en anglais.
Le processus d’étiquetage est totalement transparent pour les dispositifs finaux comme les
ordinateurs ou les serveurs. Le switch se charge d’ajouter l’étiquette VLAN lorsque la trame entre
dans le réseau et de la retirer lorsque la trame sort du réseau, de sorte que les dispositifs connectés
au VLAN n’ont pas besoin de gérer ces étiquettes eux-mêmes. Une fois qu’une trame est étiquetée,
le switch utilise cette information pour prendre des décisions sur la manière de manipuler la trame à
travers le réseau.

Par exemple, si une trame arrive sur un port configuré pour le VLAN 10, l’étiquette indiquera que
cette trame appartient au VLAN 10. Le switch saura alors que cette trame ne peut être envoyée qu’à
d’autres ports qui sont également configurés pour le VLAN 10.

6.2 Ports d’accès

Les ports d’accès sont ceux par lesquels une trame entre et ressort d’un réseau VLAN. Lorsqu’un
port d’accès reçoit une trame, celle-ci ne comporte pas d’étiquette VLAN. C’est au moment où la
trame rentre dans le port d’accès que l’étiquette VLAN est fixée à la trame. Pendant que la trame
transite par le commutateur, elle transporte l’étiquette VLAN qui lui a été attribuée au moment
d’entrer dans le port d’accès. L’étiquette VLAN est supprimée lorsque la trame quitte le
commutateur via le port d’accès de destination. Les périphériques d’émission et de réception
ignorent qu’une étiquette VLAN a jamais été utilisée. Ports d’accès :

6.3 Ports de liaison

Dans les réseaux comportant plusieurs commutateurs, il est indispensable de pouvoir
envoyer des trames avec étiquette VLAN d’un commutateur à un autre. La différence entre les
ports d’accès et de liaison est que les ports de liaison ne retirent pas l’étiquette VLAN
de la trame lorsqu’ils l’envoient. La présence de l’étiquette VLAN permet au
commutateur de réception de connaître l’appartenance de la trame en transit. La trame
peut ainsi être renvoyée aux ports appropriés du commutateur de réception.

Chaque trame avec une étiquette VLAN comporte des champs indiquant son appartenance à un
réseau VLAN. Il existe deux grands formats de marquage ou d’étiquettes VLAN :
· le format de liaison inter-commutateur ISL de Cisco
· le format standard 802.1Q.

[Link] 7
 Réseau Informatique Semestre 2, 3

7. La norme IEEE 802.1Q

La norme IEEE 802.1Q est utilisée pour étendre la portée des VLANs sur plusieurs switchs. Elle
est basée sur le marquage explicite des trames : dans l’en-têtte de niveau 2 de la trame est ajoutée un
« tag » qui identifie le VLAN auquel elle est destinée, on parle alors de VLANs « taggés ». Le
format de la trame est donc modifiée, ce qui peut entraîner des problèmes de compatibilité avec les
switchs ne supportant pas les VLANs et des soucis de taille maximale de trame sur le réseau. Il faut
noter que seuls les switchs ajoutent et enlèvent les « tags » dans les trames. Les machines n’ont
donc pas à gérer le marquage qui leur est inconnu.
Trois types de trames sont définis :
1. les trames non étiquetées (untagged frame) ne contiennent aucune information sur leur
appartenance à un VLAN ;
2. les trames étiquetées (tagged frame) possèdent un marqueur qui précise à quel VLAN elles
appartiennent ;
3. les trames étiquetées avec priorité (priority-tagged frame) sont des trames qui possèdent en
plus un niveau de priorité défini selon la norme IEEE 802.1P.
Format de la trame IEEE 802.1Q :

16 bits 3 bits 1 bit 12 bits

Tag Protocol Identifier Priority Code Point Canonical Format VLAN Identifier
(TPID) (PCP) Indicator (CFI) (VID)
Tag Control Information (TCI)
• le champ TPID Tag protocol identifier : ce champ de 16 bits identifie le protocole véhiculé dans la
trame. La valeur 0x8100 désigne une balise IEEE 802.1Q / 802.1P.
• le champ TCI est constitué de trois parties :
1. le champ Priority indique le niveau de priorité de la trame et est utilisé lorsque que le champ VID
est nul ; les 3 bits fait référence au standard IEEE 802.1P. Sur 3 bits on peut coder 8 niveaux de
priorités de 0 à 7. La notion de priorité dans les VLANs est sans rapport avec les mécanismes de
priorité IP au niveau réseau. Ces 8 niveaux sont utilisés pour fixer une priorité aux trames d'un
VLAN relativement aux autres VLANs.
2. le champ CFI Canonical Format Identifier : ce champ codé sur 1 bit assure la compatibilité entre
les adresses MAC Ethernet et Token Ring. Un commutateur Ethernet fixera toujours cette valeur à
0. Si un port Ethernet reçoit une valeur 1 pour ce champ, alors la trame ne sera pas propagée
puisqu'elle est destinée à un port «sans balise» (untagged port).

[Link] 8
 Réseau Informatique Semestre 2, 3
3. le champ VLAN Identifier, vlan id, VID : ce champ de 12 bits sert à identifier le réseau local
virtuel auquel appartient la trame. Il est possible de coder 4096 réseaux virtuels avec ce champ.
Les VLANs peuvent être déclarés manuellement ou dynamiquement. Dans la déclaration
dynamique, l’administrateur définit les VLANs sur un switch et un seul. Le protocole : Mutiple
VLAN Registration Protocol (MVRP) permet la diffusion de ces informations aux autres switchs
du réseau.
Le mode d’accès
Le fonctionnement des VLANs au niveau d’un switch apporte un niveau
supplémentaire de granularité et de contrôle. Concrètement, chaque port d’un switch peut
être assigné à un VLAN spécifique, identifié par un numéro unique. Ce numéro de VLAN
sert à étiqueter le trafic entrant et sortant du port, créant ainsi une segmentation logique à
l’intérieur même du switch.
Dans ce scénario, un ordinateur ou un autre dispositif connecté à un port spécifique du
switch ne peut communiquer qu’avec les dispositifs qui sont dans le même VLAN, c’est-à-
dire ceux qui sont connectés à des ports assignés au même numéro de VLAN. Les trames
de données qui traversent le switch sont donc étiquetées en fonction du VLAN auquel
appartient le port d’origine. Le switch utilise ensuite cette étiquette pour déterminer si
la trame peut être transmise à son port de destination. Si le port de destination
appartient au même VLAN que le port d’origine, la trame est transmise; sinon, elle est
bloquée.

Ce mécanisme de segmentation au niveau du switch permet une isolation efficace des groupes de
travail ou des départements au sein d’une organisation. Par exemple, si le département financier est
sur le VLAN 10 et le département marketing sur le VLAN 20, un ordinateur du département
financier ne pourra pas communiquer directement avec un ordinateur du département marketing,
sauf si des règles spécifiques de routage ou de commutation ont été mises en place pour autoriser ce
type de communication.
Cette manière de gérer les VLANs au niveau des ports du switch est communément appelée le «
vlan mode accès ». Dans ce mode, chaque port est strictement associé à un seul VLAN, et tout
dispositif connecté à ce port hérite automatiquement de cette association. Le mode accès est
pleinement compatible avec la technologie Ethernet, ce qui en fait une solution extrêmement
versatile et largement adoptée dans les réseaux modernes.
Dans une configuration Ethernet standard, il n'est pas nécessaire de faire des modifications
spécifiques sur les dispositifs finaux (tels que les ordinateurs ou les serveurs) pour qu'ils puissent
fonctionner dans un environnement VLAN. Le switch, en mode accès, prend en charge la gestion
des étiquettes VLAN, assurant que les trames sont correctement étiquetées et filtrées en fonction
des numéros de VLAN attribués aux ports. Ainsi, la complexité de la gestion des VLANs est
largement absorbée par le switch, rendant le processus transparent pour les utilisateurs finaux et
simplifiant la configuration et la maintenance du réseau.

[Link] 9
 Réseau Informatique Semestre 2, 3
En intégrant le mode accès dans un environnement Ethernet, les administrateurs réseau peuvent
donc tirer pleinement parti des avantages des VLANs sans avoir à faire face à des
complications supplémentaires liées à la compatibilité ou à la configuration des dispositifs. Cela
rend la technologie VLAN en mode accès, non seulement puissante en termes de
fonctionnalités, mais aussi pratique et accessible.

Le mode trunk
Dans le contexte des VLANs, le “mode trunk” constitue une alternative au mode accès, mais avec
une fonctionnalité différente. Contrairement au mode accès, où chaque port est dédié à un seul
VLAN, le mode trunk permet à un seul port physique de switch de gérer du trafic appartenant à
plusieurs VLANs simultanément. Cette capacité est particulièrement utile pour connecter
ensemble différents switches, ou encore pour relier un switch à un routeur capable de gérer
plusieurs VLANs.
Cependant, le mode trunk n’est pas directement compatible avec le protocole Ethernet standard,
car il nécessite que l’étiquette VLAN soit explicitement incluse dans chaque trame transmise.
C’est là qu’intervient le protocole 802.1Q, également connu sous le nom de “dot1q”. Ce
protocole insère une étiquette spécifique dans la trame Ethernet pour indiquer à quel VLAN la
trame appartient. En fait, 802.1Q ajoute quatre octets à la trame Ethernet standard, comprenant
entre autres le tag, pour permettre cette fonctionnalité.
La plupart des switches modernes et certains routeurs supportent le protocole 802.1Q, mais il
nécessite généralement une configuration manuelle. Lorsqu’un port est configuré en mode trunk, le
switch ajoute ou lit l’étiquette 802.1Q à chaque trame qui passe par ce port. De cette manière, les
trames de plusieurs VLANs peuvent être acheminées par un seul port trunk sans se mélanger,
car l’étiquette indique clairement à quel VLAN chaque trame appartient.
Il est important de noter que la gestion des trames en mode trunk est plus complexe que celle en
mode accès. Par exemple, pour assurer que le trafic est correctement acheminé, les deux extrémités
d’un lien en mode trunk doivent être correctement configurées pour utiliser le protocole 802.1Q.
Cela implique souvent une coordination étroite entre les administrateurs réseau et une
connaissance approfondie des besoins spécifiques en termes de trafic et de sécurité.

[Link] 10
 Réseau Informatique Semestre 2, 3
Configuration des TRUNKs
Dans les réseaux d’entreprise, les VLANs sont devenus une solution incontournable pour améliorer la
gestion, la sécurité et les performances des infrastructures réseau. En segmentant les réseaux en sous-
réseaux virtuels, les VLANs permettent de regrouper des ressources et des utilisateurs partageant des
besoins similaires en matière de trafic réseau, indépendamment de leur emplacement physique.
Cependant, pour que les données de ces VLANs soient acheminées de manière optimale au sein du
réseau, il est nécessaire de mettre en place des liaisons spécifiques appelées « trunks » entre les switchs.
Les trunks permettent de transporter les données de plusieurs VLANs sur une même liaison physique
entre deux switchs. Contrairement aux ports configurés en mode accès, qui ne transportent que les
données d’un seul VLAN, les trunks permettent de transporter les données de plusieurs VLANs
simultanément, ce qui permet une utilisation efficace des ressources réseau. Il est important de noter
que les trunks sont généralement présents au niveau des couches de distribution ou du backbone,
c’est-à-dire là où les switchs sont interconnectés pour assurer le transport des données entre les
différents VLANs. Les trunks ne sont pas destinés aux utilisateurs finaux, car ces derniers sont
connectés à des ports d’accès configurés pour un VLAN spécifique.
Le fonctionnement des tags de VLAN

Lorsqu’un paquet arrive sur le port d’un switch configuré en mode access, le switch
détermine d’abord à quel VLAN appartient ce port. En mode access, chaque port est associé à un
seul VLAN et ne traite que les paquets de ce VLAN spécifique. Le switch vérifie ensuite
l’adresse MAC de destination du paquet et consulte sa table d’adresses MAC pour
déterminer le port de sortie approprié.
Une fois le port de sortie identifié, si ce port est configuré en mode trunk, le switch doit encapsuler
le paquet avec une étiquette VLAN, également appelée tag, avant de le transmettre. Ce
tag contient des informations sur le VLAN d’origine du paquet. Cette encapsulation se
fait généralement selon la norme IEEE 802.1Q (dit DOT1Q), qui ajoute un en-tête VLAN au
paquet Ethernet d’origine.
Le paquet encapsulé est ensuite transmis sur le port trunk vers le switch ou le dispositif
de destination. Lorsque le paquet atteint le switch de destination, ce dernier examine l’étiquette
VLAN et détermine à quel VLAN appartient le paquet. Le switch de destination retire alors
l’étiquette VLAN et transmet le paquet Ethernet d’origine au port de destination approprié, qui
est configuré pour le même VLAN que le port d’origine.

[Link] 11
 Réseau Informatique Semestre 2, 3
En gros, retenez que les PC ne peuvent communiquer qu’en Ethernet, alors que les switch
communiquent entre eux en dot1q.
Les préparatifs
Avant de configurer les trunk entre les switchs, votre base de données VLAN doit être préremplie
par tous les VLAN qui devront être acheminés par les ports concernés. C’est pour
cette raison que nous avions vu qu’il était vivement recommandé que tous les switchs
d’un LAN possèdent exactement la même base de données.
La reconfiguration d’un port en Trunk
Afin de configurer le mode trunk sur le port d’un commutateur, il faut paramétrer les
interfaces réseau pour permettre la transmission de données entre plusieurs VLAN. Pour garantir
un échange de données sans erreurs, il est impératif de configurer le mode trunk sur les deux
ports situés de part et d’autre du câble. Autrement dit, chaque interface réseau qui
communique avec un switch doit être reconfigurée en mode trunk. Si l’un des deux switch est
malconfiguré, dans le meilleur des cas votre trame sera retaguée comme vlan natif. C’est à dire que
la trame retombe donc dans le vlan 1. Dans le pire des cas, c’est le protocole spanning
tree, censé créer un arbre par VLAN, dysfonctionnera, causant une défaillance réseau
totale pour tous les utilisateurs. De ce fait n’oubliez surtout pas de configurer les deux
interfaces réseaux.
Pour configurer une interface réseau en mode trunk :
Switch(config)#interface [type_dinterface] [numero_de_linterface]
Switch(config-if)# switchport mode trunk
7. Exercices d’application
7.1. Énoncé
Soit le LAN comportant des VLANs de niveau 1 ci-dessous :

[Link] 12
 Réseau Informatique Semestre 2, 3

On suppose dans un premier temps que les VLANs sont non taggés. L’administrateur souhaite faire
appartenir les machines aux VLANs comme ci-dessous :
• machines A,C, E, G : VLAN1 (sur le port 7 des switchs)
• machines B, D, F, H : VLAN2 (sur le port 8 des switchs)
Il complète en conséquence les tables port/VLAN des deux switchs.
On considère que les switchs et les machines viennent d’être mis sous tension. Ainsi les tables
MAC/port sont vides.
Question 1 : Pourquoi a-t-on mis en place deux liens entre les switchs ?
Question 2 : La machine A émet une trame à destination de la machine C. On rappelle que les
tables MAC/port sont vides. Quelles sont les machines qui reçoivent la trame ?
Expliquer.
Question 3 : On considère maintenant que les tables MAC/port sont remplies. La machine A émet
de nouveau une trame vers la machine C. Quelle(s) machine(s) reçoi(en)t la trame ?
Question 4 : La machine A émet une trame en « broadcast ». Quelles sont les machines qui
reçoivent la trame ?
Question 5 : La machine A émet une trame pour la machine H. Expliquer comment est traité la
trame ?
Question 6 : Quelle modification doit-on réaliser pour permettre le trafic entre deux machines
appartenant au même VLAN mais connectées à des switchs différents reliés par un
seul lien (7/SW1-8/SW2) ?
Question 7 : Soit le LAN ci-dessous sur lequel on souhaite implémenter deux VLANs de niveau 2.
• machines A,C : VLAN1
• machines B, D : VLAN2
Quelle table l’administrateur doit-il compléter ?

Question 8 : Quelle table est construite dynamiquement et à quel moment ?

[Link] 13
 Réseau Informatique Semestre 2, 3
7.2. Correction
Question 1 :
Comme il n’y a pas de marquage, il faut donc un lien pour le trafic issu du VLAN1, et un lien pour
le trafic issu du VLAN2.
Les machines d’un même VLAN mais placées sur des switchs différents peuvent ainsi
communiquer.
Question 2 :
SW1 consulte sa table port/VLAN et apprend que la trame provient du VLAN1. SW1 ne sait pas sur
quel port se trouve la machine C car sa table MAC/port est vide. Donc SW1 émet la trame sur les
ports de VLAN1, c’est-à-dire les ports 3 et 7.
SW2 consulte sa table port/VLAN et apprend que la trame provient du VLAN1. SW2 ne sait pas sur
quel port se trouve la machine C car sa table MAC/port est vide. Donc SW2 émet la trame sur les
ports de VLAN1, c’est-à-dire les ports 1 et 3.
Les machines qui reçoivent la trame sont : C, E, G.
Question 3 :
Seule la machine C reçoit la trame.
Question 4 :
Toutes les machines du VLAN1 reçoivent la trame : A, C, E, G.
Question 5 :
SW1 consulte sa table port/VLAN et constate que le port 1 appartient au VLAN1. Il consulte sa
table MAC/port et constate que la machine H est accessible par le port 7.
SW1 consulte sa table port/VLAN est constate que le port 7 appartient au VLAN2, donc il détruit la
trame.
Question 6 :
Il faut rajouter du marquage explicite : le port 7/SW1 et le port 8/SW2 doivent suivre la norme
802.1Q.
Exemple pour une trame de A vers E :
SW1 consulte sa table port/VLAN et constate que E est sur le port 7.
SW1 marque la trame est l’émet sur le port 7.
La trame arrive sur le port 8 de SW2.
SW2 lit la marque et apprend que la trame appartient au VLAN1.
SW2 consulte sa table MAC/port et apprend que E est sur le port 1.
SW2 consulte sa table port/VLAN et constate que le port 1 appartient au VLAN1.
SW2 émet la trame sur le port 1.
Question 7 :
L’administrateur doit compléter manuellement la table port/VLAN.
Question 8 :
La table MAC/VLAN sera construite dynamiquement par le switch dès qu’il aura pris connaissance
des affectations adresses MAC aux ports.

[Link] 14
 Réseau Informatique 3ème Semestre

Encapsulation de données
Table des matières
1. Principe.............................................................................................................................................2
2. Couche liaison de données...............................................................................................................4
2.1. En-tête Ethernet........................................................................................................................4
2.2. Trame Ethernet..........................................................................................................................4
3. Couche réseau...................................................................................................................................5
3.1. En-tête IP..................................................................................................................................5
3.2. Paquet IP...................................................................................................................................5
3.3. En-tête ARP IPv4......................................................................................................................7
3.4. Paquet ICMP.............................................................................................................................8
4. Couche transport...............................................................................................................................9
4.1. En-tête TCP...............................................................................................................................9
4.2. Segment TCP..........................................................................................................................10
4.3. En-tête UDP............................................................................................................................11
4.4. Segment UDP..........................................................................................................................11
5. Exercices.........................................................................................................................................12

L'encapsulation, en informatique et spécifiquement pour les réseaux informatiques, est un procédé

consistant à inclure les données d'un protocole dans un autre protocole.
Lors d'une encapsulation, la couche la plus abstraite est appelée « couche protocole de plus haut
niveau » (Upper Layer Protocol - ULP) alors que la couche la plus spécifique est appelée « couche
protocole de plus bas niveau » (Lower Layer Protocol - LLP).

[Link] 1
 Réseau Informatique 3ème Semestre

1. Principe
Lors d’une transmission, les données traversent chacune des couches au niveau de la machine
émettrice. À chaque couche, une information est ajoutée au paquet de données, il s’agit d’un en-
tête, ensemble d’informations qui garanti la transmission. Au niveau de la machine réceptrice, lors
du passage dans chaque couche, l’en-tête est lu, puis supprimé. Ainsi à la réception, le message est
dans son état originel.
À chaque niveau, le paquet de données change d’aspect, car on lui ajoute un en-tête, ainsi les
appellations changent suivant les couches :
• le paquet de données est appelé message au niveau de la couche application
• le message est ensuite encapsulé sous forme de segment dans la couche transport
• le segment une fois encapsulé prend le nom de paquet dans la couche réseau
• enfin on parle de trame au niveau de la couche liaison
• et de signal au niveau de la couche physique

Par exemple, l'Internet est basé sur l'Internet Protocol version 4 et la plupart des applications
utilisent aussi bien l'UDP (User Datagram Protocol) que le TCP (Transmission Control Protocol).
Ainsi un fragment de donnée est encapsulé dans un datagramme UDP qui lui-même est encapsulé
dans un paquet IP, ce dernier étant alors envoyé via un protocole de la couche de liaison (par
exemple Ethernet).
La couche de liaison est responsable de la transmission physique des données ; IP ajoute l'adressage
des ordinateurs individuels ; UDP ajoute « l'adressage des applications » (c'est-à-dire le port
spécifiant le service comme, par exemple, un service web ou un serveur TFTP).
Le modèle OSI et la suite des protocoles Internet utilisent l'encapsulation.

[Link] 2
 Réseau Informatique 3ème Semestre
Chaque couche du modèle OSI a une fonction déterminée. Cette corrélation indique bien que
certaines informations peuvent se retrouver d'une couche à une autre. Cela n’est possible que
grâce au principe d’encapsulation.
Les données sont enveloppées à chaque couche et portent le nom de PDU (Protocol Data Unit)
et contiennent deux choses : la donnée en elle-même et l’en-tête spécifique à cette couche. La
partie « donnée » de ce paquet est composée de la donnée initiale, mais aussi des en-têtes des
couches qui la précèdent.
Dans une couche N, le PDU est le SDU (Service Data Unit) de la couche N + 1 plus son en-tête
(couche N). Ce SDU ne devient un PDU qu'après l’encapsulation. La couche N ajoute des
informations dans l’en-tête (header) ou le pied (trailer), voire les deux, du SDU afin de le
transformer en un PDU. Ce PDU sera alors le SDU de la couche N - 1. Donc le PDU est un SDU
encapsulé avec un en-tête.
Constitution d'un PDU :

Dans la procédure de réception, chaque en-tête est enlevé lorsque le message « remonte » les
couches, tel qu’illustré par le schéma ci-dessous. Cette « suppression » d’en-tête, c’est la
décapsulation.

Port source du client Port destination du serveur

Web : HTTP Web :
49200 80
Source Destination
[Link] [Link]
[Link] [Link]

[Link] 3
 Réseau Informatique 3ème Semestre

2. Couche liaison de données

2.1. En-tête Ethernet

Le champ Ether Type peut prendre par exemple les valeurs suivantes :

Type utilisation
0x0800 IPv4, DoD Internet
0x0801 X.75 Internet
0x0802 NBS Internet
0x0803 ECMA Internet
0x0804 ChaosNet
0x0805 X.25 niveau 3
0x0806 ARP
0x0807 XNS
0x86DD IPv6
0x0806 ARP
0x8035 RARP
0x809B AppleTalk
0x88CD SERCOS III
0x0600 XNS
0x8100 VLAN
2.2. Trame Ethernet

Remarques :
• comme expliqué ci-dessus, si le champ type de protocole possède une valeur
hexadécimale inférieure à 0x05DC alors la trame est une trame Ethernet 802.3 et ce
champ indique la longueur du champ données ;
• on notera la présence parfois d'un préambule de 64 bits de synchronisation, alternance de
1 et 0 avec les deux derniers bits à 1 (non représenté sur la trame) ;

[Link] 4
 Réseau Informatique 3ème Semestre

• l'adresse de broadcast (diffusion) Ethernet a tous ses bits à 1 ;

• la taille minimale des données est de 46 octets (RFC 894 - Frame Format).
• si nécessaire, pour atteindre les 46 octets de données, un bourrage est effectué, et celui-ci
est transparent au niveau utilisateur3.

3. Couche réseau

3 - 1 Définition du protocole IP
IP signifie "Internet Protocol", protocole Internet. Il représente le protocole réseau le plus répandu.
Il permet de découper l'information à transmettre en paquets, de les adresser, de les transporter
indépendamment les uns des autres et de recomposer le message initial à l'arrivée. Ce protocole
utilise ainsi une technique dite de commutation de paquets. Il apporte, en comparaison à Ipx/Spx
et Netbeui, l'adressage en couche 3 qui permet, par exemple, la fonction principale de routage.

Il est souvent associé à un protocole de contrôle de la transmission des données appelé TCP, on
parle ainsi du protocole TCP/IP. Cependant, TCP/IP est un ensemble de protocole dont voici les
plus connu.
- IP - Internet Protocol - Couche 3 - IP natif.
- ARP - Address Resolution Protocol - Couche 3 - Résolution d'adresse IP en adresse MAC.
- RARP - Reverse Address Resolution Protocol - Couche 3 - Résolution d'adresse MAC en adresse
IP.
- ICMP - Internet Control Message Protocol - Couche 3 - Gestion des messages du protocole IP.
- IGMP - Internet Group Management Protocol - Couche 3 - Protocole de gestion de groupe.
- TCP - Transmission Control Protocol - Couche 4 - Transport en mode connecté.
- UDP - User Datagram Protocol - Couche 4 - Transport en mode non connecté.
Vous trouverez tous les détails du protocole IP dans la Rfc 791.
3 - 2 Structure de l'entête IP
Voici la structure de l'entête IP basé sur 20 octets.

Voici le complément de l'entête IP qui est optionnel basé sur 4 octets.

[Link] 5
 Réseau Informatique 3ème Semestre

3.3. Paquet IP

20 octets
4 - Définition des différents champs
4.1 - Le champ Vers
Le champ version est codé sur 4 bits. Il représente le numéro de version du protocole IP. Il
permet aux piles IP réceptionnant la trame de vérifier le format et d'interpréter correctement la
suite du paquet. C'est d'ailleurs pour cette raison qu'il est placé au début, une version inconnue
par un équipement conduit au rejet direct.
Voici la liste des différent codes.
- 00 - Réservé
- 01 - Non assigné
- 02 - Non assigné
- 03 - Non assigné
- 04 - IP V4
- 05 - ST Datagram Mode
- 06 - IP V6
- 07 - Non assigné
- 08 - Non assigné
- 09 - Non assigné
- 10 - Non assigné
- 11 - Non assigné
- 12 - Non assigné
- 13 - Non assigné
- 14 - Non assigné
- 15 - Réservé

[Link] 6
 Réseau Informatique 3ème Semestre

4.2 - IHL
IHL signifie "Internet header lengh". ce champ est codé sur 4 bits et représente la longueur en mots
de 32 bits de l'entête IP. Par défaut, il est égal à 5 (20 octets), cependant, avec les options de
l'entête IP, il peut être compris entre 6 et 15.
Le fait que le codage soit sur 4 bits, la taille maximum de l'entête IP est donc de 15*32bits = 60
octets
4.3 - Service
Le champs service "Type Of Service" est codé sur 8 bits, il permet la gestion d'une qualité de
service traitée directement en couche 3 du modèle OSI. Cependant, la plupart des équipements de
Backbone, ne tiennent pas compte de ce champ et même certain le réinitialise à 0.
Voici la composition du champ Service :

Vous trouverez tous les détails du champ Service TOS "Type Of Service" dans la Rfc 1349.
4.3.1 - Priorité
Le champ Priorité "Precedence" est codé sur 3 bits. Il indique la priorité que possède la paquet.
Voici les correspondances des différentes combinaisons :
- 0 - 000 - Routine
- 1 - 001 - Prioritaire 0x00 Service normal Transfert banal
- 2 - 010 - Immédiat 0x02 Minimiser le coût “ news ” (nntp)
- 3 - 011 - Urgent 0x04 Maximiser la qualité ICMP Session
- 4 - 100 - Très urgent 0x10 Minimiser le délai telnet
- 5 - 101 - Critique Maximiser le débit Transfert ftp
0x08
- 6 - 110 - Supervision interconnexion
- 7 - 111 - Supervision réseau
4.3.2 - Délai
Le champ Délai "Delay" est codé sur 1 bit. Il indique l'importance du délai d'acheminement du
paquet. Voici les correspondances des différentes combinaisons :
- 0 - Normal
- 1 - Bas
4.3.3 - Débit
Le champ Débit "Throughput" est codé sur 1 bit. Il indique l'importance du débit acheminé. Voici
les correspondances des différentes combinaisons :
- 0 - Normal
- 1 - Haut
[Link] 7
 Réseau Informatique 3ème Semestre

4.3.4 - Fiabilité
Le champ Fiabilité "Reliability" est codé sur 1 bit. Il indique l'importance de la qualité du paquet.
Voici les correspondances des différentes combinaisons :
- 0 - Normal
- 1 - Haute
4.3.5 - Coût
Le champ Coût "Cost" est codé sur 1 bit. Il indique le coût du paquet. Voici les correspondances des
différentes combinaisons :
- 0 - Normal
- 1 - Faible
4.3.6 - MBZ
Le champ MBZ "Must Be Zero" est codé sur 1 bit. Comme son nom l'indique, il doit être mis à 0.

4.4 - Longueur totale

Le champ Longueur totale est codé sur 16 bits et représente la longueur du paquet incluant l'entête
IP et les Data associées. La longueur totale est exprimée en octets, ceci permettant de spécifier une
taille maximum de 216 = 65535 octets. La longueur des Data est obtenu par la combinaison des
champs IHL et Longueur totale : Longueur_des_data = Longueur_totale - ( IHL * 4 );

4.5 - Identification
Le champ Identification est codé sur 16 bits et constitue l'identification utilisée pour reconstituer
les différents fragments. Chaque fragment possède le même numéro d'identification, les entêtes IP
des fragments sont identiques à l'exception des champs Longueur totale, Checksum et Position
fragment. Numéro permettant d'identifier les fragments d'un même paquet.

4.6 - Indicateurs ou Flags (3 bits) :

Le champ Flags est codé sur 3 bits et indique l'état de la fragmentation. Voici le détail des
différents bits constituant ce champ.
4.6.1 - Reserved
Le premier bit est réservé et positionné à 1, actuellement inutilisé.
4.6.2 - DF
Appelé DF "Don't Fragment", le second bit permet d'indiqué si la fragmentation est autorisée. Si un
Datagramme devant être fragmenté possède le flag DF à 1, alors, il sera alors détruit. Lorsque ce
bit est positionné à 1, il indique que le paquet ne peut pas être fragmenté. Si le routeur ne peut
acheminer ce paquet (taille du paquet supérieure à la MTU), il est alors rejeté.
4.6.3 - MF
Appelé MF "More Fragments", le troisième bit indique s'il est à 1 que le fragment n'est pas le
dernier. Quand ce bit est positionné à 1, on sait que ce paquet est un fragment de données
et que d'autres doivent suivre. Quand il est à 0, soit le fragment est le dernier, soit le
paquet n'a pas été fragmenté.

[Link] 8
 Réseau Informatique 3ème Semestre

4.7 - Position fragment

Le champ Position fragment est codé sur 13 bits et indique la position du fragment par rapport à la
première trame. Le premier fragment possède donc le champ Position fragment à 0. Position du
fragment par rapport au paquet de départ, en nombre de mots de 8 octets.
4.8 - TTL
Le champ TTL (Time To Live) est codé sur 8 bits et indique la durée de vie maximale du paquet.
Il représente la durée de vie en seconde du paquet. Si le TTL arrive à 0, alors l'équipement qui
possède le paquet, le détruira.
Attention, à chaque passage d'un routeur le paquet se verra décrémenté de une seconde. De plus, si
le paquet reste en file d'attente d'un routeur plus d'une seconde, alors la décrémentation sera plus
élevée. Elle sera égale au nombre de seconde passé dans cette même file d'attente. Par défaut, si
les temps de réponse sont corrects, alors on peut, entre guillemet, en conclure que le Time To Live
représente le nombre de saut maximum du niveau.
Le but du champ TTL est d'éviter de faire circuler des trames en boucle infinie.

4.9 - Protocole
Le champ Protocole est codé sur 8 bits et représente le type de Data qui se trouve derrière l'entête
IP. Numéro du protocole au-dessus de la couche réseau : TCP = 6, UDP = 17, ICMP = 1.
Ce champ permet d'identifier le protocole utilisé par le niveau supérieur :
• Internet Control Message Protocol ou ICMP est repéré par les bits 00000001, qu'on écrit
souvent en hexadécimal avec 01
• Transmission Control Protocol ou TCP par les bits 00000110, soit 06
• User Datagram Protocol ou UDP par les bits 00010001, soit 17 en décimal
Voici la liste des protocoles les plus connu :
- 01 - 00001 - ICMP
- 02 - 00010 - IGMP
- 06 - 00110 - TCP
- 17 - 10001 - UDP
Code Abréviation Nom du protocole
0 Reserved
1 ICMP Internet Control Message
2 IGMP Internet Group Management
3 GGP Gateway-to-Gateway
4 IP IP in IP (encasulation)
5 ST Stream
6 TCP Transmission Control
7 UCL UCL
8 EGP Exterior Gateway Protocol
9 IGP any private interior gateway
10 BBN-RCC-MON BBN RCC Monitoring
11 NVP-II Network Voice Protocol
12 PUP PUP
[Link] 9
 Réseau Informatique 3ème Semestre

13 ARGUS ARGUS
14 EMCON EMCON
15 XNET Cross Net Debugger
16 CHAOS Chaos
17 UDP User Datagram

4.10 - Checksum
Le champ Checksum est codé sur 16 bits et représente la validité du paquet de la couche 3. Pour
pouvoir calculer le Checksum, il faut positionner le champ du checksum a 0 et ne considérer que
l'entête IP. Donc par exemple, si deux trames ont la même entête IP (y compris le champ length)
et deux entêtes ICMP et Data différentes (mais de même longueur), le checksum IP sera alors le
même.
- Code de détection d’erreurs portant sur l'entête
- Vérification bout en bout :
la source calcule la valeur du checksum
le récepteur calcule le checksum sur l’entête reçu et vérifie si la valeur calculée
correspond à celle reçue
Tous les équipements de niveau 3, tel que les routeurs, devront recalculer le Checksum, car il
décrémente le champs TTL. De plus, toutes les fonctions de niveau 3 à 7, tel que la NAT, le PAT,
modifiant le contenu de l'entête IP ou des Data, devront recalculer le Checksum.

4.11 - Adresse IP source

Le champ IP source est codé sur 32 bits et représente l'adresse IP source ou de réponse. Il est codé
sur 4 octets qui forme l'adresse A.B.C.D.

Exemple : calcul du checksum

entête Ethernet entête IP entête TCP données
08 00 20 87 b0 44 08 00 11 08 c0 63 08 00 45 00
00 48 49 ba 00 00 1e 06 69 8d c1 37 33 f6 c1 37
33 04 17 70 96 d4 39 7f 84 c2 bf 3a 21 fd 50 18
11 1c 99 bc 00 00 0e 00 31 3f 02 c0 00 11 00 00
3e c1 00 00 00 11 00 00 00 02 28 28 a7 b0 80 29
ea fc 81 58 90 70

[Link] 10
 16 bits
0x4500 0100 0101 0000 0000
0x0048 0000 0000 0100 1000
0100 0101 0100 1000
0x49BA 0100 1001 1011 1010
1000 1111 0000 0010
0x0000 0000 0000 0000 0000
0x1E06 0001 1110 0000 0110
1010 1101 0000 1000
0x0000 0000 0000 0000 0000
0xC137 1100 0001 0011 0111
1 0110 1110 0011 1111
0x33F6 0011 0011 1111 0110
1 1010 0010 0011 0101
0xC137 1100 0001 0011 0111
10 0110 0011 0110 1100
0x3304 0011 0011 0000 0100
10 1001 0110 0111 0000
1001 0110 0111 0010
0x698D 0110 1001 1000 1101

Exemple : vérification du checksum

entête Ethernet entête IP entête TCP données
08 00 20 87 b0 44 08 00 11 08 c0 63 08 00 45 00
00 48 49 ba 00 00 1e 06 69 8d c1 37 33 f6 c1 37
33 04 17 70 96 d4 39 7f 84 c2 bf 3a 21 fd 50 18
11 1c 99 bc 00 00 0e 00 31 3f 02 c0 00 11 00 00
3e c1 00 00 00 11 00 00 00 02 28 28 a7 b0 80 29
ea fc 81 58 90 70
 16 bits
0x4500 0100 0101 0000 0000
0x0048 0000 0000 1000 0100
0100 0101 1000 0100
0x49BA 0100 1001 1010 1011
1000 1111 0010 0000
0x0000 0000 0000 0000 0000
0x1E06 0001 1110 0110 0000
1010 1101 1000 0000
0x698D 0110 1001 1101 1000
1 0001 0110 0101 1001
0xC137 1100 0001 0111 0011
1 1101 0111 1100 1100
0x33F6 0011 0011 0110 1111
10 0000 1011 0010 1100
0xC137 1100 0001 0111 0011
10 1100 1100 1001 1111
0x3304 0011 0011 0100 0000
10 1111 1111 1101 1111
10
1111 1111 1111 1111
4.11 - Adresse IPsource
Le champ IP source est codé sur 32 bits et représente l'adresse IP source ou de réponse. Il est codé
sur 4 octets qui forme l'adresse A.B.C.D.
4.12 - Adresse IP destination
Le champ IP destination est codé sur 32 bits et représente l'adresse IP destination. Il est codé sur 4
octets qui forme l'adresse A.B.C.D.
4.13 - Options
Le champ Options est codé entre 0 et 40 octets. Il n'est pas obligatoire, mais permet le "Tuning de
l'entête IP". Afin de bien gérer les Options, cela doit commencer par un octets de renseignement.
Voici le détail de cette octet :
 Réseau Informatique 3ème Semestre

4.13.1 - Copie
Le champ Copie est codé sur 1 bit et indique comment les options doivent être traitées lors de la
fragmentation. Cela signifie que lorsqu'il est positionné à 1, il faut recopier les options dans chaque
paquet fragmenté.
4.13.2 - Classe
Le champ Classe est codé sur 2 bits et indique les différentes catégorie d'options existantes. Voici la
liste des différentes classe possible :
- 0 - 00 - Supervision de réseau
- 1 - 01 - Non utilisé
- 2 - 10 - Debug et mesures
- 3 - 11 - Non utilisé
4.13.3 - Numéro
Le champ Numéro est codé sur 5 bits et indique les différentes options existantes. Voici la liste des
différents numéros possibles par Classe :
Classe 0,
- 0 - 00000 - Fin de liste d'option. Utilisé si les options ne se terminent pas à la fin de l'en-tête
(bourrage).
- 1 - 00001 - Pas d'opération. Utilisé pour aligner les octets dans une liste d'options.
- 2 - 00010 - Restriction de sécurité et de gestion. Destiné aux applications militaires.
- 3 - 00011 - Routage lâche défini par la source.
- 7 - 00111 - Enregistrement de route.
- 8 - 01000 - Identificateur de connexion.
- 9 - 01001 - Routage strict défini par la source.
Classe 2,
- 4 - 00100 - Horodatage dans l'Internet.
4.14 - Bourrage
Le champ Bourrage est de taille variable comprise entre 0 et 7 bits. Il permet de combler le champ
option afin d'obtenir une entête IP multiple de 32 bits. La valeur des bits de bourrage est 0.

[Link] 11
 Réseau Informatique 3ème Semestre

5. En-tête ARP IPv4

Signification des champs :

• Hardware type (type de matériel) :
01 - Ethernet (10Mb)
02 - Experimental Ethernet (3Mb)
• Protocol type (Type de protocole) :
0x0800 - IP
Ce champ indique quel est le type de protocole couche 3 (OSI) qui utilise ARP.
• Hardware Address Length (longueur de l’adresse physique) :
01 - Token Ring
06 - Ethernet
Ce champ correspond à la longueur de l’adresse physique. La longueur doit être prise en
octets.
• Protocol Address Length (longueur de l’adresse logique) :
04 - IP v4
16 - IP v6
Ce champ correspond à la longueur de l’adresse réseau. La longueur doit être prise en
octets.
• Operation :
01 - Request requête
02 - Reply réponse
Ce champ permet de connaître la fonction du message et donc son objectif.
• Sender Hardware Address : Adresse MAC source dans le cadre d’Ethernet.
• Sender Internet Address : Adresse IP de source dans le cadre de TCP/IP.
• Target Hardware Address : Adresse MAC destination dans le cadre d’Ethernet. Si c’est une
demande ARP, alors, ne connaissant justement pas cette adresse, le champ sera mis à 0.
• Target Internet Address : Adresse IP de destination dans le cadre de TCP/IP

[Link] 12
 Réseau Informatique 3ème Semestre

6. Paquet ICMP
Bien qu'il soit à un niveau équivalent au protocole IP, un paquet ICMP est néanmoins encapsulé
dans un datagramme IP. Dans le cadre de l'IPv4, la forme générale d'un tel paquet est la suivante :

Un tel datagramme est composé :

• d'un en-tête IP (en bleu), avec Protocole valant 1 et Type de Service valant 0.
• du type de message ICMP (8 bits)
signification du message
type
0 Echo Reply (réponse en écho)
3 Destination Unreachable (destination inaccessible)
4 Source Quench (interruption de la source)
5 Redirect (redirection, changement de route)
8 Echo Request (demande d’écho)
11 Time Exceeded for a Datagram (temps de vie d’un datagramme dépassé)
12 Parameter Problem on a Datagram (datagramme mal formé)
13 Timestamp Request (demande de date d’estampillage)
14 Timestamp Reply (réponse à une demande d’estampillage)
15 Information Request (demande d’information)
16 Information Reply (réponse à une demande d’information)
17 Address Mask Request (demande de masque d’adresse)
18 Address Mask Reply (réponse à une demande de masque d’adresse)
• du code de l'erreur (8 bits)
• d'une somme de contrôle (16 bits), calculée sur la partie spécifique à ICMP (sans l'en-tête IP)
• d'une partie aménagée pour des données relatives aux différents types de réponses (32 bits),
si elle n'est pas utilisée, on procède à un bourrage (cette partie peut correspondre aux
Identifiant et Numéro de séquence pour un paquet de type Ping par exemple)
• du message
[Link] 13
La fragmentation
La fragmentation va donc être un rôle secondaire de la couche 3 qui devra permettre
de découper un datagramme en plusieurs paquets ET de reconstituer ces paquets à la
machine destinatrice.

La difficulté va donc être de pouvoir découper, puis recomposer les paquets reçus,
même s’ils ne prennent pas le même chemin et arrivent dans le désordre, ou alors que
l’un d’entre eux est perdu.

En effet, sur Internet, il y a souvent beaucoup de chemins possibles pour aller d’une
machine A à une machine B et il peut arriver que des paquets ne suivent pas le même
chemin.

Nous allons donc maintenant voir comment nous allons découper notre datagramme et
identifier chacun des paquets qui seront coupés pour pouvoir les réassembler
correctement.

2- Découpage des fragments

On nous parle de fragment, paquet et datagramme, mais qu’est-ce qui représente quoi
là-dedans ?
• Le datagramme est l’information de couche 3 au moment où la machine qui émet
une information reçoit les informations de la couche 4.
• Un paquet est l’élément de couche 3 qui circule sur le réseau. Il peut être un
datagramme complet s’il n’a pas été découpé, ou un des morceaux de
datagrammes fragmentés.
• Un fragment est comme un paquet, sauf que l’on utilise souvent ce terme quand
on parle de fragmentation.
Imaginons que notre machine souhaite envoyer un datagramme de 1 600 octets. Une
trame pouvant transporter un datagramme de 1 500 octets (1518 - 18 octets d’en-tête
Ethernet), il va falloir fragmenter ce datagramme.

Mais où va-t-on couper ? Au milieu ? Au début ? À la fin ?

La réponse est simple, les fragments doivent toujours être les plus gros possible.

Ainsi, nous allons faire un premier fragment de 1 500 octets, et un autre de... 120 octets.

Heu... mais 1 500 + 120, ça ne fait pas 1 600 ?

C’est exact, mais vous avez oublié les 20 octets d’en-tête qui sont dans notre
datagramme d’origine. Il n’est pas nécessaire de les transporter, puisque nous allons de
toute façon fabriquer un nouvel en-tête pour chacun des fragments réalisés. Il faut aussi
ajouter un nouvel en-tête à chacun de nos nouveaux fragments. Voici un schéma qui
explique cela :
Fragmentation du datagramme pour une IP simple
On voit bien ici que l’ancien en-tête sera enlevé et que seules les données seront
découpées. Ensuite, chaque fragment aura un en-tête qui lui sera propre pour pouvoir
être aiguillé sur Internet.

OK, donc un datagramme trop gros devra être découpé en fragments les plus gros
possible.

Mais ça veut dire quoi, "les plus gros possible" ? C’est toujours 1 500 ? Ou ça peut être
plus ? Ou moins ?
En fait, cette information doit être donnée par la couche 2, car c’est elle qui va
encapsuler le datagramme IP et qui peut donc dire quelle taille de datagramme elle peut
transporter. D’ailleurs, cette information porte un nom dont vous avez peut-être déjà
entendu parler, il s’agit de la MTU (Maximum Transmission Unit).

La couche 2 va donc dire à la couche 3 quelle est la taille qu’elle peut accepter comme
datagramme, et la couche 3 va faire en sorte de découper les datagrammes trop gros
à cette taille. Par exemple, pour le protocole Ethernet, la MTU est de 1 500 octets.

Mais une des règles d’or du modèle OSI était que les couches étaient indépendantes
entre elles ? Ici, ce n’est pas le cas ?
En fait si, car cette information n’est pas contenue dans les en-têtes. Il n’y aura donc
pas de modification d’un protocole si l’on change cette taille. Le protocole IP utilise cette
information, mais il est capable d’en accepter de différentes valeurs si jamais on change
de protocole de couche 2. Cette information doit donc être définie par tout protocole
de couche 2.

3- Identification et assemblage des fragments

Nous savons donc maintenant que la couche 3 va devoir découper les datagrammes
trop gros par rapport à la MTU imposée par la couche 2. Mais il nous faut encore
découvrir comment ces fragments vont être identifiés, et comment une machine qui va
recevoir ces fragments va pouvoir reconstituer le puzzle !

Mais nous avons déjà vu des éléments dans l’en-tête que nous allons étudier plus en
détail.

En-tête IP avec fragmentation mise en avant

Il y a ici trois éléments qui nous intéressent : l’IPID, les flags et le fragment offset.

• L’IPID : c’est un identifiant unique qui permet de savoir de quel datagramme

d’origine proviennent les fragments. En gros, si un datagramme a l’IPID X, tous
les fragments qui en proviennent auront l’IPID X. Ainsi, quand une machine
recevra différents fragments X, Y ou Z, elle saura que ceux ayant l’IPID X
proviennent du même datagramme. Étant codé sur deux octets, il peut prendre
2^{16} valeurs, soit entre 0 et 65 535.
Mais maintenant que nous savons quels fragments proviennent d’un datagramme, il faut
encore être capable de les remettre dans l’ordre pour reconstituer le datagramme
d’origine. Il y a pour cela le fragment offset, qui n’est pas des plus simples à
comprendre...

• Le fragment offset : il indique la place du fragment par rapport au datagramme

d’origine.
Mais pour bien comprendre comment il fonctionne, nous allons devoir nous plonger
dans un cas concret.
Reprenons notre cas précédent :
Cas simple de fragmentation de datagramme
Nous allons donc devoir dire quelle est la place de chacun de ces fragments par rapport
au datagramme d’origine. Cette place est donnée en octets.

Par exemple, le premier fragment aura un fragment offset de 0, car il n’y a aucun
fragment avant lui.

Le second fragment aura un fragment offset de 1 480, car il y a 1 480 octets avant lui.

Attention, cependant, c’est plus compliqué que cela !

Le fragment offset n’est pas codé en octets, mais en mots de 8 octets. Il faut donc
diviser les octets par 8 pour obtenir le vrai fragment offset.

Dans notre exemple, le premier FO (Fragment Offset, mais je suis fainéant) vaut toujours
0. Par contre, le second vaudra non plus 1 480, mais 1480/8 soit 185.

Mais pourquoi s’amuse-t-on à diviser le nombre d’octets par 8 ? On n’a rien d’autre à
faire de mieux que des maths en réseau ?
En fait, c’est une nécessité, et pour le comprendre, nous allons revoir l’en-tête IP.

• La longueur d’un datagramme est codée sur 16 bits et peut donc prendre des
valeurs entre 0 et 65 535.
• Le fragment offset est codé sur 13 bits et peut donc prendre des valeurs entre 0
et 8 191.
Cependant, il est possible de devoir coder un fragment offset pour un datagramme qui
fait plus de 8 191 octets, et dans ce cas, on a un problème !

Les personnes qui ont créé le protocole IP se sont alors dit qu’en multipliant le fragment
offset par 8, on pourrait couvrir toutes les valeurs possibles de taille de datagramme.
Et c’est effectivement vrai : 8*8192=65536.

Mais d’où vient ce facteur multiplicateur de 8 ?

Eh bien, c’est la différence de 3 bits qui existe entre le nombre de bits pour coder la
taille du datagramme et celle de la taille de l’offset. 3 bits représentent 2323 valeurs,
soit 8 !
Cela apporte aussi une contrainte très forte pour nous :
La taille des données d’un paquet IP doit obligatoirement être un multiple de 8 !
Eh oui ! Cependant, si l’on regarde notre capture Wireshark précédente, on observe que
la taille totale du datagramme fait 1 326 octets, soit une taille de données de 1 306
octets, qui n’est pas un multiple de 8. C’est un peu contradictoire.
Capture Wireshark
Mais c’est normal, car en fait, le fragment offset doit coder des valeurs multiples de 8.
Mais ces valeurs correspondent au nombre d’octets des paquets précédents !

Le dernier paquet provenant d’un datagramme fragmenté n’a pas besoin d’avoir une
taille de données multiple de 8, car il n’y aura aucun fragment après lui et donc besoin
d’avoir un nombre de données multiple de 8.

Vous me suivez ? Si ce n’est pas le cas, relisez tranquillement les informations

précédentes plusieurs fois pour bien les assimiler.

On en arrive donc à la règle suivante :

La taille des données d’un paquet IP doit obligatoirement être un multiple de 8, sauf
pour le dernier fragment d’un datagramme fragmenté, ou d’un paquet qui n’a pas du
tout été fragmenté.
Il nous reste à voir un dernier champ que sont les flags, codés sur trois bits, chaque bit
représentant une information.

• Premier bit : Réservé, il n’est pas utilisé et vaut toujours 0.

• Second bit : Don't Fragment, qui indique donc que l’on veut obliger l’impossibilité
de fragmenter un datagramme. S’il vaut 0, on a le droit de fragmenter, s’il vaut 1,
on n’a pas le droit.
• Troisième bit : More fragment. Ce bit indique s’il y a encore des fragments
derrière celui-ci, et permet donc à une machine qui reçoit les fragments de savoir
quel est le dernier d’entre eux.
À quoi ça peut bien servir d’interdire de faire de la fragmentation ?
Cela peut avoir de l’intérêt pour connaître la plus petite MTU autorisée entre deux points
d’un réseau. C’est un mécanisme que l’on appelle MTU path discovery et qui sert
notamment à éviter de faire de la fragmentation quand il y a beaucoup d’échanges entre
deux points. Cela améliore légèrement les performances réseau, mais reste très peu
utilisé.

OK, donc pour récapituler, nous avons tous les éléments nécessaires pour fragmenter
un datagramme et être capables de le reconstruire à l’arrivée. Prenons un exemple
concret pour mieux comprendre en détail le fonctionnement de la fragmentation.0
4- Premier exercice de fragmentation
Nous allons faire un premier exercice simple sur la fragmentation pour remettre bout à
bout toutes les notions que nous venons de voir. Nous pourrons ensuite passer à un
exercice plus complexe !

Nous sommes sur un réseau simple que nous avons déjà utilisé par le passé avec deux
machines situées sur deux réseaux différents, et un routeur qui relie ces deux réseaux :

Schéma d'un réseau simple

Notre machine virtuelle 1 veut envoyer un datagramme de 5 600 octets à la machine
virtuelle 2. Les MTU pour les réseaux [Link]/24 et [Link]/24 sont
identiques et valent 1 500 octets, comme pour un réseau Ethernet habituel.

Il va donc falloir fragmenter !

Nous savons que chaque fragment doit être le plus gros possible. Ici, chaque fragment
devra donc faire 1 500 octets, sauf peut-être le dernier.

Chaque fragment aura donc la forme suivante :

Format d’un fragment

Chaque fragment pourra donc contenir 1 480 octets de données. Au passage, 1 480 est
bien un multiple de 8, donc tout va bien !

Notre datagramme d’origine fait 5 600 octets au total, soit 5 580 octets de données.
Nous allons maintenant chercher à savoir combien il nous faut de fragments pour
transporter ces données.

5580/1480=3,7...
Il va donc nous falloir 3 fragments de 1 480 octets, et un dernier fragment de 5580-
(1480*3)=5580-4440=1140 octets

Cela nous donne donc 4 fragments :

Découpage de notre datagramme en 4 fragments

Cherchons maintenant les informations contenues dans les en-têtes IP.

Dans le datagramme d’origine, nous avions :

• IPID : 10254 (choisi au hasard pour l’exemple)

• Flags : On n’indiquera que MF (More Fragments), qui est ici à 0, car le
datagramme est le dernier fragment, vu qu’il n’est pas encore fragmenté.
• FO (Fragment Offset) : 0
Dans notre premier fragment :

• IPID : 10254 (le même que dans le datagramme d’origine)

• Flags : MF=1 (il y a encore des fragments après celui-ci)
• FO : 0
Dans le second fragment :

• IPID : 10254
• Flags : MF=1
• FO : 1480/8=185
Dans le troisième fragment :

• IPID : 10254
• Flags : MF=1
• FO : 370 (1480*2/8)
Et dans le dernier fragment :
 • IPID : 10254
• Flags : MF=0 (Cette fois, c’est le dernier fragment !)
• FO : 555
Magnifique ! Nous avons réalisé notre première fragmentation !

Ainsi, la machine qui recevra ces fragments pourra les réassembler, même si elle les
reçoit dans le désordre.
Cependant, pour nous assurer que nous n’avons pas fait d’erreur de calcul, nous allons
faire une petite vérification.

Le fragment offset du dernier fragment représente toutes les données des fragments
précédents. Si l’on y ajoute le nombre de ses données, on devrait tomber sur le nombre
de données total. Vérifions cela :

(555*8)+1140=4440+1140=5580 octets

Ce qui correspond bien à ce que nous attendions !

Notons au passage une information importante que nous avons utilisée :

La valeur du fragment offset dépend de la taille des données contenues dans les
fragments précédents et non dans celles contenues dans le fragment lui-même.
Mais même si l’exemple précédent peut vous paraître complexe, il est en réalité très
simple. Et nous allons dès maintenant nous attaquer à une fragmentation plus
complexe. Si vous n’être pas encore très à l’aise avec celle-ci, refaites cet exercice en
changeant la taille du datagramme d’origine, par exemple.

5- Un second exercice plus complexe

Nous allons maintenant rajouter un peu de piment à notre exercice ! Pour cela, c’est très
simple, nous allons considérer le même réseau que précédemment, mais la MTU sur le
second réseau ne sera plus de 1 500, mais de 820.

Schéma réseau avec MTU différencié

Et cela va malheureusement considérablement nous compliquer la vie !
En effet, la machine 1 connaît la MTU de son propre réseau, qui est à 1 500. Mais elle
n’a aucune connaissance de la MTU du second réseau et va donc faire son découpage
du datagramme avec la MTU à 1 500.

Le découpage va donc être, dans un premier temps, le même que le précédent, et la

machine 1 va envoyer ces fragments sur le réseau.

Mais une fois arrivée au routeur 1, la table de routage de celui-ci va lui dire de les
envoyer sur le second réseau qui a une MTU de 820 ! Et là, le routeur a deux choix :

• soit il réassemble les fragments et les découpe une nouvelle fois ;

• soit il découpe directement les fragments reçus en fragments plus petits.
Et c’est en fait la seconde solution qui est utilisée en réseau, car aucun matériel réseau
n’a le droit de réassembler des fragments, sauf la machine destinatrice (et les firewalls
parfois pour des raisons de sécurité).

Le routeur va donc découper chacun des fragments qu’il a reçus en fonction de la

nouvelle MTU à 820. Les nouveaux fragments vont donc avoir un maximum de 800
octets de données.

Le découpage des fragments contenant 1 480 octets de données va donc être comme
ceci :

Découpage modifié des fragments

Et ce, pour les trois premiers gros fragments. Il nous reste encore à découper le dernier
fragment qui contient 1 140 octets de données :
Découpage du dernier fragment
Nous allons donc avoir en tout 8 fragments.

Résultat de la seconde fragmentation

Étudions le contenu de chacun, en présentant d’abord le datagramme d’origine :

• IPID : 8652
• Flags : MF=0
• FO : 0
Qui va donc être découpé en 4 fragments une première fois lors de l’envoi de la machine
1, puis en 8 fragments au passage par le routeur R1.

Le premier fragment contenant 800 octets de données :

• IPID : 8652
• Flags : MF=1
• FO : 0
Le second fragment contenant 680 octets de données :

• IPID : 8652
• Flags : MF=1
• FO : 100 (car le fragment précédent contient 800 octets)
Troisième fragment :

• IPID : 8652
• Flags : MF=1
• FO : 185
Quatrième fragment :

• IPID : 8652
• Flags : MF=1
 • FO : 285
Cinquième fragment :

• IPID : 8652
• Flags : MF=1
• FO : 370
Sixième fragment :

• IPID : 8652
• Flags : MF=1
• FO : 470
Septième fragment :

• IPID : 8652
• Flags : MF=1
• FO : 555
Huitième fragment :

• IPID : 8652
• Flags : MF=0
• FO : 655
Nous pouvons faire notre petit calcul pour vérifier que tout cela est bien correct en
tenant compte du dernier fragment offset à 655 et des 340 octets de données
contenues dans le dernier fragment :

(655*8)+340=5240+340=5580 octets

Parfait ! Cela correspond bien à ce que nous attendions !

Deux petites remarques au passage, que nous avons abordées, et qui sont importantes
pour bien comprendre la fragmentation :

Le flag More Fragment n’est positionné à 0 que pour le dernier fragment, même si
plusieurs fragmentations successives ont eu lieu.
Le réassemblage des fragments n’a lieu qu’à la destination. Tout routeur intermédiaire
ne réassemble pas ceux-ci (sauf les firewalls, mais nous allons savoir pourquoi très
bientôt !)
Pour ceux qui ne se sentent pas encore tout à fait à l’aise, je vous propose un dernier
petit exercice à faire par vous-même avant d’en lire la correction.

7- Exercice d’entraînement

On prend le schéma réseau précédent, mais avec des MTU différentes, 1 140 pour le
premier réseau et 420 pour le second :
Schéma réseau avec nouvelles MTU
Et la machine 1 souhaite envoyer un datagramme de 4 260 octets à la machine 2.

Écrivez tous les fragments reçus par la machine 2.

Vous pourrez voir la correction à la fin de ce chapitre.

Ce qu’il faut en retenir

Cependant, vous pourriez être en mesure de vous demander à quoi cela va bien pouvoir
vous servir.

Certes, la fragmentation est gérée automatiquement et ne génère quasiment jamais

de problèmes au niveau réseau.

Cependant, ce que vous venez d’apprendre vous sera utile pour mieux comprendre les
mécanismes réseau, et potentiellement ce que vous pouvez observer sur le réseau. Par
ailleurs, nous allons aborder la sécurité à la fin de cet ouvrage, et nous verrons que pour
faire de la sécurité, il est souvent nécessaire de connaître dans les plus petits détails le
fonctionnement d’un protocole ou d’un système.

Il n’est donc pas négligeable de bien connaître le fonctionnement détaillé du protocole

IP pour pouvoir étudier en détail ses failles potentielles, les comprendre et pourquoi ne
pas en imaginer de nouvelles !

D’ailleurs, nous allons maintenant aborder une attaque liée à la fragmentation. Ainsi,
vous verrez qu’avoir des connaissances profondes du fonctionnement d’un système est
le meilleur moyen d’imaginer comment contourner son fonctionnement normal pour
faire de la sécurité.

Pour aller plus loin

Pour ceux qui leu souhaitent, et seulement ceux qui se sentent très à l’aise, je vous
propose de réfléchir à une question.

Nous avons parlé précédemment du MTU path discovery. Je vous invite alors à
vous renseigner sur ce mécanisme, et à vous demander ce que cela aurait pu changer
sur nos précédents exercices.
Correction de l’exercice
Avant de commencer l’exercice, vérifiez bien que les MTU que l’on vous a fournis vous
permettent d’avoir un nombre de données qui est un multiple de 8.
Ici, c’est bien le cas pour une MTU de 1 140 (1 120 est un multiple de 8) et pour 420
(400 étant un multiple de 8).
Dans un premier temps, il faut fragmenter le datagramme d’origine selon la MTU de 1
140 octets, ce qui nous donne 4 fragments.
3 fragments comportant 1 120 octets de données, et un dernier fragment de 4240-
(1120*3)=880 octets.
Écrivons les informations de fragmentation contenues dans leurs en-têtes :
Fragment 1 :
• IPID : 12534
• Flags : MF=1
• FO : 0
Fragment 2 :
• IPID : 12534
• Flags : MF=1
• FO : 140
Fragment 3 :
• IPID : 12534
• Flags : MF=1
• FO : 280
Fragment 4 :
• IPID : 12534
• Flags : MF=0
• FO : 420
Dans un second temps, ces fragments arrivent au routeur 1 qui doit les fragmenter de
nouveau pour qu’ils puissent aller sur le second réseau dont la MTU fait 420 octets.
Chaque gros fragment va donc être découpé en trois fragments, deux premiers
contenant 400 octets de données, et le dernier contenant 1120-(400*2)=320 octets de
données
Le dernier fragment de 880 octets de données va aussi être fragmenté en trois, deux
fragments de 400 octets de données, et un dernier de 80 octets de données.
Ce qui nous donne finalement 12 fragments :
Fragment 1 :
• IPID : 12534
• Flags : MF=1
• FO : 0
Fragment 2 :

• IPID : 12534
• Flags : MF=1
• FO : 50
Fragment 3 :

• IPID: 12534
• Flags : MF=1
 • FO : 100
Fragment 4 :
• IPID: 12534
• Flags : MF=1
• FO : 140
Fragment 5 :
• IPID: 12534
• Flags : MF=1
• FO : 190
Fragment 6 :
• IPID: 12534
• Flags : MF=1
• FO : 240
Fragment 7 :
• IPID: 12534
• Flags : MF=1
• FO : 280
Fragment 8 :
• IPID: 12534
• Flags : MF=1
• FO : 330
Fragment 9 :

• IPID: 12534
• Flags : MF=1
• FO : 380
Fragment 10 :

• IPID: 12534
• Flags : MF=1
• FO : 420
Fragment 11 :

• IPID : 12534
• Flags : MF=1
• FO : 470
Fragment 12 :

• IPID : 12534
• Flags : MF=0
• FO : 520
Et comme d’habitude, nous pouvons vérifier notre calcul :

(520*8)+80=4160+80=4240 octets, ce qui correspond bien au nombre de données du

datagramme d’origine !
 Réseau Informatique Semestre 3 & 4

Protocole TCP
Table des matières
1. TCP – Transmission Control Protocol..............................................................................................2
1.1. Introduction...............................................................................................................................2
1.2. Caractéristiques de TCP............................................................................................................2
1.3. Description de l'en-tête.............................................................................................................4
1.4. Les ports....................................................................................................................................6
1.5. Les sockets................................................................................................................................7
1.6. Multiplexing / demultiplexing..................................................................................................9
2. Début et clôture d’une connexion...................................................................................................10
2.1. Établissement d’une connexion..............................................................................................10
2.2. Clôture d’une connexion.........................................................................................................11
2.2.1. Clôture canonique...........................................................................................................11
2.2.2. Clôture abrupte................................................................................................................12
3. Contrôle du transport......................................................................................................................13
3.1. Mécanisme de l’acquittement.................................................................................................13
3.2. Fenêtres glissantes..................................................................................................................14
4. Exemple de paquets capturés..........................................................................................................15
5. Conclusion......................................................................................................................................18
TCP est l'acronyme de « Transmission Control Protocol », il est défini dans la RFC 793. Les données encapsulées dans
un en-tête TCP sont des paquets TCP.

8-protocole_TCP.odt
 Réseau Informatique Semestre 3 & 4

1. TCP – Transmission Control Protocol

1.1. Introduction
Le rôle de la couche transport est de rendre possible la communication logique
entre applications. En anglais, on parle de logical end-to-end communication.
Il y a une grande différence entre la communication logique établie par la
couche transport et celle établie par la couche réseau. La couche transport
établit une communication logique entre les processus d'applications alors que
la couche réseau établit une communication logique entre les hôtes.
Quand un hôte envoie un message, il utilise une application comme un client de
messagerie. Cette application lui donne accès aux services réseaux pour envoyer
un mail. Une fois ce SDU reçu par la couche transport, il sera converti en un
PDU. La couche transport, qui est aussi responsable de la fragmentation des
unités de données, va « couper » ce SDU en plusieurs chaînes (ou morceaux) qu'on
appelle « chunks » en anglais. À chaque « morceau » sera ajouté un en-tête. Le
SDU reçu par la couche transport sera donc « brisé » en 4 PDU distincts, par
exemple :

Ces 4 PDU seront envoyés à la couche N-1 (la couche réseau en l'occurrence).

1.2. Caractéristiques de TCP

Cinq points principaux caractérisent ce protocole :
1. TCP contient un mécanisme pour assurer le bon acheminement des données.
Cette possibilité est absolument indispensable dès lors que les
applications doivent transmettre de gros volumes de données et de façon
fiable.
Il faut préciser que les paquets de données sont acquittés de bout en bout
et non de point en point. D'une manière générale le réseau assure
l'acheminement et les extrémités le contrôle.
2. Le protocole TCP permet l'établissement d'un circuit virtuel entre les
deux points qui échangent de l'information. On dit aussi que TCP
fonctionne en mode connecté (par opposition à UDP qui est en mode non
connecté ou encore mode datagramme).

8-protocole_TCP.odt 2
 Réseau Informatique Semestre 3 & 4

• Avant le transfert les 2 applications se mettent en relation avec

leurs OS respectifs, les informent de leurs désirs d'établir ou de
recevoir une communication.
• Pratiquement, l'une des deux applications doit effectuer un appel
que l'autre doit accepter.
• Les protocoles des 2 OS communiquent alors en s'envoyant des
messages au travers du réseau pour vérifier que le transfert est
possible (autorisé) et que les deux applications sont prêtes pour
leurs rôles.
• Une fois ces préliminaires établis, les modules de protocole
informent les applications respectives que la connexion est établie
et que le transfert peut débuter.
• Durant le transfert, le dialogue entre les protocoles continue, pour
vérifier le bon acheminement des données.
Conceptuellement, pour établir une connexion -- un circuit virtuel -- il
faut avoir réunis les éléments du quintuplet :
Le protocole
C'est TCP mais il y pourrait y avoir d'autres transports qui assurent le
même service...

IP locale
Adresse de la machine qui émet.

Port local
Le numéro de port associé au processus. Il est imposé ou est déterminé
automatiquement comme nous le verrons dans le cours de programmation.

IP distante
Adresse de la machine distante.

Port distant
Le numéro de port associé au service à atteindre. Il est obligatoire de le
connaître précisément.

L'ensemble de ces cinq éléments définit un circuit virtuel unique. Que

l'un d'eux change et il s'agit d'une autre connexion !
3. TCP a la capacité de mémoriser des données :
• Aux deux extrémités du circuit virtuel, les applications s'envoient
des volumes de données absolument quelconques, allant de 0 octet à
des centaines (ou plus) de Mo.
• À la réception, le protocole délivre les octets exactement comme ils
ont été envoyés.
• Le protocole est libre de fragmenter le flux de données en paquets
de tailles adaptées aux réseaux traversés. Il lui incombe cependant
d'effectuer le réassemblage et donc de stocker temporairement les
fragments avant de les présenter dans le bon ordre à l'application.
4. TCP est indépendant vis à vis des données transportées, c'est un flux
d'octets non structuré sur lequel il n'agit pas.
5. TCP simule une connexion en full duplex. Pour chacune des deux

8-protocole_TCP.odt 3
 Réseau Informatique Semestre 3 & 4

applications en connexion par un circuit virtuel, l'opération qui consiste

à lire des données peut s'effectuer indépendamment de celle qui consiste à
en écrire.
Le protocole autorise la clôture du flot dans une direction tandis que
l'autre continue à être active. Le circuit virtuel est rompu quand les
deux parties ont clos le flux.

1.3. Description de l'en-tête

La figure suivante montre la structure d'un en-tête TCP. Sa taille normale est
de 20 octets, à moins que des options soient présentes.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Port Source 2 octets Port destination 2 octets

Numéro de séquence

Numéro d'acquittement

Taille Réservé ECN URG ACK PSH RST SYN FIN Fenêtre
de
l'en-tête

Somme de contrôle Pointeur de données urgentes

Options Remplissage

Données

PORT SOURCE
Le numéro de port de l’application locale.
PORT DESTINATION
Le numéro de port de l’application distante.
NUMÉRO DE SEQUENCE
C’est un nombre qui identifie la position des données à transmettre par rapport
au segment original. Au démarrage de chaque connexion, ce champ contient une
valeur non nulle et non facilement prévisible, c’est la séquence initiale ou
ISN. Numéro du premier octet transmis dans le segment
Permet de s’assurer que les données ont été reçues dans l’ordre dans lequel elles ont été envoyées
TCP numérote chaque octet transmis en incrémentant ce nombre 32 bits non signé.
Il repasse à 0 après avoir atteint 232 − 1 (4 294 967 295).
Pour le premier octet des données transmis ce nombre est incrémenté de un, et
ainsi de suite...
NUMÉRO d’ACQUITTEMENT
C’est un numéro qui identifie la position du dernier octet reçu dans le flux
entrant. numéro de séquence identifiant le prochain octet attendu par l’émetteur. Permet de s’assurer que
les données ont été correctement reçues. Il doit s’accompagner du drapeau ACK (voir plus
loin).
LONGUEUR d'EN-TÊTE
pour Longueur d’en-tête, il s’agit d’un déplacement qui permet d’atteindre les
données quand il y a des options. Codé sur 4 bits, il s’agit du nombre de mots
de 4 octets qui composent l’en-tête. Le déplacement maximum est donc de 60
octets (24 − 1 × 4 octets). Dans le cas d’un en-tête sans option, ce champ porte
la valeur 5, ainsi 10 mots de 4 octets sont donc possibles pour les options.
RESERVE
Six bits réservés pour un usage futur !

8-protocole_TCP.odt 4
 Réseau Informatique Semestre 3 & 4
CODE
Six bits pour influer sur le comportement de TCP en caractérisant l’usage
du segment :
URG Le champ “URGENT POINTER” doit être exploité.
ACK Le champ “ACNOWLEDGMENT NUMBER” doit être exploité.
PSH C’est une notification de l’émetteur au récepteur, pour lui indiquer
que toutes les données collectées doivent être transmises à
l’application sans attendre les éventuelles données qui suivent.
RST Re-initialisation de la connexion
SYN Le champ “SEQUENCE NUMBER” contient la valeur de début de connexion.
FIN L’émetteur du segment a fini d’émettre.
URG = 1 indique que les données du segment sont urgentes et doivent être délivrées immédiatement
ACK = 1 indique que le numéro de séquence est valide et contient le prochain octet de données attendu
PSH = 1 indique une fin de message et que les données doivent être transmises à la couche supérieure
RST = 1 indique un arrêt ou un refus de connexion suite à la détection d’une erreur irrécupérable
SYN = 1 indique une demande de synchro de numéro de séquence : demande d'ouverture de connexion
FIN = 1 indique que l'émetteur n'a plus de données à transmettre : demande de fermeture de connexion
TAILLE DE FENETRE
Le flux TCP est contrôle de part et d’autre pour les octets com- pris dans une
zone bien délimitée et nommée “ fenêtre ”. La taille de celle-ci est définie par
un entier non signé de 16 bits, qui en limite donc théoriquement la taille `a 65
535 octets. Nombre d'octets de données à transmettre à partir de celui indiqué par le champ numéro
d’acquittement. Chaque partie annonce ainsi la taille de son buffer de réception.
Par construction, l’émetteur n’envoie pas plus de données que le récepteur ne
peut en accepter.
Cette valeur varie en fonction de la nature du réseau et surtout de la bande
passante devinée à l’aide de statistiques sur la valeur du RTT.
SOMME DE CONTRÔLE (CHECKSUM)
Un calcul qui porte sur la totalité du segment, en-tête et données.
PRIORITÉ (URGENT POINTER)
Ce champ n’est valide que si le drapeau URG est armé(1). Ce pointeur contient
alors un offset à ajouter à la valeur de SEQUENCE NUMBER du segment en cours
pour délimiter la zone des données urgentes à transmettre à l’application.
Le mécanisme de transmission à l’application dépend du système d’exploitation.
OPTIONS
C’est un paramétrage de TCP. Sa présence est détectée dès lors que Longueur d’en-
tête est supérieur à 5. Permet, par exemple, de définir la taille maximale d’un segment
Les options utilisées :
mss La taille maximale du segment 5 des données applicatives que
l’émetteur accepte de recevoir. Au moment de l’établissement d’une
connexion (paquet comportant le flag SYN), chaque partie annonce sa
taille de MSS. Ce n’est pas une négociation. Pour de l’Ethernet la
valeur est 1460 (= MTU − 2 × 20).

timestamp pour calculer la durée d’un aller et retour (RTT ou “round trip
time”).

Wscale Facteur d’échelle (“shift”) pour augmenter la taille de la fenêtre

au delà des 16 bits du champ WINDOW ( > 65535).
Quand cette valeur n’est pas nulle, la taille de la fenêtre est de
65535 × 2shift . Par exemple si “shift” vaut 1 la taille de la fenêtre
est de 131072 octets soit encore 128 ko.
nop Les options utilisent un nombre quelconque d’octets par

8-protocole_TCP.odt 5
 Réseau Informatique Semestre 3 & 4

contre les paquet TCP sont toujours alignés sur une taille de mot
de quatre octets ; à cet effet une option “No Operation” ou nop,
codée sur 1 seul octet, est prévue pour compléter les mots.
REMPLISSAGE PADDING
Remplissage pour se caler sur un mot de 32 bits.
DATAS
Les données transportées. Cette partie est de longueur nulle à l’établissement
de la connexion, elle peut également être nulle par choix de l’application.

1.4. Les ports

Le numéro de port est le numéro qui permet de faire la distinction entre les
applications. Par exemple, dans la transmission d'un mail, le premier service ou
la première application utilisée est un MUA. Le MUA utilise le protocole SMTP
pour envoyer le mail au serveur de messagerie souvent en passant par un MSA.
Dans l'ordre de réception, on utilisait également un autre MUA pour retirer le
mail du serveur de messagerie avec un protocole de réception comme IMAP ou POP.
Il se peut donc que les deux services (POP/IMAP et SMTP) soient exécutés au même
moment sur une même machine hôte. C'est là qu'intervient le numéro de port, qui
permet de faire la distinction entre les services qui ont été demandés par
l'application distante, qu'il s'agisse d'un serveur de messagerie ou d'un client
de messagerie. Le protocole SMTP utilise le protocole TCP pour la transmission
au numéro de port 25.
L'organisme IANA (Internet Assigned Numbers Authority) classe les numéros de
port en trois catégories principales, comme l'illustre le tableau ci-dessous :
Portée Catégorie Description

0 – 1023 Ports bien connus Ports réservés pour des services bien connus
(web, envoi de mail, etc.).

1024 – 49151 Ports réservés Ports réservés pour être utilisés par des
applications propriétaires.

49152 – 65635 Ports dynamiques Ports « libres » à utiliser pour vos

applications. Ils ne sont ni pour des
services bien connus, ni réservés par une
entreprise quelconque.

Voici quelques ports bien connus :

Protocole Description Protocole de Numéro Statut
transmission de port d'assignation

File Transfert Protocole de transfert de TCP 21 Officiel

Protocole (FTP) fichier

Secured SHell Protocole permettant TCP & UDP 22 Officiel

(SSH) l'échange de données par
le biais d'un canal
sécurisé

Telnet Utilisé pour TCP 23 Officiel

l'établissement des
sessions à distance

8-protocole_TCP.odt 6
 Réseau Informatique Semestre 3 & 4

Simple Mail Protocole d'envoi de TCP 25 Officiel

Transfer courrier électronique
Protocol (SMTP)

WHOIS protocol Protocole ou service TCP 43 Officiel

utilisé pour
l'identification d'une
machine par son nom de
domaine ou son adresse
IP. La procédure
d'identification se fait
par une requête envoyée à
un des registres Internet
pour obtenir des
informations.

Domain Name Protocole de résolution TCP & UDP 53 Officiel

System (DNS) des noms de domaine

HyperText Protocole de TCP & UDP 80 Officiel

Transfer téléchargement
Protocol (HTTP) (principalement de pages
web)

Post Office Protocole de retrait de TCP 109 Officiel

Protocol mails d'un serveur de
messagerie
Version 2 (POP2)

Post Office Protocole de retrait de TCP 110 Officiel

Protocol mails d'un serveur de
messagerie
Version 3 (POP3)

Internet Message Protocole de retrait et TCP & UDP 143 Officiel

Access Protocol consultation de mails
(IMAP) d'un serveur de
messagerie

… … … … ...

• Statut d'assignation : le statut officiel veut dire que le couple

application / numéro de port a été enregistré dans les registres de
l'IANA. En d'autres termes, il est défini par une convention que telle
application utilise tel numéro de port.
• Protocole de transmission : les protocoles peuvent s'utiliser entre eux.
Le protocole SMTP qui sert à envoyer un mail s'appuie sur le protocole TCP
pour le transmettre. On parle de sous-couchage de protocoles
(underlayering protocols).

1.5. Les sockets

Les protocoles se chevauchent : un protocole applicatif (SMTP, POP, HTTP, etc)
peut être interfacé à un protocole de transport (UDP, TCP). Un socket est une
interface entre les processus : en réseau, un socket sert donc à faire
communiquer un processus avec un service qui gère le réseau. Chaque socket a une

8-protocole_TCP.odt 7
 Réseau Informatique Semestre 3 & 4

adresse de socket. Cette adresse est constituée d'une adresse IP et d'un numéro
de port. C'est grâce à la programmation de socket que l'on définit le modèle de
communication. Si le socket a été configuré de manière à envoyer ou recevoir,
c'est un modèle Half-Duplex. S'il a été configuré de manière à envoyer et
recevoir simultanément, il s'agit d'un modèle Full-Duplex. Étant donné que les
sockets sont en fait une interface de programmation d'applications (API), on
peut donc s'en servir pour programmer des applications en réseaux (par exemple,
créer une application pour faire communiquer un client et un serveur).
Voici un schéma illustrant une communication entre un client et un serveur :

Le client commence à se connecter au serveur grâce aux sockets. Une fois la

connexion établie (étape 1), le client et le serveur peuvent communiquer (étapes
2 et 3). À la fin de la communication, le client envoie une demande de
terminaison de session au serveur (étape 4) et le serveur met fin à la
connexion.
Le serveur utilise les sockets pour lier un port d'application à son processus
correspondant. Ensuite, il « écoute » ce port. Ce faisant, il va découvrir qu'un
client essaie de se connecter à lui par le numéro de port qu'il écoute. Il
accepte donc la requête, établit la connexion (étape 1) et, finalement, les deux
communiquent (étapes 2, 3 et 4). Le modèle de communication est Half-Duplex
parce que le client envoie et attend la réponse du serveur et vice-versa.

8-protocole_TCP.odt 8
 Réseau Informatique Semestre 3 & 4

1.6. Multiplexing / demultiplexing

Le rôle de la couche transport est d'acheminer ou de donner les PDU reçus aux
processus d'application identifiables par un numéro de port. Il se peut que
plusieurs services (processus d'applications) soient exécutés au même moment.
Certaines applications peuvent avoir plusieurs instances en cours d'exécution
qui donnent accès aux services du protocole HTTP. Lorsque la couche transport
reçoit les PDU de la couche réseau, elle va examiner les en-têtes de ces PDU
afin de retrouver l'identifiant du processus auquel le PDU doit être acheminé.
C'est le démultiplexage : le fait de transmettre un PDU donné au processus d'une
application donnée.
Ainsi, un protocole de la couche transport est responsable de la collection des
SDU, de leur encapsulation, en spécifiant le numéro de port du processus de
l'application utilisée et le numéro de port à utiliser pour le processus de
l'application réceptrice. Cette encapsulation, c'est la transformation du SDU en
PDU. Ce protocole est aussi responsable de la livraison de ce PDU à un protocole
de la couche inférieure (couche réseau, protocole IP).
Les protocoles TCP et UDP sont donc responsables de la modification des en-têtes
des unités de données lors du multiplexage / démultiplexage.
Un segment de protocole de transport est partiellement constitué des champs
« port source » (source port), « port de destination » (destination port) et
« SDU ». Le champ « port source » contiendra le numéro de port utilisé par
l'application émettrice. Le champ « port de destination » contiendra le numéro
de port identifiant l'application réceptrice. Finalement, le champ « SDU »,
c'est le message original.
Les serveurs web créent un nouveau processus pour chaque requête HTTP qu'ils
reçoivent. Un serveur qui gère 10 requêtes gère donc 10 processus utilisant tous
le même numéro de port.
Pour le démultiplexage, il faut deux numéros de port (source et destination). En
général, le protocole de cette couche (UDP ou TCP) va générer automatiquement un
numéro de port qu'aucun processus n'utilise actuellement.
Y sera la valeur du champ « Source port » et 80 la valeur du champ « Destination
port ».

Le serveur va recevoir ce PDU et examiner sa constitution.

Dans la procédure d'envoi de la requête, le champ « Source port » avait pour
valeur Y. Dans l'envoi de la réponse, le champ « Source port » prend la valeur
du champ « Destination port » de la requête, et le champ « Destination port »
prend la valeur du champ « Source port » de la requête. Ainsi, le segment envoyé
par le serveur web ressemblera à ceci :

8-protocole_TCP.odt 9
 Réseau Informatique Semestre 3 & 4

Pour résumer cela, voici un schéma qui montre les valeurs de chaque champ au
niveau du client et au niveau du serveur :

2. Début et clôture d’une connexion

2.1. Établissement d’une connexion
L’ établissement d’une connexion TCP s’effectue en trois temps :

8-protocole_TCP.odt 10
 Réseau Informatique Semestre 3 & 4

On suppose que l’ émetteur du premier paquet avec le bit SYN a connaissance du

couple (adresse IP du récepteur, numéro de port du service souhaité).
L’émetteur du premier paquet est à l’origine de l’établissement du circuit
virtuel, c’est une attitude généralement qualifiée de “cliente”. On dit aussi
que le client effectue une “ouverture active” (active open).
Le récepteur du premier paquet accepte l’établissement de la connexion, ce qui
suppose qu’il était prêt à le faire avant que la partie cliente en prenne
l’initiative. C’est une attitude de “serveur”. On dit aussi que le serveur
effectue une “ouverture passive” (passive open).
1. Le client envoie un segment comportant le drapeau SYN , avec sa séquence
initiale (ISN = x).
2. Le serveur répond avec sa propre séquence (ISN = y), mais il doit
également acquitter le paquet précédent, ce qu’il fait avec ACK (seq = x +
1).
3. Le client doit acquitter le deuxième segment avec ACK (seq = y + 1).
Une fois achevé cette phase nomme “three-way handshake”, les deux applications
sont en mesure d’échanger les octets qui justifient l’établissement de la
connexion.

2.2. Clôture d’une connexion

2.2.1. Clôture canonique
Un change de trois segments est nécessaire pour l’établissement de la
connexion ; il en faut quatre pour qu’elle s’achève de manière canonique
(“orderly release”).

8-protocole_TCP.odt 11
 Réseau Informatique Semestre 3 & 4

La raison est qu’une connexion TCP est “full-duplex”, ce qui implique que les
données circulent indépendamment dans un sens et dans l’autre. Les deux
directions doivent donc pouvoir être interrompues indépendamment l’une de
l’autre.
L’application qui envoie un paquet avec le drapeau FIN indique à la couche TCP
de la machine distante qu’elle n’enverra plus de donnée. La machine distante
doit acquitter ce segment, comme il est indiqué sur la figure ci-dessus, en
incrémentant d’une unité le “sequence number”.
La connexion est véritablement terminée quand les deux applications ont effectué
ce travail. Il y a donc échange de 4 paquets pour terminer la connexion.
Au total, sans compter les échanges propres au transfert des données, les deux
couches TCP doivent gérer 7 paquets, il faut en tenir compte lors de la
conception des applications !
Sur la figure on constate que le serveur continue d’envoyer des données bien que
le client ait terminé ses envois. Le serveur a détecté cette attitude par la
réception d’un caractère de EOF (en C sous Unix ).
Cette possibilité a son utilité, notamment dans le cas des traitements distants
qui doivent s’accomplir une fois toutes les données transmises, comme par
exemple pour un tri.

2.2.2. Clôture abrupte

Au lieu d’un échange de quatre paquets comme précédemment, un mécanisme de reset
est prévu pour terminer une connexion au plus vite (abortive release).
Ce type d’arrêt est typiquement géré par la couche TCP elle-même quand
l’application est brutalement interrompue sans avoir effectué un appel à la
primitive close, comme par exemple lors d’un appel à la primitive abort, ou
après avoir rencontré une exception non prise en compte (“core dump”...).

8-protocole_TCP.odt 12
 Réseau Informatique Semestre 3 & 4

L’extrémité qui arrête brutalement la connexion émet un paquet assorti du bit

RST, après avoir (ou non) envoyé les derniers octets en attente. Ce paquet clôt
l’échange. Il ne reçoit aucun acquittement. L’extrémité qui reçoit le paquet de
reset (bit RST ), transmet les éventuelles dernières données à l’application et
provoque une sortie d’erreur du type “Connection reset per peer” pour la
primitive de lecture réseau. Comme c’est le dernier échange, si des données
restaient à transmettre à l’application qui a envoyé le RST elles peuvent être
détruites.

3. Contrôle du transport
Le bon acheminement des données applicatives est assurée par un mécanisme
d’acquittement des paquets.

3.1. Mécanisme de l’acquittement

• Au départ du Paquet i une horloge se déclenche. Si cette horloge dépasse

une valeur limite avant réception de l’ACK le Paquet i est retransmis.
Cette valeur limite est basée sur la constante MSL (Maximum Segment
Lifetime) qui est un choix d’implémentation, généralement de 30 secondes à
2 minutes. Le temps maximum d’attente est donc de 2 × MSL.
• Le temps qui s’écoule entre l’émission d’un paquet et la réception de son
acquittement est le RTT1, il doit donc être inférieur à 2 × MSL. Il est
courant sur l’Internet actuel d’avoir un RTT de l’ordre de la seconde. Il
faut noter que le RTT est la somme des temps de transit entre chaque
routeur et du temps passé dans les diverses files d’attente sur les
routeurs.
• L’émetteur conserve la trace du Paquet i pour éventuellement le renvoyer.
Si on considère des délais de transmission de l’ordre de 500 ms (voire plus), un
tel mécanisme est totalement inadapté au transfert de flux de données. On peut
aussi remarquer qu’il sous-emploie la bande passante du réseau.

1 Round Trip Time, calculé à l’aide de l’option timestamp

8-protocole_TCP.odt 13
 Réseau Informatique Semestre 3 & 4

3.2. Fenêtres glissantes

Cette attente de l’acquittement est pénalisante, sauf si on utilise un mécanisme
de fenêtres glissantes :

• Avec ce principe, la bande passante du réseau est beaucoup mieux employée.

• Si l’un des paquets doit être reémis, la couche TCP du destinataire aura
toute l’information pour le replacer dans le bon ordre.
• À chaque paquet est associée une horloge comme sur la figure.
• Le nombre de paquets à envoyer avant d’attendre le premier acquittement
est fonction de deux paramètres :
1. La largeur de la fenêtre change dynamiquement pour deux raisons :
a) L’application change la taille de cette fenêtre.
b) Chaque acquittement ACK envoyé est assorti d’une nouvelle valeur de
taille de la fenêtre, permettant ainsi à l’émetteur d’ajuster à tout
instant le nombre de segment qu’il peut envoyer simultanément. Celle
valeur peut être nulle, comme par exemple lorsque l’application cesse
de lire les données reçues. C’est ce mécanisme qui assure le contrôle
de flux de TCP.
2. La taille maximale des données, ou MSS (Maximum Segment Size) vaut 512
octets par défaut. C’est la plus grande taille du segment de données que
TCP enverra au cours de la session. Le datagramme IP a donc une taille
égale au MSS augmentée de 40 octets (20 + 20), en l’absence d’option de
TCP .
Cette option apparaît uniquement dans un paquet assorti du drapeau SYN ,
donc à l’établissement de la connexion. Comme de bien entendu cette valeur
est fortement dépendante du support physique et plus particulièrement du
MTU (Maximum Transfer Unit).
Sur de l’Ethernet la valeur maximale est 1500 − 2 × 20 = 1460, avec des
trames l’encapsulation 802.3 de l’IEEE un calcul similaire conduit à une
longueur de 1452 octets.

8-protocole_TCP.odt 14
 Réseau Informatique Semestre 3 & 4

Chaque couche TCP envoie sa valeur de MSS en même temps que le paquet de
synchronisation, comme une option de l’en-tête. Cette valeur est calculée
pour éviter absolument la fragmentation de IP au départ des datagrammes.

Le débit obtenu dépend de la taille de la fenêtre et bien sûr de la bande

passante disponible. Par contre l’agrandissement de la taille de la fenêtre ne
se conçoit que jusqu’à une limite optimale au delà de laquelle des paquets sont
perdus parce qu’envoyés trop rapidement pour être reçus par le destinataire. Or,
pour fonctionner de manière optimale, TCP se doit de limiter au maximum la perte
de paquets et donc leur réémission.
Cette taille limite optimale de la largeur de la fenêtre est, comme on peut le
deviner, fonction de la bande passante théorique du réseau et surtout de son
taux d’occupation instantané. Cette dernière donnée est fluctuante, aussi TCP
doit-il asservir continuellement les tailles de fenêtre pour en tenir compte.

4. Exemple de paquets capturés

Le premier exemple montre un échange de paquets de synchronisation (SYN) et de
fin (FIN) entre la machine [Link] et la machine [Link].
L’établissement de la connexion se fait à l’aide de la commande telnet sur le
port discard du serveur [Link]. La machine qui est à l’origine de
l’établissement de la connexion est dite cliente, et celle qui est supposée
prête à répondre, serveur. Pour information, le service discard peut être
considéré comme l’équivalent du fichier /dev/null sur le réseau : les octets
qu’on lui envoie sont oubliés (“discard”).
L’utilisateur tape :
$ telnet srv discard
Trying...
Connected to [Link].
Escape character is ’^]’.
telnet> quit
Connection closed.
Et l’outil d’analyse réseau permet la capture pour l’observation des échanges

8-protocole_TCP.odt 15
 Réseau Informatique Semestre 3 & 4

suivants. Le numéro qui figure en tête de chaque ligne a été ajouté

manuellement, le nom de domaine “chezmoi” a été retiré, le tout pour faciliter
la lecture :
0 [Link].274009 clnt.1159 > [Link]: S 55104001:55104001(0) win 8192 <mss
1460>
1 [Link].275114 [Link] > clnt.1159: S 2072448001:2072448001(0) ack
55104002 win 4096 <mss 1024>
2 [Link].275903 clnt.1159 > [Link]: . ack 1 win 8192
3 [Link].456899 clnt.1159 > [Link]: F 1:1(0) ack 1 win 8192
4 [Link].457559 [Link] > clnt.1159: . ack 2 win 4096
5 [Link].458887 [Link] > clnt.1159: F 1:1(0) ack 2 win 4096
6 [Link].459598 clnt.1159 > [Link]: . ack 2 win 8192
Plusieurs remarques s’imposent :
1. Pour améliorer la lisibilité les numéros de séquences “vrais” ne sont
indiqués qu’au premier échange. Les suivants sont relatifs. Ainsi le ack 1
de la ligne 2 doit être lu 2072448002 (2072448001 + 1). A chaque échange
la valeur entre parenthèses indique le nombre d’octets échangés.
2. Les tailles de fenêtre (win) et de segment maximum (mss) ne sont pas
identiques. Le telnet du client fonctionne sur HP-UX alors que le serveur
telnetd fonctionne sur une machine BSD.
3. La symbole > qui marque le sens du transfert.
4. Le port source 1159 et le port destination discard.
5. Les flags F et S. L’absence de flag, repéré par un point.
Le deuxième exemple montre une situation de transfert de fichier avec l’outil
ftp (File Transfer Protocol).
Il faut remarquer que l’établissement de la connexion TCP est ici à l’initiative
du serveur, ce qui peut laisser le lecteur perplexe... L’explication est simple.
En fait le protocole ftp fonctionne avec deux connexions TCP, la première, non
montrée ici, est établie du client vers le serveur, supposé à l’écoute sur le
port 21. Elle sert au client pour assurer le contrôle du transfert.
Lorsqu’un transfert de fichier est demandé via cette première connexion, le
serveur établit une connexion temporaire vers le client. C’est cette connexion
que nous examinons ici. Elle est clôturée dès que le dernier octet demandé est
transféré.
Extrait du fichier /etc/services, concernant ftp :
ftp-data 20/tcp #File Transfer [Default Data]
ftp-data 20/udp #File Transfer [Default Data]
ftp 21/tcp #File Transfer [Control]
ftp 21/udp #File Transfer [Control]
Dans cette exemple nous pouvons suivre le fonctionnement du mécanisme des
fenêtres glissantes. Les lignes ont été numérotées manuellement et la date
associée à chaque paquet supprimée.
0 srv.20 > clnt.1158: S 1469312001:1469312001(0) win 4096 <mss 1024> [tos 0x8]
1 clnt.1158 > srv.20: S 53888001:53888001(0) ack 1469312002 win 8192 <mss
1460>

8-protocole_TCP.odt 16
 Réseau Informatique Semestre 3 & 4

2 srv.20 > clnt.1158: . ack 1 win 4096 [tos 0x8]

3 srv.20 > clnt.1158: P 1:1025(1024) ack 1 win 4096 [tos 0x8]
4 clnt.1158 > srv.20: . ack 1025 win 8192
5 srv.20 > clnt.1158: . 1025:2049(1024) ack 1 win 4096 [tos 0x8]
6 srv.20 > clnt.1158: . 2049:3073(1024) ack 1 win 4096 [tos 0x8]
7 clnt.1158 > srv.20: . ack 3073 win 8192
8 srv.20 > clnt.1158: . 3073:4097(1024) ack 1 win 4096 [tos 0x8]
9 srv.20 > clnt.1158: P 4097:5121(1024) ack 1 win 4096 [tos 0x8]
10 srv.20 > clnt.1158: P 5121:6145(1024) ack 1 win 4096 [tos 0x8]
11 clnt.1158 > srv.20: . ack 5121 win 8192
12 srv.20 > clnt.1158: P 6145:7169(1024) ack 1 win 4096 [tos 0x8]
13 srv.20 > clnt.1158: P 7169:8193(1024) ack 1 win 4096 [tos 0x8]
14 clnt.1158 > srv.20: . ack 7169 win 8192
15 srv.20 > clnt.1158: P 8193:9217(1024) ack 1 win 4096 [tos 0x8]
16 srv.20 > clnt.1158: P 9217:10241(1024) ack 1 win 4096 [tos 0x8]
17 clnt.1158 > srv.20: . ack 9217 win 8192
18 srv.20 > clnt.1158: P 10241:11265(1024) ack 1 win 4096 [tos 0x8]
19 srv.20 > clnt.1158: P 11265:12289(1024) ack 1 win 4096 [tos 0x8]
20 clnt.1158 > srv.20: . ack 11265 win 8192
... ... ...
21 srv.20 > clnt.1158: P 1178625:1179649(1024) ack 1 win 4096 [tos 0x8]
22 clnt.1158 > srv.20: . ack 1178625 win 8192
23 srv.20 > clnt.1158: P 1212417:1213441(1024) ack 1 win 4096 [tos 0x8]
24 srv.20 > clnt.1158: P 1213441:1214465(1024) ack 1 win 4096 [tos 0x8]
25 srv.20 > clnt.1158: P 1214465:1215489(1024) ack 1 win 4096 [tos 0x8]
26 clnt.1158 > srv.20: . ack 1213441 win 8192
27 clnt.1158 > srv.20: . ack 1215489 win 8192
28 srv.20 > clnt.1158: P 1215489:1215738(249) ack 1 win 4096 [tos 0x8]
29 srv.20 > clnt.1158: F 1215738:1215738(0) ack 1 win 4096 [tos 0x8]
30 clnt.1158 > srv.20: . ack 1215739 win 8192
31 clnt.1158 > srv.20: F 1:1(0) ack 1215739 win 8192
32 srv.20 > clnt.1158: . ack 2 win 4096 [tos 0x8]
Remarques :
1. Le P symbolise le drapeau PSH. La couche TCP qui reçoit un tel paquet est
informée qu’elle doit transmettre à l’application toutes les données
reçues, y compris celles transmises dans ce paquet. Le positionnement de
ce drapeau est à l’initiative de la couche TCP émettrice et non à
l’application.
2. Le type de service (“Type Of service” tos 0x8) est demandé par
l’application pour maximiser le débit.

8-protocole_TCP.odt 17
 Réseau Informatique Semestre 3 & 4

5. Conclusion
Le protocole TCP a été conçu à une époque où l’usage de la commande ligne était
universel, et les applications graphiques utilisant le réseau très rares !
Une trentaine d’années plus tard, on peut faire le constat pratiquement
inverse : les applications textes interactives (beaucoup de petits messages
applicatifs) disparaissent au profit d’applications moins interactives et qui
sont plus orientées flux de données (vidéo, audio, téléphonie...) avec des
échanges plus volumineux et des besoins en transport qui ont évolué.
Le principe de la fenêtre glissante, si performant qu’il soit pour assurer le
bon acheminement des données, est bloquant pour certaines applications comme le
web. En effet, si le paquet de données de tête n’est pas acquitté, les suivants,
même reçus, sont en attente avant d’être délivrés à l’application.
Si la réponse comporte par exemple de nombreuses zones graphiques et textuelles
différentes la fluidité de la consultation est considérablement amoindrie, et
tenter de la compenser en établissant un grand nombre de connexions simultanées
pour récupérer individuellement les éléments de la page, consomme beaucoup de
ressources système et réseaux (celles de l’établissement des connexions) qui ne
compense que partiellement ce soucis.
L’indépendance de TCP vis `a vis de la structure des données est également un
inconvénient dans certaines applications comme la téléphonie pour la- quelle la
notion de messages successifs est bien plus intéressante.
Depuis le début des années 2000 l’IETF met au point le protocole SCTP qui
fournit des services similaires à ceux de TCP, en abandonne certains et apporte
les nouvelles fonctionnalités adaptées aux nouveaux besoins.

8-protocole_TCP.odt 18
 Informatique et Science du Numérique

Protocole UDP
Table des matières
1. Identification de la destination.........................................................................................................2
2. Description de l'en-tête.....................................................................................................................3
3. Ports réservés/disponibles................................................................................................................5
3.1. Attribution des ports (ancienne méthode).................................................................................6
3.2. Attribution des ports (nouvelle méthode).................................................................................6

UDP est l'acronyme de « User Datagram Protocol », il est défini dans la RFC 768. Les données
encapsulées dans un en-tête UDP sont des paquets UDP.

8-protocole_UDP.odt 1
 Informatique et Science du Numérique

1. Identification de la destination
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
divers 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 remplie. 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. A 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.
La figure ci-dessous explicite la notion de port. La couche IP sépare les
datagrammes SCTP, TCP et UDP grâce au champ PROTO de son en-tê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.

Numéro de port comme numéro de service

8-protocole_UDP.odt 2
 Informatique et Science du Numérique

2. Description de l'en-tête
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 encapsulé dans IP

• 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 FIFO1. 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.
Parmi les utilisations les plus courantes d'UDP on peut signaler le serveur de
noms, base de données répartie 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.

Structure de l'en-tête UDP

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.

1 First In First Out

8-protocole_UDP.odt 3
 Informatique et Science du Numérique

UDP DESTINATION PORT

Le numéro de port du destinataire du paquet.

MESSAGE LENGTH
C'est la longueur du paquet, donc comprenant l'en-tête et le message.
• La longueur minimal 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 en-tête constitué de la manière
suivante :

Cas du checksum non nul

Ce pseudo en-tête est prévu initialement pour apporter une protection en cas de
datagrammes mal routés !
3. Ports réservés/disponibles
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 (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, 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.

8-protocole_UDP.odt 4
 Informatique et Science du Numérique

Nom Port Proto Commentaire

echo 7 tcp
echo 7 udp
ftp-data 20 tcp #File Transfer [Default Data]
ftp-data 20 udp #File Transfer [Default Data]
ftp 21 tcp #File Transfer [Control]
ftp 21 udp #File Transfer [Control]
ssh 22 tcp #Secure Shell Login
ssh 22 udp #Secure Shell Login
smtp 25 tcp mail #Simple Mail Transfer
smtp 25 udp mail #Simple Mail Transfer
domain 53 tcp #Domain Name Server
domain 53 udp #Domain Name Server
http 80 tcp www www-http #World Wide Web HTTP
http 80 udp www www-http #World Wide Web HTTP
pop3 110 tcp #Post Office Protocol - Version 3
pop3 110 udp #Post Office Protocol - Version 3
imap 143 tcp #Interim Mail Access Protocol
imap 143 udp #Interim Mail Access Protocol
https 443 tcp #Secure World Wide Web HTTP
https 443 udp #Secure World Wide Web HTTP
Ce tableau présente quelques uns des ports bien connus plus connus les plus
utilisés, il y en a quantité d'autres...
L'IANA, 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.
3.1. Attribution des ports (ancienne méthode)
Historiquement les ports de 1 à 255 sont réservés aux services bien connus,
plus récemment, ce segment à été élargi à [1,1023]. Aucune application ne peut
s'attribuer durablement et au niveau de l'Internet un numéro de port dans ce
segment, sans en référer à l'IANA, qui en contrôle l'usage.
À partir de 1024 et jusqu'à 65535, l'IANA se contente d'enregistrer les
demandes d'usage et signale les éventuels conflits.

3.2. Attribution des ports (nouvelle méthode)

Devant l'explosion du nombre des services enregistrés l'IANA a modifié la
segmentation qui précède. Désormais les numéros de ports sont classés selon les
trois catégories suivantes :
1. Le segment [1,1023] est toujours réservés aux services bien connus.
Les services bien connus sont désignés par l'IANA et sont mis

8-protocole_UDP.odt 6
 Informatique et Science du Numérique
en œuvre par des applications qui s'exécutent avec des droits privilégiés
(root sur une machine Unix)
2. Le segment [1024,49151] est celui des services enregistrés.
Ils sont énumérés par l'IANA et peuvent être employés par des processus
ayant des droits ordinaires.
Par exemple :
Nom Port Proto Commentaire
bpcd 13782 tcp VERITAS NetBackup
bpcd 13782 udp VERITAS NetBackup
3. Le segment [49152, 65535] est celui des attributions
dynamiques et des services privés.
Note : la présence de ce pseudo en-tête, interaction entre les deux couches IP et UDP, est une des raisons qui font
que le modèle TCP/IP ne s'applique pas parfaitement au modèle OSI.
8. Exercices
5.1. Exercice 1 : décoder la trame Ethernet suivante.

Exercice 2 : Analyse de trame MAC (Ethernet)

Les trames MAC transportent en partie donnée diverses informations qui peuvent elles même être des trames d’un
autre protocole (c’est l’encapsulation de protocoles). Étant donné le format de trame de différents protocoles (ici
ARP), on veut analyser le contenu d’une trame MAC.
Décoder les trames MAC Ethernet suivantes :
Trame 1
FF FF FF FF FF FF 08 00 20 02 45 9E 08 06 00 01 08 00 06 04 00
01 08 00 20 02 45 9E 81 68 FE 06 00 00 00 00 00 00 81 68 FE 05
Trame 2
08 00 20 02 45 9E 08 00 20 07 0B 94 08 06 00 01 08 00 06 04 00
02 08 00 20 07 0B 94 81 68 FE 05 08 00 20 02 45 9E 81 68 FE 06

8-protocole_UDP.odt 7