• 15 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

Ce cours est en vidéo.

Ce cours existe en livre papier.

Vous pouvez obtenir un certificat de réussite à l'issue de ce cours.

J'ai tout compris !

Mis à jour le 28/02/2018

On récapitule tout de A à Z !

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

‌Ça y est, vous avez toutes les connaissances réseau suffisantes pour comprendre comment fonctionne Internet, mais avant d'aller plus loin nous allons réviser ce que nous avons vu avec un exercice complet qui va utiliser toutes les connaissances que nous avons acquises jusqu'à maintenant.

Si vous savez faire cet exercice de A à Z, bravo ! Vous pouvez considérer que vous avez de très bonnes bases en réseau.
Ceci dit, il est très rare de faire tout de A à Z sans oublier une petite étape. :p

C'est parti pour un premier chapitre court de présentation de l'exercice !

Présentation de l'exemple et principes de résolution

Nous allons maintenant essayer de suivre une connexion de A à Z avec toutes les connaissances que nous avons.

Voici le schéma réseau qui va représenter notre connexion :

Schéma réseau de la connexion
Schéma réseau de la connexion

Nous allons donc détailler une connexion web que vous pourriez faire, de votre machine sur votre réseau chez vous, derrière votre box, vers l'adresse 88.191.135.63.

Comment allons-nous procéder ?

Effectivement, si je vous demande, comme ça, par où commencer, cela peut vous paraître complexe, mais nous allons déjà identifier les étapes de la connexion.

Au départ, notre machine

Dans un premier temps, la connexion va partir de l'application qui tourne sur notre machine, c'est-à-dire dans notre cas du navigateur Firefox.
Puis il va y avoir beaucoup d'étapes avant de réussir à former la trame à envoyer sur le réseau. Pour comprendre chacune de ces étapes, nous allons nous appuyer sur notre support principal de compréhension des réseaux, j'ai nommé... le modèle OSI !

Comme je vous l'avais dit et comme vous pouvez le concevoir, le modèle OSI permet de comprendre en profondeur le fonctionnement des réseaux, nous allons donc l'utiliser pour détailler le parcours de nos informations. Et notamment pour l'envoi d'une information sur le réseau.

Envoi dans le modèle OSI
Envoi dans le modèle OSI

Nous voyons bien ici que nous allons devoir détailler les informations relatives à chacune des couches avant de pouvoir envoyer notre trame sur le réseau, mais nous savons maintenant dans quel ordre le faire.

Envoi de la trame sur le réseau

Nous allons ensuite voir ce qu'il advient de notre trame sur le réseau, quels matériels sont rencontrés, quels protocoles sont utilisés, etc.

D'ailleurs, nous allons encore nous servir du modèle OSI chaque fois qu'un matériel réseau est rencontré. Cependant, cette fois, le parcours du modèle OSI se fera dans le sens inverse, du bas vers le haut puisque la trame provient du réseau et va vers l'application.

Nous verrons comment la trame parcourt le réseau et ce qui est modifié à chaque passage par un équipement.

Réception de la trame par la machine destinataire et réponse

De la même façon que précédemment, nous allons cette fois remonter les couches du modèle OSI jusqu'à la couche 7 applicative. Nous verrons comment les informations sont reçues et aiguillées entre les couches et comment l'application reçoit les informations de départ et peut les traiter.

Il est temps de passer au concret, vous pouvez commencer à réfléchir à chaque étape du processus.

Au cœur de notre machine

Nous allons voir comment nous allons passer d'une requête applicative de notre navigateur, à une trame qui est envoyée sur le réseau. Tout cela se passe au niveau du système d'exploitation de notre machine, et plus précisément dans ce que l'on appelle la pile TCP/IP.

De l'application au réseau

Nous sommes donc devant notre clavier et entrons dans notre navigateur préféré l'adresse du site que nous voulons atteindre : 88.191.135.63.

On entre la demande dans le navigateur
On entre la demande dans le navigateur

Nous allons maintenant voir tout ce qui se passe au niveau de notre machine à partir du moment où vous tapez sur la touche entrée.

En couche 7

Nous sommes au niveau de votre navigateur web, Firefox chez moi, et celui-ci souhaite envoyer une requête sur le réseau vers le serveur d'adresse IP 88.191.135.63.
Firefox va utiliser le protocole applicatif HTTP pour envoyer une requête web. Le protocole HTTP fonctionnant sur TCP, Firefox va envoyer sa requête au protocole TCP de couche 4.
Plus exactement, et pour les connaisseurs du web, voici à peu de chose près la requête applicative qui est envoyée :

