Ce videoclip produit par l’Ecole Polytechnique Fédérale de Lausanne

Présentation au sujet: "Ce videoclip produit par l’Ecole Polytechnique Fédérale de Lausanne"— Transcription de la présentation:

1 Ce videoclip produit par l’Ecole Polytechnique Fédérale de Lausanne
fait partie de son cours d’introduction à l’information, à la communication, et au calcul. Il s’inscrit dans le 3e module de ce cours qui porte sur le fonctionnement et la sécurité des systèmes informatiques.

2 Le besoin de structure dans la transmission de données
Imaginons un signal arrivant d’un réseau, sans aucune structure Comment savoir si c’est un signal électrique réel ou juste du bruit ? Comment le convertir en un signal numérique binaire ? Comment savoir où il commence et où il finit ? Comment savoir d’où il vient ? Comment interpréter ce qu’il contient ? Autant essayer de capter un message extra-terrestre Comme aux fins de gestion des données sur des mémoires mortes, la gestion de données transmises sur un réseau impose un besoin de structure dans ces données. Imaginons en effet un signal électromagnétique arrivant d’un réseau sans aucune structure. 1 Comment savoir si c’est un signal réel ou juste du bruit résultant de perturbations cosmiques ? Comment convertir cet hypothétique signal en une suite de bits ? S’il s’agit effectivement d’un signal bien réel, comment savoir où il commence et où il finit ? Comment savoir d’où il vient ? Comment interpréter ce qu’il contient ? 2 Sans structure, autant essayer de capter et de comprendre un message extra-terrestre.

3 Plan de la leçon Le besoin de structure dans la transmission des données Types de structures: protocoles, messages, couches, encapsulation Structures d’Internet: topologie, interfaces, commutation, routage, protocoles Évolution des paradigmes de réseaux La suite de ce clip va introduire les concepts de base – protocoles et messages – qui permettent de structurer les données transmises sur un réseau.

4 Les protocoles – Le pourquoi
Un protocole = une règle qui gouverne une communication Exemple Oral Ecrit Où commence et où finit une communication ? Elle est délimitée par deux silences … ou par l’enveloppe d’un envoi postal Mais qu’est-ce qu’un silence ou l’enveloppe d’un envoi informatique ? D’où vient-elle et à qui s’adresse-t-elle ? De l’orateur à son interlocuteur … ou du signataire au destinataire d’un courrier Mais comment identifier un émetteur ou un récepteur informatique ? Dans quel langage est-elle exprimée ? Un langage commun aux interlocuteurs … ou à l’expéditeur et aux destinataires Mais comment des ordinateurs peuvent-ils savoir et se mettre d’accord ? Et si la communication est perturbée ? Un interlocuteur demande “Pardon?” … ou un destinataire demande une explication Mais comment peut faire un ordinateur en cas d’erreur ? A qui le tour de communiquer ? À chacun son tour de parler … mais on peut échanger des courriers simultanés Mais comment un ordinateur sourd et aveugle peut-il savoir ? Qu’est ce qui se cache derrière le terme abstrait de protocole? En réalité quelque chose de fort comparable à la notion de protocole dans une réunion officielle: Une série de règles qui doivent être respectées pour le bon déroulement des interactions. 1 A titre d’illustration imaginons la situation de 2 personnes qui désirent communiquer oralement dans un cas et par écrit dans un autre. 2 Une 1e question est que ces 2 interlocuteurs doivent se mettre d’accord sur où commence et où finit une communication ? Oralement elle est délimitée par deux silences. Par écrit elle est délimitée par l’enveloppe d’un envoi postal. Mais qu’est-ce qu’un silence ou l’enveloppe d’un envoi informatique ? 3 Une 2e question est d’où vient-elle et à qui s’adresse-t-elle ? Dans le cas oral de l’orateur à son interlocuteur. Dans le cas écrit du signataire au destinataire du courrier. Mais comment identifier un émetteur ou un récepteur informatique ? 4 Une 3e question est dans quel langage est-elle exprimée ? Oralement comme par écrit dans un langage commun aux deux parties. Mais comment des ordinateurs peuvent-ils savoir et se mettre d’accord ? 5 Se pose ensuite la question de ce qui se passe si la communication est perturbée ? Oralement un interlocuteur peut demander “Pardon?” alors que le destinataire d’un courrier peut se plaindre d’un courrier endommagé ou perdu. Mais comment peut faire un ordinateur en cas de telles erreurs ? 6 Et comment savoir à qui est le tour de communiquer ? Oralement c’est chacun à son tour et pas tous à la fois, quitte à lever la main. Par écrit cela joue moins un rôle car on peut échanger des courriers simultanés. Mais comment un ordinateur sourd et aveugle doit-il se comporter ?

