Lorsque vous rencontrez une personne nous suivons naturellement un ensemble de protocoles :

• On commence par initier la communication par un allô/bonjour ou une poignée de main,

• ensuite on s'identifie,

• puis on échange des informations dans un codage adapté (le français),

• on vérifie que l'on s'est compris (oui, ok, j'ai compris),

• et enfin on se quitte.

En informatique ils existent bon nombre de protocoles : HTTP, IP, TCP, UDP,...

Pour récupérer sur son ordinateur un mail stocké sur un serveur gérant sa messagerie, on utilise un protocole nommée POP pour Post Office Protocol (=protocole de bureau de poste).

La couche d’application inclut tous les protocoles de niveau supérieur tels que :

• DNS (système de nommage de domaine),

• HTTP (protocole de transfert hypertexte),

• SSH (protocole pour sécuriser la communication grâce à un cryptage),

• FTP (protocole de transfert de fichier),

• SNMP (protocole de gestion de réseau simple) ,

• SMTP (protocole de transfert de courrier simple),

• DHCP (protocole de configuration d’hôte dynamique),

• RDP (protocole de bureau à distance),

• IMAP (protocole pour accéder à ses courriers électroniques),

• ...

Considérons un ordinateur dont le navigateur veut accéder au contenu d'une page Web stocké dans un serveur distant.
Pour cela, le navigateur du client va envoyer une requête HTTP au serveur. Une telle requête est un message. Nous verrons dans le chapitre ARSE4 cette requête plus précisément.
Pour simplifier l'exemple, on suppose que :

• le navigateur connaît l'IP du serveur : le protocole DNS (Domain Name System) n'est pas utilisé.

• l'acheminement de l'ordinateur client au serveur se fait en passant par deux routeurs : routeur 1 et routeur 2.

Les données de la requête vont suivre les modifications et cheminement suivant :

1. Au niveau de l'ordinateur client, il y a une encapsulation :

   1. Le navigateur prépare la requête : couche Application.

   2. Cette requête est encapsulée dans un datagramme (ou plusieurs) par le protocole TCP : couche Transport.

   3. Ces datagrammes sont encapsulés avec des adresses IP dans des paquets pour pouvoir circuler dans le réseau : couche Internet.

   4. Ces paquets sont encapsulés avec des adresses physiques MAC dans des trames : couche Réseau.

   

   Une fois encapsulée dans une trame, le tout peut circuler et être orienté dans les réseaux.
   La trame est transmise, par une succession de bits, au routeur R1.

2. Au niveau du routeur R1 :

   1. Décapsulation pour lire une partie du contenu des en-têtes :

      Lorsque la trame arrive au routeur 1, celui-ci a besoin de connaître l'expéditeur et le destinataire.
      Pour cela, il va décapsuler :

      • les trames pour récupérer les adresses physiques MAC,

      • les paquets pour récupérer les adresses logiques IP.

      

      Avec ces adresses (et sa table de routage cf. cours de Terminale dessus), le routeur va pouvoir acheminer les données à l'intermédiaire suivant : le routeur 2.

      Cependant, pour pouvoir être renvoyées sur le réseau, les données doivent être encapsulées sous forme d'une trame. D'où :

   2. Encapsulation pour le renvoi sur le réseau :

      Comme il y a eu deux niveaux de décapsulation, il faut encapsuler deux fois pour transformer les données en paquet puis trame.

      

   Le routeur 1 envoie la trame vers le routeur 2.

3. Au niveau du routeur R2 :

   Le même besoin des adresse MAC et IP conduit au même travail de décapsulation et d'encapsulation avant que ce routeur n'envoie la trame réencapsulée vers le serveur destinataire.

   

4. Au niveau du serveur :

   Le serveur doit récupérer la requête HTTP qu'il vient de recevoir encapsulée dans une trame.
   Pour cela, il doit enlever les différentes en-têtes en décapsulant :

   1. d'abord la trame pour extraire le paquet IP,

   2. ensuite le paquet IP pour extraire le datagramme,

   3. enfin le datagramme pour extraire les données correspondant à la requête HTTP.

   

   Une fois la requête reçue et extraite, le serveur peut traiter la demande.
   Sa réponse contenant le code de la page Web suivra lui aussi une succession d'encapsulations et de décapsulations à travers son acheminement sur le réseau.

Tooma veut envoyer à Pascual un fichier. La donnée à envoyer est alors tronçonnée et encapsulée en 4 paquets : C1, C2, C3 , C4

Pascual va recevoir les paquets, il faudra alors reconstituer la donnée et ne pas mélanger les paquets.

Nous allons explorer dans cet exemple deux tentatives de protocole pour arriver finalement au protocole du bit alterné.

1. Ce qu'on pourrait imaginer mais qui n'arrive pas.

   Imaginez que l'on soit capable de dire qu'un paquet met un temps $t$ pour arriver jusqu'à Pascual. Il suffirait alors d'attendre suffisamment longtemps entre chaque envoi de paquets pour être sûr que chaque capsule a été envoyée dans le bon ordre.

   

   Oui mais voila, il est impossible d'être certain du temps de parcours du paquet. Par conséquent cette solution n'est pas satisfaisante.

2. Vers une première solution

   L'idée ici est que Tooma doit attendre un accusé de réception ( ACK=acknowledgement) pour envoyer un nouveau paquet.

   

   Là encore ça ne fonctionne pas, si le ACK ne part pas on va avoir un doublon de paquet. Tooma va renvoyer un paquet déjà existante et provoquera un doublon.

3. Le protocole du bit alterné

   Chaque paquet va être accompagné d'un "flag". En fait un bit qui vaut en départ 0.

   Chaque ACK portera le bit correspondant au paquet reçu.

   A chaque nouvel envoi le bit est alterné, il change de valeur.