Dans ce TP vous allez utiliser le logiciel Filius pour visualiser les différents protocoles utilisés lors d'un échange entre deux machines.
Dans cette première partie, nous allons travailler avec le réseau suivant :
Fig. 1 - Réseau pour observer les premières trames
Téléchargement
Commencez par télécharger le fichier arp.fls en question et ouvrez-le avec Filius.
L'objectif ici est de voir comment observer les trames échangées entre machines, les protocoles mis en jeu au niveau des différentes couches du modèle Internet (Filius se base sur ce modèle et non le modèle OSI).
L'ordinateur 192.168.0.1, d'adresse MAC 06:5C:09:34:6E:32 a déjà le logiciel Ligne de commandes installé.
💻 Question 1 : Passez en mode simulation (flèche verte) puis ouvrez le terminal sur l'ordinateur 192.168.0.1. Exécutez la commande arp -a pour voir la table ARP qui contient les correspondances entre @IP et @MAC. Vous devez voir que cette table est vide pour le moment (seule l'adresse de diffusion est présente).
💻 Question 2 : Laissez le logiciel "Ligne de commandes" ouvert et cliquez droit sur l'ordinateur 192.168.0.1 puis cliquez sur "Afficher les échanges de données ..." qui ouvre une fenêtre dans laquelle on va voir les différentes trames échangées par cet ordinateur. Faites ensuite un ping vers 192.168.0.3 da. Cette commande déclenche l'échange de plusieurs trames comme sur la capture ci-dessous :
On va s'intéresser aux deux premiers messages échangés.
192.168.0.3 ? »Le premier paquet échangé via le protocole ARP, s'appelle la requête ARP. En cliquant sur ce paquet on obtient le détail :
Analyse :
192.168.0.1 à 192.168.0.3 (c'est notre ping) via le protocole ARP. Ces données ont été encapsulées par la couche "Réseau"192.168.0.3 de lui renvoyer son @MAC.FF:FF:FF:FF:FF:FF.Vous pouvez observez que les deux autres machines du réseau ont reçu cette requête ARP (clic droit sur celles-ci puis clic sur "Afficher les échanges de données") mais seule
192.168.0.3, qui s'est reconnue a repondu.
Le second message s'appelle la reponse ARP : la machine cherchée 192.168.0.3 a renvoyé son @MAC à 192.168.0.1 pour lui indiquer que c'est elle qu'elle veut contacter :
✍️ Question 3 : Analysez la réponse ARP pour répondre aux questions suivantes :
192.168.0.3 connait-il l'@MAC de 192.168.0.1 ?À partir de maintenant, 192.168.0.1 connaît l'@MAC de 192.168.0.3 et l'a enregistré dans sa table ARP qui n'est plus vide (jusqu'à effacement de la mémoire cache) :
Vous pouvez vérifier qu'en faisant le même ping que précédemment,
192.168.0.1n'a plus besoin d'envoyer de requête ARP à tout le réseau puisqu'il regarde d'abord dans sa table ARP et se rend compte qu'il connaît l'@MAC de192.168.0.3. Cela permet évidemment un gain en temps, même si cela reste minime, et évite d'encombrer inutilement le réseau.
Par ailleurs, en cliquant sur le switch, vous pouvez rendre compte que les échanges entre nos deux machines, qui sont passés par le switch, lui ont permi d'enregistrer dans sa table les adresses MAC de 192.168.0.1 et 192.168.0.3 en les associant au bon port (cette table était vide au départ).
En effet, un switch est un équipement qui se situe au niveau "Réseau" du modèle Internet et ne travaille donc pas avec les @IP mais avec les @MAC.
Vous avez du constater que lors d'un ping, 4 messages sont envoyés au destinataire et on est en attente des 4 réponses (pong, en guise d'accusé de réception).
Les trames suivantes échangées par 192.168.0.1 correspondent à ce jeu de ping pong entre les deux machines. C'est le protocole ICMP qui se charge de cela, comme vous pouvez le voir avec Filius.
💻✍️ Question 4 : Cliquez sur la troisième trame (le premier "ping") pour en voir le détail et complétez le schéma ci-dessous avec les bonnes informations pour chaque couche.
💻✍️ Question 5 : Cliquez sur la quatrième trame (le premier "pong") pour en voir le détail et complétez le schéma ci-dessous avec les bonnes informations pour chaque couche.
💻✍️ Question 6 : Pour différencier les différents "ping", un numéro de séquence est attribué. Vérifiez que ce numéro est bien itéré pour chaque "ping" et que le "pong" contient ce numéro également. Pourquoi à votre avis ?
On va maintenant analyser les trames correspondants à une requête HTTP vers un serveur Web.
Pour cela, on va repartir du réseau construit au cours du TP du chapitre 3 sur la simulation d'un réseau :
Fig. 2 - Réseau pour les requêtes HTTP
Téléchargement
Commencez par télécharger le fichier tp_protocoles.fls en question et ouvrez-le avec Filius.
On va mettre en place un serveur dans le réseau R2 (celui d'adresse 192.168.1.0). C'est la machine 192.168.1.3 qui jouera le rôle de serveur.
💻 Question 7 : Passez en mode conception (flèche verte) et installez sur 192.168.1.3 les logiciels "Serveur web", "Explorateur de fichiers" et "Éditeur de textes".
En ouvrant l'explorateur de fichiers on peut accéder aux fichiers présents sur le serveur : c'est le répertoire root/webserver qui contient les pages web hébergées par le serveur (ainsi que tous les autres fichiers). En particulier, index.html est celui qui sera envoyé au client qui effectue une requête à la racine du serveur.
💻 Question 8 : Lancez l'éditeur de texte puis ouvrez le fichier index.html pour en voir le contenu (il faut double-cliquer sur le fichier puis cliquer sur le bouton "Ouvrir"). Modifiez le contenu du body avec le code que vous souhaitez (un exemple ci-dessous) et enregistrer les modifications.
💻 Question 9 : Ouvrez enfin le logiciel "Serveur web" et cliquez sur "Démarrer" pour lancer le serveur qui est désormais prêt à recevoir les requêtes des clients. Vous devriez obtenir l'écran ci-dessous si tout s'est bien passé.
C'est l'ordinateur 192.168.0.1 qui jouera le rôle de client (cela pourrait être n'importe quel ordinateur en fait).
💻 Question 10 : En mode conception (flèche verte), cliquez droit sur 192.168.0.1 et cliquez sur "Afficher les échanges de données". Vous devriez voir apparaître différentes trames utilisant le protocole RIP (programme de Terminale). On voit bien en cliquant sur l'une d'elles les différentes couches du modèle "Internet" comme ci-dessous. Quelle machine a envoyé ces requêtes ? À qui ? Expliquez.
Un routeur envoie régulièrement à toutes les machines de son réseau un message pour signaler sa présence, et que l'on peut passer par lui (passerelle) pour contacter des machines en dehors du réseau. Cela correspond aux différents messages RIP.
Vous pouvez effacer ces requêtes en cliquant droit puis "Vider les tables" (d'autres apparaîtront au fur et à mesure mais il y aura moins à défiler pour voir les trames qui nous intéressent par la suite)
💻 Question 11 : Tout en laissant la fenêtre "Échanges de données", installez sur 192.168.0.1 le "Navigateur web" puis ouvrez-le et saisissez l'@IP du serveur dans la barre d'URL, soit 192.168.1.3. La page index.html du serveur écrite à la question 8 doit s'afficher dans le navigateur.
Dans la fenêtre "Échanges de données", vous devez obtenir quelque chose de similaire à la capture d'écran ci-dessous.
Dans la suite on ne s'intéresse qu'aux trames échangées suite à la validation de l'URL dans le navigateur c'est-à-dire à toutes sauf celles utilisant le protocole RIP :
✍️ Question 12 : En utilisant ce qui a été vu dans la partie précédente, expliquez le rôle des deux premières trames utilisant le protocole ARP. Soyez précis : qui envoie ? à qui ? dans quel but ?
Lors d'un échange entre un client et un serveur via la protocole TCP, il est nécessaire d'établir une session TCP entre les deux machines. Cela fonctionne en trois phases :
On évoque les première et dernière phases tout de suite avant de se concentrer sur le transfert de données pour terminer.
L'établissement de la connexion se fait en trois temps (SYN, SYN+ACK, ACK):
Fig. 3 - Établissement d'une connexion TCP en 3 temps
Crédit : Adaptation personnelle d'une image de Snubcube, CC BY-SA 3.0, via Wikimedia Commons.
Pendant la phase d'établissement de la connexion, des paramètres comme le numéro de séquence sont initialisés afin d'assurer la transmission fiable (sans perte et dans l'ordre) des données.
✍️ Question 13 : Complétez le schéma ci-dessous correspondant à la première trame (la demande de synchronisation). Expliquez pourquoi l'@MAC de destination n'est pas celle du serveur.
Les deux autres trames suivent le même principe comme vous pouvez le constatez par vous-même.
Le client envoie la trame à son routeur, qui désencapsule la couche "Internet" pour lire l'@IP de destination (celle du serveur). Il constate dans notre cas que le serveur est dans le même réseau que son interface
192.168.1.254, diminue la valeur TTL (Time To Live) d'une unité (elle passe de 64 à 63) et envoie la trame au serveur, en ayant éventuellement au préalable demandé son @MAC via le protocole ARP. Vous pouvez d'ailleurs observer que le TTL vaut 63 lorsqu'il arrive au serveur en affichant les échanges de données de ce dernier.Si le serveur n'était pas dans le même réseau que le routeur, ce dernier aurait passé la trame à un routeur voisin (selon un protocole étudié en Terminale). Chaque routeur ainsi traversé, décremente la valeur TTL d'une unité et si cette valeur devient égale à 0, le paquet est détruit pour éviter l'encombrement des réseaux avec des paquets qui ne trouvent pas leur destination.
La fin de la connexion se fait, elle, en quatre temps avec des demandes de fin de connexion (FIN) et accusés de réception (ACK) de part et d'autre.
Fig. 4 - Fin d'une connexion TCP en 4 temps
Entre l'établissement et la rupture de la session TCP, a lieu la requête et la réponse HTTP comme on l'a vu dans le chapitre Dialogue client-serveur sur le Web du thème n°3.
On va terminer en analysant les trames échangées entre le client et le serveur suite à la demande de la page Web par le client.
💻✍️ Question 14 : Identifiez la requête HTTP ainsi que la réponse HTTP dans la série de trames échangées. Quel est le rôle de deux autres trames (protocole TCP) de la phase de transfert des données ?
✍️ Question 15 : Complétez le schéma suivant avec les informations de la requête HTTP. En particulier, vous indentifierez la ligne de commande et les en-têtes de la requête HTTP.
✍️ Question 16 : Complétez le schéma suivant avec les informations de la réponse HTTP. En particulier, vous indentifierez la ligne de statut, les en-têtes et le corps de la réponse HTTP.
Vous avez constaté que le client a contacté le serveur en utilisant son @IP (dans la barre d'URL du navigateur). En réalité, on utilise le nom de domaine et c'est un serveur DNS qui permet d'associer au nom de domaine l'adresse IP du serveur correspondant.
Pour mettre en place un tel serveur DNS et comprendre le fonctionnement, vous pouvez regarder la vidéo suivante (de David Roche) qui présente la manière de procéder. Libre à vous de la mettre en oeuvre avec Filius et d'observer les différentes trames échangées.
Source : https://youtu.be/EZp_TLGVyv0.
Références :
Germain Becker, Lycée Emmanuel Mounier, Angers.
Sous licence CC BY-SA 4.0.
Voir en ligne : info-mounier.fr/premiere_nsi/archi_os/tp-protocoles