5 Les messages – Le comment des protocoles Début et fin
Toute communication est faite de messages délimités par des marqueurs (sur les lignes de transmission) ou … un pointeur + longueur (au sein d’un ordinateur) L pointeur + longueur La réponse à toutes ces questions demande la définition d’un protocole. Tout protocole consiste en un échange formalisé de messages standardisés. Ces messages doivent tout d’abord être délimités soit par des signaux caractéristiques appelés marqueurs sur les lignes de transmission soit par un pointeur + un champ donnant leur longueur dès lors que le message est sous forme d’une chaines de bits dans la mémoire d’un ordinateur. marqueur longueur L message marqueur

6 Les messages – Le comment des protocoles Séquencement
Une communication peut se composer de plusieurs messages “On sonne à la porte je te rappelle …” ou “Nous verrons cela à la prochaine leçon…” Un abonnement à un journal ou un magazine Un envoi tellement gros que l’expédier en un colis est trop lourd pour la poste Un fichier est tellement long que l’expédier en une fois saturerait une ligne Un message peut inclure un numéro de séquence Entre deux personnes comme entre deux ordinateurs une communication peut cependant se composer de plusieurs messages, p.ex. “On sonne à la porte je te rappelle …” ou “Nous verrons cela à la prochaine leçon…”. Un abonnement à un journal ou un magazine suppose l’envoi de plusieurs numéros. Un envoi peut être tellement gros que l’expédier en un colis est trop lourd pour la poste. Un fichier peut être tellement long que l’expédier en un gros message saturerait un réseau. Un message informatique peut donc inclure un numéro de séquence indiquant qu’il fait partie d’un échange de plusieurs messages associés. longueur no. seq. message

7 Les messages – Le comment des protocoles Adressage émetteur et récepteur
Chaque message contient les adresses de l’émetteur et du récepteur Un ordinateur doit bien savoir d’où vient et où va un message. Donc chaque message doit contenir des adresses identifiant son émetteur et son ou ses récepteur(s). src dest longueur no. seq. message

8 Les messages – Le comment des protocoles Syntaxe et sémantique
Chaque message contient un champ indiquant le langage du message (= type d’application) Qu’un ordinateur soit polyglotte ou pas il doit indiquer à ses correspondants la langue dans laquelle il s’exprime. Chaque message contient donc typiquement un champ indiquant le langage du message. En pratique ce langage est synonyme de l’application qui est supposée traiter le message tant du côté de l’émetteur que du côté du récepteur. src dest longueur no. seq. type message

9 Les messages – Le comment des protocoles OK ou erreur et retransmission
Chaque message peut contenir un code de détection d’erreur (CRC) (CRC = cyclic redundancy check = un “résumé mathématique” du message en quelques (n) octets) La probabilité que deux messages aient le même résumé = 1 / 28n (=> très faible si n est assez grand) Si le message envoyé et / ou son résumé subissent une erreur de transmission le message et le résumé reçus ne “colleront” plus ensemble => le récepteur en déduit une erreur de transmission Maintenant de quoi un protocole a-t-il besoin pour gérer les cas d’erreur? A cette fin chaque message peut contenir ce qu’on appelle un code de détection d’erreur ou CRC qui signifie en anglais cyclic redundancy check. Un CRC est en fait un “résumé mathématique” du message en quelques octets, typiquement 1, 2, ou 4, voire un peu plus. 1 La probabilité que deux messages aient le même résumé de n octets est = 1 / 28n. 2 Autant dire qu’elle est très faible si n est assez grand, déjà 1/216 soit < 1/64000e si n=2 octets. 3 Si le message envoyé et / ou son résumé subissent une erreur de transmission le message et le résumé reçus ne “colleront” plus ensemble. Le récepteur en déduira donc une erreur de transmission. src dest longueur no. seq. type message CRC

