Introduction aux protocoles

Avant d’étudier comment communiquent les hôtes dans un vaste réseau tel qu’Internet, il nous faut comprendre ce qu’est un protocole pour commencer.

A protocol is a set of rules that define how communication occurs in a network.

C’est la définition la plus basique d’un protocole que vous retrouverez certainement dans plusieurs cours anglais de réseaux. En français, on dit qu’un protocole est un ensemble de règles qui définissent comment se produit une communication dans un réseau. Pour mieux appréhender cela, nous allons considérer une analogie.

Le protocole : un genre de langue

Communiquer est l’une des activités les plus courantes. Les personnes qui communiquent ne peuvent se comprendre que dans deux cas :

• Si elles parlent la même langue.
• Si elles ont un intermédiaire qui parle leurs deux langues respectives pour faire office d’interprète.

Mais une langue que les humains parlent, qu’est-ce que c’est, au final ?

D’après Wikipédia, une langue est un système constitué de signes linguistiques, vocaux, graphiques, gestuels, tenu en cohésion par des règles précises qui, lorsque respectées, permettent la communication.

En réseau, c’est la même chose. La langue que les humains parlent, c’est un protocole pour les hôtes dans un réseau. Pas n’importe quel protocole, car il en existe plusieurs. Mais celui qui nous concerne est appelé « protocole de communication ».

Quant à l’interprète de notre exemple, dans un réseau, ce sera la passerelle (applicative) qui permettra de faire communiquer deux réseaux basés sur des protocoles différents en assurant plusieurs fonctions telles que la traduction des protocoles et des signaux, l’isolation d’erreurs, l’adaptation d’impédances, etc.

Si vous ne comprenez pas ces termes techniques, ce n’est pas important pour l’instant.

Bien ! Vous avez compris le concept de protocole ? Maintenant essayons de voir à quoi ça sert dans un réseau. Pour comprendre cela, très souvent, on utilise une analogie que nous qualifions de « classique » en réseau, car plusieurs professeurs utilisent presque toujours cette dernière pour faire assimiler les fonctions assurées par un protocole. Il s’agit de la communication téléphonique entre deux humains.

Pierre veut transmettre un message à Jean. Il compose donc son numéro de téléphone et il peut entendre la tonalité (tuuuut… tuuuuut…). Il attend que Jean décroche, car la communication ne peut avoir lieu qu’à ce moment-là. Jean, de son côté, entend son téléphone sonner. Il décroche, et c’est là qu’intervient le classique « Allô ?».

À ce niveau, la « session de communication » est établie, c’est-à-dire que Pierre peut maintenant dire à Jean ce qu’il a en tête. Il va donc gentiment se présenter : « Salut, c’est Pierre… » et évoquer le contexte ou la raison de son appel : « C’était juste pour te dire que demain, il y aura une fête chez Anne-Sophie, qui habite au numéro 10 de la rue Lézard ! ». Jean peut éventuellement demander à Pierre de répéter, pour être sûr d’avoir bien saisi son message : « Chez qui ? Anne qui ? ». Alors Pierre répétera cette partie pour que Jean comprenne. Finalement, la conversation terminée, il faut se séparer en douceur ( ) . Un classique « salut » ou « au revoir » des deux côtés avant qu’ils ne raccrochent leurs combinés.

Les protocoles nous permettent de faire tout ça. Essayons un peu de réexaminer ce scénario avec un langage un peu plus informatique.

Pierre veut transmettre un message à Jean.

Il compose donc son numéro de téléphone et il peut entendre la tonalité (tuuuut… tuuuuut…). Il attend que Jean décroche, car la communication ne peut avoir lieu qu’à ce moment-là.

L’hôte Pierre, à l’adresse IP 124.23.42.13, souhaite communiquer avec l’hôte Jean à l’adresse IP 124.23.12.13. Il lui enverra un paquet de demande d’initialisation de session (il compose son numéro et attend que Jean décroche et dise « Allô »). À ce stade, il peut se passer quatre choses dans le contexte naturel :

1. Le numéro est incorrect.
2. Le numéro est correct mais indisponible.
3. Le numéro est correct et Jean décroche en disant « Allô ».
4. Le numéro est correct, disponible, mais Jean ne décroche pas (c’est donc un peu comme le cas 2 ).

Étudions ces cas :

• Cas 1 : Pierre aura un message vocal disant « Le numéro que vous avez composé n’existe pas ». En réseau ce sera un paquet ICMP(Internet Control Message Protocol) qui enverra une erreur de type 3 (destination unreachable, destination inaccessible) et de code 7 (destination host unknown, destinataire inconnu).

• Cas 2 : Ici, un message vocal dira à Pierre « L’abonné que vous souhaitez appeler est injoignable pour l’instant, veuillez rappeler dans quelques instants ». En réseau, il s’agira également d’une erreur de type 3.