GET http://88.191.135.63 HTTP/1.0
HOST: 88.191.135.63\r\n
Accept : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20100101 Firefox/19.0

Ce sont donc ces informations qui vont être envoyées au serveur web 88.191.135.63.

Pour l'instant, voici où nous en sommes de l'envoi de notre trame finale:

GET http://88.191.135.63...

Données applicatives

En couche 4

La couche 4 reçoit les informations précédentes et voit qu'une requête doit être envoyée au serveur 88.191.135.63.

Donc avant de pouvoir envoyer nos données applicatives, nous allons devoir envoyer un segment TCP qui demande à la machine 88.191.135.63 si elle veut bien ouvrir une connexion avec nous.
Cette requête ne sera donc qu'une demande d'ouverture de connexion SYN qui ne contient pas de données applicatives.
Ce premier segment TCP envoyé ne contiendra donc pas de données.

Il va cependant falloir former l'en-tête TCP.
Pour former l'en-tête, nous avons notamment besoin des ports TCP utilisés.
Le port destination est donné par Firefox, c'est le port 80 qui est utilisé par défaut pour le web.
Le port source est un port choisi aléatoirement au-dessus de 1024, la pile TCP/IP va donc nous donner un port aléatoire, par exemple 1337. :p
On y ajoute les flags, avec notamment le flag SYN qui est positionné, vu qu'il s'agit de l'initialisation d'une connexion.

Notre future trame continue de se former avec pour l'instant le segment TCP:

1337

80

???

flags

???

checksum

Segment TCP
On voit bien ici que les données applicatives ne sont pas dans ce segment, elles ne seront envoyées que quand la connexion TCP sera établie.

Maintenant que le segment TCP est prêt, on peut l'envoyer à la couche 3, qui sera ici le langage quasi universel utilisé, IP.

En couche 3

La couche 3 récupère donc les informations de couche 4 ainsi que l'adresse IP destination.
Comme la couche 3 est en charge du dialogue entre réseaux et notamment de l'aiguillage des paquets, elle va devoir savoir à quel routeur envoyer les informations. Pour cela, elle va voir sa table de routage, qui pour notre exemple est :

Table de routage

 

Réseau à joindre

passerelle

192.168.0.0/24

192.168.0.1

0.0.0.0/0

192.168.0.254

Pour aller vers 88.191.135.63, la passerelle à utiliser est 192.168.0.254.

La couche 3 sait donc maintenant à qui adresser la future trame, elle connaît aussi les adresses IP source et destination ; elle va pouvoir former son datagramme et l'envoyer à la couche 2...

???

192.168.0.1 (source)

88.191.135.63 (destination)

1337

80

???

flags

???

checksum

Datagramme IP, contenant le segment TCP
Mais avant, elle va faire un petit travail supplémentaire pour faciliter le travail de la couche 2, elle va s'occuper de la requête ARP pour indiquer à la couche 2 l'adresse MAC à joindre.

Elle va donc en premier lieu aller voir dans la table ARP si l'adresse MAC du routeur 192.168.0.254 n'est pas déjà présente.

  • Si elle est présente, c'est parfait, on connaît maintenant l'adresse MAC.

  • Si elle n'est pas présente, un broadcast ARP va être envoyé sur le réseau pour demander l'adresse MAC de 192.168.0.254. Le routeur va nous répondre et nous connaîtrons son adresse MAC que nous allons inscrire aussi dans la table ARP.

Ainsi, la couche 3 va pouvoir envoyer à la couche 2 le datagramme ainsi que l'adresse MAC de la prochaine machine à joindre.

En couche 2

Notre dernière étape avant l'envoi sur le réseau !

La couche 2 possède maintenant tous les éléments pour envoyer la trame sur le réseau, elle va donc pouvoir la former:

@MAC 192.168.0.254

@MAC 192.168.0.1

proto 3 IP

???

192.168.0.1

88.191.135.63

1337

80

???

flags

???

checksum

CRC

Trame Ethernet qui contient le Datagramme IP, contenant le segment TCP

La couche 2 va pouvoir alors envoyer cette trame sous forme de 0 et de 1 sur le réseau !

Allez, pour le plaisir je vous donne un aperçu de ce que cela peut donner en hexadécimal (en binaire ce serait un peu long...)