10 Les messages – Le comment des protocoles OK ou erreur et retransmission
Chaque message peut contenir un code de détection d’erreur (CRC) et un champ indiquant s’il s’agit d’un message OU … d’un acquittement négatif (= “Il me manque le message no. seq., retransmettre SVP”) => L’émetteur peut aussi renvoyer automatiquement après un “time-out” sans acquittement La question est alors que faire dans ce cas? Outre un CRC chaque message peut aussi contenir un champ indiquant s’il s’agit d’un message ou de ce qu’on appelle un acquittement c.à.d. l’équivalent d’un acquiescement oral ou d’une quittance de réception pour un courrier postal. En cas d’erreur de transmission, le récepteur peut renvoyer un acquittement négatif signifiant “Il me manque le message portant le no. de séquence ci-joint, prière de retransmettre”. Bien sûr le message original peut être non seulement perturbé mais même complètement perdu. De la même façon un acquittement peut aussi se perdre dans le réseau. Dans un cas comme dans l’autre l’émetteur ne peut pas savoir où en est le récepteur. Dans ce cas après un “time-out” sans acquittement il peut automatiquement renvoyer le message original. src dest longueur no. seq. type msg message CRC src dest longueur no. seq. type nacq CRC

11 Les messages – Le comment des protocoles OK ou erreur et retransmission
Chaque message peut contenir un code de détection d’erreur (CRC) et un champ indiquant s’il s’agit d’un message OU … d’un acquittement positif (= “Bien reçu et bien compris jusque et y compris message no. seq.”) => OK pour envoyer le / les N message(s) suivant(s) [N = fenêtre d’envoi] Il résulte de cette dernière observation que le récepteur DOIT en fait renvoyer un acquittement qu’il y ait erreur ou pas, sinon l’émetteur ne peut pas savoir et va retransmettre inutilement. En l’absence normale d’erreur, le récepteur renvoie des acquittements positifs signifiant donc «Bien reçu et bien compris». Ceci dit, il ne doit pas nécessairement acquitter réception de chaque message individuellement. Il doit simplement renvoyer des acquittemenst assez fréquemment pour que l’émetteur ne retransmette pas inutilement des messages bien reçus. Par contre tant que les messages semblent arriver régulièrement et sans erreur le récepteur peut se contenter d’acquitter réception d’un seul message sur N. En indiquant le no. de séquence de ce Ne message dans l’acquittement cet acquittement vaut alors pour les N messages précédents. Outre qu’il limite le nombre d’acquittements nécessaires ce facteur N joue aussi un rôle de régulateur. En effet il autorise l’émetteur à envoyer les N messages suivants. Il constitue ce qu’on appelle la fenêtre d’envois autorisés. A défaut de ce facteur N l’émetteur pourrait envoyer des messages plus vite que le récepteur ne puisse les recevoir. Pour le coup des messages se perdraient et devraient être retransmis, ce qui saturerait inutilement les réseaux. src dest longueur no. seq. type msg message CRC src dest longueur no. seq. type acq CRC Dernier message acquitté / Dernier message envoyé / Dernier message acceptable

12 Les messages – Le comment des protocoles Résumé – En-tête
Tous les champs de “contrôle” sont regroupés dans ce qu’on appelle l’en-tête, enveloppe ou “header” Cette enveloppe est ajoutée avant expédition et retirée après réception … comme pour un courrier postal L’ensemble des champs de “contrôle” du protocole que nos venons de voir constitue ce qu’on appelle l’en-tête, enveloppe ou “header” du message. Cette enveloppe est ajoutée avant son expédition et retirée après sa réception … exactement comme pour un courrier postal. src dest longueur no. seq. type msg / n/acq message CRC entête message CRC