reseaux informatiques
protocoles reseaux
Exemple de communication entre deux processus utilisant la suite protocolaire TCP/IPTCP/IP est une suite de protocoles. Le sigle TCP/IP signifie « Transmission Control Protocol/Internet Protocol » et se prononce « T-C-P-I-P ». Il provient des noms des deux protocoles majeurs de la suite de protocoles, c'est-à-dire les protocoles TCP et IP).
TCP/IP représente d'une certaine façon l'ensemble des règles de communication sur internet et se base sur la notion adressage IP, c'est-à-dire le fait de fournir une adresse IP à chaque machine du réseau afin de pouvoir acheminer des paquets de données. Etant donné que la suite de protocoles TCP/IP a été créée à l'origine dans un but militaire, elle est conçue pour répondre à un certain nombre de critères parmi lesquels :
- Le fractionnement des messages en paquets ;
- L'utilisation d'un système d'adresses ;
- L'acheminement des données sur le réseau (routage) ;
- Le contrôle des erreurs de transmission de données.
Pour comprendre le fonctionnement de cette suite de protocole, nous allons prendre un exemple classique d’une conversation téléphonique
Martin veut transmettre un message à Toma.
- Il compose donc son numéro de téléphone et il peut entendre la tonalité (tuuuut... tuuuuut...). Il attend que Toma décroche, car la communication ne peut avoir lieu qu'à ce moment-là. Toma, 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 Martin peut maintenant dire à Toma ce qu'il a en tête. Il va donc gentiment se présenter : « Salut, c'est Martin… » 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 à Akwa ». Toma peut éventuellement demander à Martin de répéter, pour être sûr d'avoir bien saisi son message : « Chez qui ? Anne qui ? ». Alors Martin répétera cette partie pour que Toma comprenne. Finalement, la conversation terminée, 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 en réseau.
Citation : Martin veut transmettre un message à Toma.
Il compose donc son numéro de téléphone et il peut entendre la tonalité (tuuuut... tuuuuut...). Il attend que Toma décroche, car la communication ne peut avoir lieu qu'à ce moment-là.
L'hôte Martin, à l'adresse IP 124.23.42.13, souhaite communiquer avec l'hôte Toma à 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 Toma 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 Toma décroche en disant « Allô »
4. Le numéro est correct, disponible, mais Toma ne décroche pas (c'est donc un peu comme le cas 2
Étudions ces cas :
Cas 1 : Martin aura un message vocal disant « Le numéro que vous avez composé n'existe pas ». En réseau ce sera un ICMP packet (Internet Control Message Protocol) qui enverra une erreur de type 3 (destination unreachable, destination inaccessible) et de code 7 (Destination host unknown, destinataire inconnu).
ICMP est un protocole dans la suite protocolaire TCP-IP utilisé pour envoyer des messages d'erreurs dans un réseau. Il travaille en partenariat avec le protocole IP.
Cas 2 : Ici, un message vocal dira à Martin « 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 Toma 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 Toma 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 Martin 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.
Citation
« C'était juste pour te dire que demain, il y aura une fête chez Anne-Sophie, qui habite Akwa ».
Toma peut éventuellement demander à Martin de répéter, pour être sûr d'avoir bien saisi son message « Chez qui ? Anne qui ? ». Alors Martin répétera cette partie pour que Toma comprenne.
Si Toma demande à Martin de répéter quelque chose, de façon radicale on peut conclure qu'il n'a pas reçu ce que Martin a dit (si l'on considère que recevoir un message = comprendre le message). En réseau, l'hôte Toma va envoyer un paquet à Martin disant « je n'ai pas reçu le dernier paquet, renvoie-le stp ». Martin 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, Martin peut demander à la fin de chaque phrase si Toma a compris. En réseau, l'hôte Martin pourrait donc demander un message d'accusé de réception à chaque envoi de paquet, et l'hôte Toma 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 (non orienté connexion.
Qu'est-ce qui se passe, si Martin se met à raconter sa vie à raconter une histoire à Toma et que ce dernier dépose le combiné et s'en va faire un tour aux toilettes sans prévenir ? Martin aurait perdu son temps en parlant pour rien ! Pour prévenir ce genre de chose, Martin peut vérifier la présence de Toma 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 Martin enverra un paquet de « vérification de session » pour savoir si l'hôte Toma est toujours connecté. Si Toma ne répond pas après un certain laps de temps, la communication est terminée (la session se termine là).
Citation
Finalement, la conversation terminée, il faut se séparer 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.
Cette illustration décrit le fonctionnement des réseaux suivant le modèle TCP/IP ainsi on a le schéma suivant :
Lors d'une transmission, les données traversent chacune des couches au niveau de la machine émettrice. A chaque couche, une information est ajoutée au paquet de données, il s'agit d'un en-tête, ensemble d'informations qui garantit la transmission. Au niveau de la machine réceptrice, lors du passage dans chaque couche, l'en-tête est lu, puis supprimé. Ainsi, à la réception, le message est dans son état originel...
A chaque niveau, le paquet de données change d'aspect, car on lui ajoute un en-tête, ainsi les appellations changent suivant les couches :
- Le paquet de données est appelé message au niveau de la couche Application
- Le message est ensuite encapsulé sous forme de segment dans la couche Transport
- Le segment une fois encapsulé dans la couche Internet prend le nom de datagramme
- Enfin, on parle de trame au niveau de la couche Accès réseau