00 50 56 b0 11 46 00 26  bb 16 21 84 08 00 45 00 
00 40 97 ea 40 00 40 06  be 74 0a 08 3f e9 0a 04 
90 64 ed d8 1f 90 d0 78  41 24 00 00 00 00 b0 02 
ff ff 5e 92 00 00 02 04  05 b4 01 03 03 04 01 01 
08 0a 4a 69 8a a3 00 00  00 00 04 02 00 00

Les plus aventureux pourront s'amuser à décrypter le contenu ! C'est une vraie trame Ethernet.
En plus, comme je suis sympa, je vous donne un aperçu du contenu réel pour voir si vous avez eu juste :

Contenu de la trame Ethernet
Contenu de la trame Ethernet

Voilà donc notre trame partie sur le réseau (à la vitesse de la lumière, si si, pour de vrai !)
Nous allons maintenant voir quel est le premier équipement qu'elle va rencontrer sur le réseau et comment il va la recevoir.

Sur le réseau

Un long voyage réseau

Enfin, long pour nous qui étudions tout ce parcours étape par étape, car je vous rappelle que dans la réalité, tout cela se fait en quelques millisecondes... :o

Première rencontre sur le réseau

D'après vous, quel est le prochain matériel rencontré par notre trame ?
Je vous rappelle le schéma :

Schéma réseau de la connexion
Schéma réseau de la connexion

Et le prochain matériel rencontré est... un switch !

Nous ne le voyons pas sur le schéma, car il s'agit d'un schéma logique de couche 3, mais il y a bien un switch entre nous et la box.

Le switch reçoit donc notre trame, mais comme c'est un équipement de couche 2, il ne comprend que le protocole Ethernet et ne peut lire que les informations de l'en-tête Ethernet.

@MAC 192.168.0.254

@MAC 192.168.0.1

proto 3 IP

???

CRC

Trame Ethernet qui contient... des choses
Le switch va donc pouvoir lire la trame et notamment l'adresse MAC source et l'adresse MAC destination.

Grâce à l'adresse MAC source, il va pouvoir mettre à jour sa table CAM en indiquant sur quelle prise est branchée la machine 192.168.0.1 (ou simplement remettre le TTL de cette association au maximum).
Ensuite, grâce à l'adresse MAC destination, il va pouvoir identifier la prise sur laquelle il doit renvoyer la trame.
Il va donc récupérer toute la trame, l'analyser et la réémettre sur la prise adéquate.

Et notre trame est repartie sur le réseau !

En route pour le routeur

Notre trame arrive ensuite au routeur.
Le routeur va lire la couche 2...

En réseau, qui peut le plus peut le moins !
Un équipement de couche 3 saura donc parler tous les protocoles des couches inférieures. Sinon, il ne pourrait pas renvoyer les paquets sur le réseau en passant par la couche 2 !
D'ailleurs, l'un des éléments les plus évolués du réseau est... votre machine, car vu qu'elle est capable de parler au niveau applicatif (couche 7), elle connaît tous les protocoles des couches inférieures.

Le routeur lit donc la trame et l'en-tête de couche 2.
Il voit que l'adresse MAC destination est la sienne ! Il va donc pouvoir lire le reste du contenu et envoyer le datagramme à la couche 3.
Il lit notamment le CRC en fin de trame et vérifie qu'il n'y a pas eu d'erreur de transmission pendant le trajet.
Si tout va bien, il remonte le datagramme à la couche 3.

???

192.168.0.1 (source)

88.191.135.63 (destination)

1337

80

???

flags

???

checksum

Datagramme IP, contenant le segment TCP
La couche 3 lit le contenu de l'en-tête et voit que l'adresse IP de destination n'est pas la sienne (ce qui est bien normal pour un routeur qui ne cesse d'aiguiller des paquets qui ne sont pas pour lui)

Il doit donc maintenant aiguiller ce paquet vers son réseau de destination. Pour cela, vous le savez maintenant, il va voir sa table de routage:

Table de routage

 

Réseau à joindre

passerelle

192.168.0.0/24

192.168.0.254

82.238.22.0/24

82.238.22.47

0.0.0.0/0

Prochain routeur Internet

Sa route par défaut lui dit d'envoyer le paquet vers Internet.

Oui, comme moi, vous avez remarqué un point très important. ;)

Nous allons passer d'un réseau privé 192.168.0.0/24 à un réseau public 82.238.22.0/24 !
Et quand on passe d'un réseau privé à un réseau public, il faut faire de la NAT.