• Cas 3 : Si le numéro est correct et que Jean décroche en disant « Allô », c’est le début de la conversation. En réseau on dira donc qu’une session a été initialisée.

• Cas 4 : Ici, classiquement, ce sera le répondeur de Jean qui dira « Je ne suis pas disponible pour l’instant, laissez-moi un message, je vous rappellerai dès que possible ». En réseau, c’est un peu différent. L’hôte Pierre va recevoir une erreur ICMP de type 3 (destination inaccessible) et de code 1 (destinataire inaccessible). En gros, c’est pour dire qu’on n’arrive pas à atteindre le destinataire. En fait, si un numéro de téléphone est disponible, sonne, mais que personne ne répond, ça veut dire qu’on n’a pas atteint le destinataire final en fait. Donc c’est un peu pareil que le cas 2.

Continuons l’analyse de notre analogie.

« C’était juste pour te dire que demain, il y aura une fête chez Anne-Sophie, qui habite au numéro 10 de la rue Lézard ».

Jean peut éventuellement demander à Pierre de répéter, pour être sûr d’avoir bien saisi son message « Chez qui ? Anne qui ? ». Alors Pierre répétera cette partie pour que Jean comprenne.

Si Jean demande à Pierre de répéter quelque chose, de façon radicale on peut conclure qu’il n’a pas reçu ce que Pierre a dit (si l’on considère que recevoir un message = comprendre le message). En réseau, l’hôte Jean va envoyer un paquet à Pierre disant « je n’ai pas reçu le dernier paquet, renvoie-le stp ». Pierre va alors renvoyer le dernier paquet. En fait, c’est un peu plus précis que ça. Suivant le protocole que vous utilisez (UDP ou TCP, nous allons les comparer dans les prochains chapitres), Pierre peut demander à la fin de chaque phrase si Jean a compris. En réseau, l’hôte Pierre pourrait donc demander un message d’accusé de réception à chaque envoi de paquet, et l’hôte Jean devra répondre « oui j’ai reçu, envoie le prochain » tout le long de la communication si l’on utilise le protocole TCP qui est dit connection-oriented (orienté connexion) par opposition au protocole UDP qui est dit connectionless-oriented. Tenez-vous tranquille, avec TCP on peut faire encore plus fort que ça.

Qu’est-ce qui se passe, si Pierre se met à raconter sa vie à raconter une histoire à Jean et que ce dernier dépose le combiné et s’en va faire un tour aux toilettes sans prévenir ? Pierre aurait perdu son temps en parlant pour rien ! Pour prévenir ce genre de chose, Pierre peut vérifier la présence de Jean en demandant toutes les x minutes « Tu me suis ? Tu es là ? ». En réseau, avec TCP il s’agit d’une vérification périodique de l’état de la session de communication. Ceci dit, l’hôte Pierre enverra un paquet de « vérification de session » pour savoir si l’hôte Jean est toujours connecté. Si Jean ne répond pas après un certain laps de temps, la communication est terminée (la session se termine là).

Finalement, la conversation terminée, il faut se séparer en douceur. Un classique « salut » ou « au revoir » des deux côtés avant qu’ils ne raccrochent leurs combinés.

À ce stade, la session de communication est terminée.

Un protocole de communication digne de ce nom doit remplir quelques exigences rigoureuses. Un protocole est un ensemble de règles dictant comment doit s’effectuer la communication entre deux entités. Ceci dit, il faudrait que ledit protocole soit en mesure d’assurer des fonctions vitales au bon déroulement d’une communication. Il existe plusieurs « fonctions vitales » (comprendre exigences) qu’un protocole de communication doit être capable de remplir. Dans la sous-partie précédente, nous avons vu quelques-unes de ces fonctions le long de l’exemple sans vous les pointer directement. Parmi ces fonctions figurent en bonne et auguste posture :

• La gestion du format des données : un protocole, comme nous l’avons répété, définit comment s’effectue la communication. Or, qui dit communication dit échanges de données. Le protocole doit donc avoir des « fonctions » permettant de gérer le format de ces données. Nous verrons plus tard dans quelle couche du modèle OSI on trouve ces services de formatage. En général, les données seront constituées de deux choses : d’un entête et du contenu. L’entête sera un peu « réservé » au protocole. C’est à ce niveau que l’on trouve des informations « techniques » tandis que le contenu… bah, c’est le contenu !

• La gestion du format d’adresses : durant la procédure de transmission des données, il faudrait bien gérer les adresses : qui est l’émetteur, qui est le destinataire ? Dans une communication dans le monde naturel, quand on écrit une lettre, dans l’entête, on met l’adresse de l’émetteur et celle du destinataire, et même sur l’enveloppe d’ailleurs. Si on ne le fait pas, on ne sait pas à qui envoyer la lettre, et celui qui la reçoit ne sait même pas si elle lui est destinée et de qui elle provient. Par comparaison, dans l’entête des données « encapsulées », il faudrait qu’un protocole soit en mesure de spécifier l’adresse de l’émetteur et du destinataire.

