Les protocoles de communication =============================== <img class="r-stretch centre image-responsive" src="https://upload.wikimedia.org/wikipedia/commons/3/3d/Torrentcomp_small.gif" alt="illustration"> <small>Crédits : <a href="https://commons.wikimedia.org/wiki/File:Torrentcomp_small.gif">Wikiadd</a>, <a href="http://creativecommons.org/licenses/by-sa/3.0/">CC BY-SA 3.0</a>, via Wikimedia Commons</small> *Ce document a été créé en collaboration avec Claude (modèle Claude Sonnet 4), qui a été utilisé pour transposer le cours correspondant (accessible [ici](protocoles)) en un diaporama. Pour voir la conversation [cliquez ici](https://claude.ai/public/artifacts/b9941432-f36f-4184-ac9d-6935779e57a8).* --- ## Qu'est-ce qu'un protocole de communication ? - **Définition** : Ensemble de règles pour la communication entre machines - **Spécifie** : - Le **format** des informations échangées - La **manière** de les échanger - L'**établissement** et la **terminaison** de la communication - Les machines utilisent **plusieurs protocoles** simultanément --- ## Rappels sur le protocole TCP/IP ---- ### Définitions - **Protocole IP** (Internet Protocol) : - Assure l'acheminement des paquets d'une machine A vers B - Utilise les adresses IP des machines - **Protocole TCP** (Transmission Control Protocol) : - Assure la transmission correcte des paquets - Gère la numérotation et les accusés de réception - Basé sur le **découpage en paquets** et l'**encapsulation** ---- ### TCP/IP - Étape 1 : Encapsulation - **TCP** découpe les données en paquets - Ajoute un **numéro** à chaque paquet - **IP** encapsule le paquet TCP - Ajoute les **adresses IP** de l'émetteur et du récepteur <img class="centre image-responsive" src="data/tcp_ip_1.png" alt="illustration"> ---- ### TCP/IP - Étape 2 : Transport - Le protocole **IP** achemine les paquets vers la destination - Utilise l'**adresse IP** du destinataire - Les paquets passent de **routeurs en routeurs** - Chemin déterminé par des **algorithmes** (route la plus rapide) <img class="centre image-responsive" src="data/tcp_ip_2.png" alt="illustration"> ---- ### TCP/IP - Étape 3 : Désencapsulation - À destination, les données sont **désencapsulées** - **IP** donne chaque paquet à **TCP** - **TCP** réordonne les paquets selon leur numéro - Reconstitue les **données originales** <img class="centre image-responsive" src="data/tcp_ip_3.png" alt="illustration"> ---- ### TCP/IP - Étape 4 : Accusé de réception - **TCP** s'assure que chaque paquet arrive à destination - L'ordinateur B envoie un **accusé de réception** à A - Message : "OK, j'ai bien reçu le paquet" - Si pas d'accusé → **renvoi** du paquet après un délai <img class="centre image-responsive" src="data/tcp_ip_4.png" alt="illustration"> --- ## Le modèle de *couches* Internet ---- ### Modèle Internet en 4 couches <img class="centre image-responsive" src="data/modele_internet_4_couches.svg" alt="modèle internet en 4 couches"> - **Couche 4 - Application** : Point d'accès aux services réseau (coder et décoder les infos utiles pour les applications) - **Couche 3 - Transport** : Gestion des connexions entre applications (contrôle des flux, gestion des erreurs) ---- ### Modèle Internet en 4 couches <img class="centre image-responsive" src="data/modele_internet_4_couches.svg" alt="modèle internet en 4 couches"> - **Couche 2 - Internet** : Acheminement des paquets via les routeurs - **Couche 1 - Accès réseau** : Transmission physique entre machines (d'un même résau) ---- ### Encapsulation des données <img class="centre image-responsive" src="data/modele_internet_encapsulation_v2.png" alt="modèle internet en 4 couches"> - Chaque couche **ajoute des données** à la couche supérieure - **Segment** : données de la couche Transport - **Datagramme/Paquet** : données de la couche Internet - **Trame** : données de la couche Accès réseau - Principe de **pile de protocoles** ---- ### Modèle Internet = modèle TCP/IP - Le modèle Internet s'appelle aussi parfois *modèle TCP/IP* - Mais cela porte à confusion ! - Car la couche "Transport" peut utiliser un autre protocole que TCP (ex : UDP) - Car la couche "Internet" met en oeuvre d'autres protocoles que IP (ex : ARP) ---- ## Couche Accès réseau - Le message de la couche n'est pas envoyé directement, il est encapsulé dans une **trame** qui sera envoyée **physiquement** sur le réseau - Communication via **interface physique** - Identifiée par une **adresse MAC** (Media Access Control) - **Adresse physique unique** définie par le constructeur - Format : 6 octets en hexadécimal (XX:XX:XX:XX:XX:XX) - Exemple : 5E:FF:56:A2:AF:15 ---- ## Couche *Accès réseau* - Interfaces physiques connues : Ethernet, Wi-Fi, OTN (Optical Transport Network) = fibre - Si la laison physique est de type Ethernet, on parle de **trame Ethernet** : - Encapsule le **datagramme IP** - Ajoute les **adresses MAC** émetteur et destinataire - Contient des **codes de contrôle d'erreurs** - Permet la transmission **physique** sur le réseau ---- ## Protocole ARP - **Problème** : IP connaît les adresses IP, pas les adresses MAC - **Solution** : Protocole ARP (Address Resolution Protocol) = permet de connaître l'@MAC à partir de l'@IP - **Principe** : - Requête à toutes les machines : "Quelle @MAC a cette @IP ?" - Seule la machine concernée répond avec son @MAC - Table de correspondance mise en cache ---- ## Couche *Application* - Le message encapsulé par la couche *Transport* contient lui-même des données encapsulées par le protocole utilisé au niveau de la couche *Application* - Exemples de protocoles utilisés par la couche *Application* : - **HTTP/HTTPS** : Navigation web (navigateur ↔ serveur) - **SMTP, POP, IMAP** : Messagerie électronique - **FTP** : Transfert de fichiers - Chaque application utilise son **protocole spécifique** ---- ## Synthèse - Modèle Internet complet - **4 couches** avec leurs protocoles respectifs - **Encapsulation** à l'envoi (de haut en bas) - **Désencapsulation** à la réception (de bas en haut) - Exemple complet : Requête HTTP via trame Ethernet <img class="centre image-responsive" src="data/modele_internet_protocoles.svg" alt="modèle internet en 4 couches"> ---- ## Synthèse - Exemple (requête HTTP) <img class="centre image-responsive" src="data/modele_internet_4_couches_bilan.svg" alt="modèle internet en 4 couches"> --- ## Le modèle OSI ---- #### Modèle OSI - C'est un autre modèle *théorique* pour découper les piles de protocoles utilisés <img class="centre image-responsive" src="data/osi_vs_internet.png" alt="modèle internet en 4 couches"> --- # Le protocole du bit alterné ---- ## Introduction - La couche *Transport* gère les flux de données - Protocoles mis en œuvre pour assurer la fiabilité des transmissions - TCP utilise numérotation et accusé de réception - **Protocole du bit alterné** : solution plus basique mais pas infaillible ---- ## Contexte - Alice veut envoyer à Bob un message M - Message prédécoupé en sous-messages M0, M1, M2,... - Alice envoie ses sous-messages au fur et à mesure ---- ### Situation idéale <img class="r-stretch centre image-responsive" src="data/ideale.png" alt="situation idéale"> - Messages envoyés par Alice à cadence Δt fixée - Sous-messages arrivent tous à destination dans le bon ordre - Transmission correcte ---- ### Situation réelle <img class="r-stretch centre image-responsive" src="data/realite.png" alt="situation réelle"> - On maîtrise le timing d'envoi d'Alice - Temps d'arrivée des sous-messages *imprévisible* - Sous-messages peuvent être détruits en route - Exemple : M0 arrive après M1, M2 n'arrive jamais ---- **Que faire ?** ---- ### Solution naïve <img class="r-stretch centre image-responsive" src="data/naive.png" alt="situation naïve"> - Bob envoie un signal ACK (acknowledgement) à Alice - ACK confirme la réception du sous-message - Alice renvoie un message considéré comme perdu - Permet de gérer les messages perdus ---- ### Problème de la solution naïve <img class="r-stretch centre image-responsive" src="data/naivebad.png" alt="situation naïve peu efficace"> - Si le deuxième ACK de Bob met trop de temps à arriver - Alice suppose que son sous-message M1 n'est pas arrivé - Elle renvoie M1 - Bob se retrouve avec deux fois le sous-message M1 - Transmission incorrecte, rien ne permet de le détecter ---- ### Problème de la solution naïve <img class="r-stretch centre image-responsive" src="data/naivebad.png" alt="situation naïve peu efficace"> > Que se passe-t-il sur le deuxième ACK de Bob est perdu ? ---- ### Le protocole du bit alterné - Principe - Bob intègre une méthode de validation du sous-message reçu - Il peut décider de garder ou d'écarter le message - But : éviter les doublons ---- ### Le protocole du bit alterné - Mécanisme (1/2) - Alice ajoute un bit de contrôle **FLAG** à chaque sous-message - Au départ, FLAG vaut 0 - Quand Bob reçoit un FLAG, il renvoie un ACK **égal au FLAG reçu** ---- ### Le protocole du bit alterné - Mécanisme (2/2) - Alice attend l'ACK contenant le même bit que son dernier FLAG envoyé - Tant qu'elle ne l'a pas reçu : continue à envoyer le même sous-message avec le même FLAG - Dès qu'elle l'a reçu : envoie nouveau sous-message en inversant le bit FLAG - Bob garde seulement les sous-messages dont le FLAG = inverse de son dernier ACK ---- #### Cas où le sous-message est perdu <img class="r-stretch centre image-responsive" src="data/alt2.png" alt="cas où le message est perdu"> - Le message d'Alice avec le FLAG 1 est perdu en route - Alice ne reçoit pas d'ACK 1 donc renvoie le message avec le même FLAG - Bob finit par recevoir le message, renvoyé l'ACK 1 qui est reçu par Alice ---- #### Cas où le ACK est perdu <img class="r-stretch centre image-responsive" src="data/alt1.png" alt="cas où l'accusé est perdu"> - Bob reçoit M1 avec FLAG 1 mais l'ACK 1 est perdu - Alice renvoie M1 avec FLAG 1 - Bob reçoit M1 : - renvoie un ACK1 - Bob détecte un doublon et l'écarte (il s'attend à avoir un FLAG 0 et reçoit un FLAG 1) - Protocole détecte bien le doublon ---- #### Cas où un sous-message est en retard <img class="r-stretch centre image-responsive" src="data/alt3.png" alt="cas où le message est en retard"> - Même principe : doublon détecté et rejeté - Transmission correcte ! ---- #### Cas où le protocole est inefficace - Il existe des situations où le protocole du bit alterné ne permet pas d'assurer une transmission correcte ---- #### Exemple problématique Cas précédent : <img class="r-stretch centre image-responsive" src="data/alt3.png" alt="cas où le message est en retard"> > Et si le premier sous-message M1 était *encore plus* en retard ? ---- ### Conclusion - Protocole longtemps utilisé au sein de la couche 2 du modèle OSI - Simple et léger - Peut être facilement mis en défaut - Remplacé par des protocoles plus performants mais plus complexes comme TCP (qui intervient quant à lui au niveau de la couche *Transport*) ---- ## Protocoles sans accusé de réception - Certains protocoles ne prévoient pas d'accusés de réception - L'émetteur ne sait pas si tous les paquets arrivent - Exemple : **protocole UDP** - transmissions plus rapides mais moins fiables que TCP - Paquet perdu = définitivement perdu - Utilisation quand la rapidité est primordiale et la perte moins gênante : - VoIP - streaming vidéo - jeux en ligne --- # Bilan ---- ## Bilan (1/2) - **Protocole de communication** = ensemble de règles précisant format, échange et établissement/terminaison - Messages découpés en paquets, acheminés via TCP et IP - Communications via **couches de protocoles** avec encapsulation - **Modèle Internet** (4 couches) et **modèle OSI** ---- ## Bilan (2/2) ## Les couches - **Application** : protocoles des applications (email, HTTP...) - **Accès réseau** : fabrication de la trame avec adresses MAC - Protocoles de fiabilité : **bit alterné** (simple mais limité), **TCP** (complexe mais efficace) --- **Références** : - Cours *Introduction aux réseaux* du DIU EIL de l'université de Nantes, Pierrick Passard et Salima Hamma. - Cours de Gilles Lassus sur les [Protocoles de communication](https://glassus.github.io/premiere_nsi/T3_Architecture_materielle/3.4_Protocoles_de_communication/cours/). - Cours de David Roche sur le [Modèle TCP/IP](https://dav74.github.io/site_nsi_prem/c18c/) --- Germain Becker, Lycée Emmanuel Mounier, Angers. Sous licence [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/deed.fr).