Notre routeur a donc besoin de faire de la NAT, et pour cela, il va devoir aller lire les informations de couche 4. Ça tombe bien, elles sont contenues dans l'en-tête TCP qui est contenu dans le datagramme !
Le routeur récupère donc les ports source et destination, 1337 et 80.

Il va choisir à son tour un port source pour l'envoi du paquet et va noter tout cela dans la table de NAT dynamique :

Table NAT

 

@IP SRC, @IP DST, port SRC, port DST

@IP SRC, @IP DST, port SRC, port DST

192.168.0.1, 88.191.135.63, 1337, 80

82.238.22.47, 88.191.135.63, 22385, 80

Il va donc modifier les informations de couche 4 et de couche 3 avant de renvoyer la trame sur le réseau.
Avant cela, il fait une requête ARP pour obtenir l'adresse MAC du prochain routeur.
Il peut alors envoyer le nouveau datagramme à la couche 2 :

???

82.238.22.47 (source)

88.191.135.63 (destination)

22385

80

???

flags

???

checksum

Datagramme IP modifié pour la NAT segment TCP
La couche 2 reçoit le datagramme ainsi que l'adresse MAC destination et n'a plus qu'à former la nouvelle trame à envoyer sur le réseau

@MAC prochain routeur

@MAC 82.238.22.47

proto 3 IP

???

82.238.22.47

88.191.135.63

22385

80

???

flags

???

checksum

CRC

Trame Ethernet qui contient le Datagramme IP, contenant le segment TCP

Nous avons vu qu'à chaque passage par un équipement, nous avons remonté le modèle OSI jusqu'au niveau de l'équipement. Le switch a lu les informations jusqu'à la couche 2, le routeur les a lues jusqu'à la couche 4 (car il devait faire de la NAT) et ainsi de suite.

On pourrait donc schématiser le parcours sur le réseau en fonction du modèle OSI de la manière suivante :

Passage sur le réseau selon le modèle OSI
Passage sur le réseau selon le modèle OSI

Nous voyons une fois de plus l'importance du modèle OSI, et aussi l'importance de sa compréhension.

Par ailleurs, nous avons vu que lors du passage par notre box, beaucoup d'informations avaient été modifiées dans différentes couches.
On peut en déduire les règles suivantes :

  • quand on passe d'un réseau à un autre, les adresses MAC changent dans l'en-tête Ethernet (couche 2) ;

  • quand on passe d'un réseau à un autre, rien ne change dans les en-têtes de couches 3 et 4, IP et TCP, sauf s'il y a de la NAT ;

  • dans le cas de la NAT, on change aussi les adresses IP source et ports source.

Voici donc deux remarques importantes à garder à l'esprit pour la compréhension du réseau.

Mais il est temps de retourner à nos moutons, car notre trame va continuer ainsi à se balader de routeur en switch et de switch en routeur, jusqu'à atteindre sa destination finale.

Destination finale que nous allons étudier sur le champ ! :p

Réception par la machine destinataire

Après avoir cheminé sur Internet, notre trame arrive enfin à sa destination.

Réception des informations

Comme vous pouvez vous en douter, nous allons une fois encore parcourir le modèle OSI, et cette fois ce sera en remontant les couches vers la couche applicative.

Réception de la trame en couche 2

Nous sommes donc au niveau du serveur d'adresse IP 88.191.135.63. Il reçoit la trame suivante:

@MAC 88.191.135.63

@MAC 88.191.135.254

proto 3 IP

???

CRC

Trame Ethernet
L'adresse MAC destination est bien celle de notre machine, la couche 2 sait donc maintenant qu'elle va devoir envoyer le datagramme contenu dans la trame à la couche 3. Elle vérifie donc que la trame a été transmise correctement, grâce au CRC, et elle peut alors envoyer le datagramme au protocole de couche 3 indiqué dans l'en-tête, à savoir IP !

Réception du datagramme en couche 3

La couche 3, et plus précisément le protocole IP, reçoit donc le datagramme suivant:

???

82.238.22.47 (source)

88.191.135.63 (destination)

???

Datagramme IP
L'adresse IP destination est aussi la nôtre, il va donc falloir envoyer le segment TCP contenu au protocole de couche 4 indiqué qui est TCP.
La couche 3 finit donc ses traitements et envoie le segment au protocole TCP.

Réception du segment en couche 4