• Correspondance d’adresses : quand vous inscrivez l’adresse du destinataire sur une enveloppe, cette dernière est « logique ». Logique dans ce sens que le destinataire n’habite pas sur cette enveloppe ( ), mais cette adresse indique l’adresse physique du destinataire, là où vous pouvez le trouver si vous vous y rendez physiquement. Le facteur doit donc faire une correspondance entre cette adresse logique sur l’enveloppe et l’adresse physique. Par analogie, un protocole doit assurer des fonctions de correspondance entre les adresses logiques (IP) et les adresses physiques (MAC). Cette correspondance s’appelle « address mapping » en anglais.

• Routage : nous allons passer un long moment sur ce sujet dans la suite de ce tuto. Dit simplement, le routage consiste à « diriger » les données entre deux réseaux d’un plan d’adressage différent.

• Détection d’erreurs de transmission : il se peut qu’une erreur se produise dans la procédure de transmission des informations. Un protocole devrait donc être en mesure de détecter ces erreurs. Comme nous allons le voir, il s’agit d’un CRC (Cyclic Redundancy Check, Contrôle de Redondance Cyclique) qui est ajouté à la fin des paquets.

• Accusé de réception : quand vous recevez un mail, très souvent vous y répondez. Cette réponse informe explicitement à l’émetteur que vous avez reçu son mail. C’est en quelque sorte un accusé de réception. Certains protocoles permettent donc à un hôte récepteur d’informer un hôte émetteur qu’il a reçu le paquet envoyé pour empêcher ce dernier de renvoyer les mêmes choses. D’autres par contre n’implémentent pas cette fonction.

• La gestion de perte d’informations : de même que des erreurs peuvent se produire lors de la transmission, il peut y avoir des pertes d’informations. Pertes ? Dans un réseau ? Oui ! Généralement quand un paquet met trop du temps à arriver à son destinataire, « il se perd ». Voilà pourquoi c’est important qu’un protocole gère la reconnaissance des paquets. Si l’hôte-récepteur B répond dans un intervalle de x secondes à l’hôte-émetteur A, ce dernier saura alors que B a bien reçu les données, et n’essaiera plus de les renvoyer. Si B par contre ne répond pas à A, ce dernier peut donc conclure que les données « se sont perdues » et va les renvoyer dans un espace de temps déterminé par le protocole.

• La direction du flux d’informations : A et B peuvent-ils communiquer (s’échanger des données) simultanément ? Si oui, il s’agit d’un système de communication full-duplex. Sinon, il s’agit d’un système de communication half-duplex. Nous allons en parler un peu plus tard dans cette partie du cours. Un protocole doit donc dicter la direction de flux dans la communication pour empêcher à deux hôtes de communiquer simultanément dans un système half-duplex par exemple.

• Contrôle de séquences : toute information envoyée sur un réseau est segmentée en plusieurs « séquences » (nous y reviendrons). Elles sont ensuite envoyées au destinataire. Selon la congestion (le degré d’occupation) des routes qu’elles vont emprunter, elles peuvent arriver « en désordre », ou même en double (s’il y a eu des retransmissions). Grâce au contrôle de séquences d’un protocole, on peut « numéroter » chaque « morceau » afin que le destinataire sache les « remettre en ordre » ou supprimer les doublons. Nous allons voir comment fonctionne cette « segmentation » en étudiant le protocole BitTorrent.

• Gestion de flux : quand deux personnes parlent, il est nécessaire de donner à celui qui « écoute » le temps de comprendre ce qui est dit, puisqu’il se peut que l’émetteur parle plus vite que le récepteur. Il faut donc gérer cette volubilité, ce flux. Dans les réseaux, il y a des cas où un hôte-émetteur peut transmettre plus vite que ne peut recevoir un hôte-récepteur. C’est là qu’intervient l’utilité de la gestion des flux.

Mais non ! Les fonctions citées ne peuvent pas être réalisées par un seul protocole. Il s’agit d’une suite protocolaire, une suite de protocoles. Il y a des protocoles qui s’occupent de la transmission, d’autres du routage, etc. Une suite de protocoles est un ensemble de protocoles fonctionnant en harmonie et cohésion pour le bon déroulement de la communication. Vous avez déjà entendu l’expression « protocole TCP/IP » ? En fait, ce n’est pas un protocole. TCP en est un, IP en est un autre. Mais TCP/IP, ça fait deux. C’est une suite (une pile pour être précis) de protocoles en fait, protocol stack en anglais.