Le protocole TCP reçoit le segment suivant:

22385

80

???

flags/SYN

???

checksum

Segment TCP
Si l'on regarde le contenu des flags, on voit que seul le flag SYN est positionné, il s'agit donc bien d'une demande de connexion.
La couche TCP va par ailleurs vérifier que le port destination demandé est bien ouvert et prêt à recevoir des connexions.
Il y a bien un service en écoute sur le port 80 de la machine, le protocole TCP peut donc répondre favorablement à la demande de connexion et renvoyer un segment TCP contenant les flags SYN et ACK.

Et on est repartis pour un tour en sens inverse !
Cette fois on parcourt tout ce que l'on vient de faire, mais de la machine 88.191.135.63 vers la machine 82.238.22.47, puis vers 192.168.0.1 après la NAT.

La machine 192.168.0.1 recevant le segment TCP avec les flags SYN et ACK va pouvoir finaliser le three way handshake en envoyant un segment TCP avec le flag ACK, qui va établir la connexion TCP.

Une fois la connexion établie, la machine 192.168.0.1 va ENFIN pouvoir faire sa requête web !
Pour information, voici la trame envoyée alors :

@MAC 192.168.0.254

@MAC 192.168.0.1

proto 3 IP

???

192.168.0.1

88.191.135.63

1337

80

???

flags

???

checksum

GET http://88.191.135.63...

CRC

Trame Ethernet qui contient le Datagramme IP, contenant le segment TCP qui contient les données applicatives !
Ouf, eh bien c'est pas trop tôt !

Nous venons donc d'étudier une connexion TCP plus ou moins en détail. Cela devrait maintenant vous permettre de mieux comprendre comment vos machines communiquent sur Internet.
Mais attention, il y a plusieurs points à garder à l'esprit :

  • nous n'avons vu qu'une version très simplifiée de ce qui se passe réellement ;

  • tout cela se passe en quelques millisecondes ;

  • chaque connexion peut utiliser un chemin différent qui la fera passer par un plus ou moins grand nombre de routeurs, mais cela ne change que très peu le temps de transit.

Pourquoi est-ce une version simplifiée ? Ça semble complexe quand même…

Oui, c'est déjà bien complexe, mais ce n'est pas encore représentatif de la réalité. Nous n'avons pas parlé de requête DNS, que nous allons voir dans le chapitre suivant. Nous n'avons pas non plus parlé de proxy qui peut intervenir dans certains cas.

Mais on n'a pas vu le proxy, c'est quoi ?

Les intérêts de mettre en place un proxy peuvent être divers :

  • une entreprise veut pouvoir centraliser les requêtes d'une application donnée, comme le web, pour voir tout ce qui sort de son réseau ;

  • un proxy peut aussi servir de cache, c'est-à-dire qu'il va enregistrer les pages web qu'il a visitées, et ainsi les renvoyer lors d'une demande identique, sans avoir à refaire une requête ;

  • un proxy peut aussi filtrer les requêtes en fonction de critères, comme le type des sites web demandés ;

  • enfin, on entend parfois parler de proxy "anonyme" pour faire en sorte que ce soit l'adresse du proxy qui soit vue et non la nôtre.

Nous comprenons maintenant comment une information circule sur le réseau de la machine émettrice à la destination. Super, il s'agissait de l'objectif majeur du cours !

Nous allons maintenant faire un peu de pratique, notamment en mettant en œuvre des services qui sont nécessaires au bon fonctionnement des réseaux.

  • Vous savez maintenant ce qu'est une application et ce que sont un client et un serveur.

  • Les protocoles de couche 4 utilisés sont TCP et UDP.

  • L'adressage utilisé pour différencier les applications sur une machine est le port.

  • La NAT et le port forwarding permettent de relier des réseaux privés à Internet.

  • Vous avez pu voir le parcours complet d'une information sur Internet.

Il est temps maintenant d'aller plus loin dans le réseau et de comprendre pourquoi nous avons besoin de quelques services supplémentaires pour faire fonctionner tout ce que nous avons vu.

Nous venons donc de voir la couche 4 et avons fait un petit récapitulatif de ce que nous avons vu depuis le début.

Cette partie est maintenant terminée. N'oubliez pas de faire vos exercices avant de passer à la partie suivante. Vous trouverez les liens des exercices (quiz et/ou activité) dans le plan principal du cours ICI. À vous de jouer!

Exemple de certificat de réussite
Exemple de certificat de réussite