Salut tout le monde !

Ce soir, je ne vous propose rien d’innovant, mais juste un partage d’une de mes conceptions que je trouve plutôt cool de la semaine dernière. En effet, nous avions du faire un exposé de vulgarisation scientifique, sur le thème (pour mon groupe) de TCP et UDP. Comme j’avais pas envie de me casser le cul pendant tout un week-end pour 12 minutes 31, j’ai décidé de le rendre publique o/ En plus, il pourra faire comprendre des choses à des gens, et peut être éviter à d’autres cancres de faire le même boulot en leurs permettant de me plagier 🙂 .

TCP / UDP : Pour les nuls

Je vous propose aussi ce texte explicatif qui illustre à peu près le contenu des slides :

Bonjours à tous !

Nous sommes Jean, Kevin et Steve, et nous allons vous parler aujourd’hui des méthodes utilisées pour communiquer sur internet.

Nous n’allons pas vous parler des langages utilisés, mais plus de la façon dont ces différents langages arrivent d’un ordinateur à l’autre.

À titre de comparaison avec la vraie vie, les protocoles TCP/UDP sont à Internet ce que l’air, ou le téléphone est à la parole.

En gros, nous allons pas vous apprendre comment parler en français ou en chinois avec votre voisin, mais plus les procédés physiques mis en œuvre pour que le son émis par votre bouche arrive bien dans son oreille.

Pour commencer, il est bon de faire une petite présentation d’internet :

Pour que les ordinateurs communiquent ensemble, ils s’échangent des paquets de la même façon que pour que deux personnes parlent ensemble, elles s’échangent des mots.

Quand de chez nous, on décide de « parler » à Facebook, plusieurs paquets de données sont transportés de notre ordinateur, dans notre maison, à l’un des serveurs de Facebook, en Californie.

Hé oui, généralement, des milliers de kilomètres sont parcouru par chaque octet envoyé sur internet. Et celui-ci, pour arriver à destination doit emprunter plusieurs routes différentes.

Par exemple notre paquet, envoyé de l’IUT à Facebook passera de mon ordinateur à la « gare » du campus d’Illkirch, puis est envoyé à l’Esplanade, pour arriver à Nancy, ensuite à Paris, Limoges, à Lucerne en Suisse, à Hessen en Allemagne, puis passe dirrectement en Californie pour rejoindre un serveur Facebook !

De la même façon que pour rejoindre la Californie en voiture, le paquet dispose d’une infinité de chemin différent, et il n’est pas rare qu’un paquet face plusieurs fois le tour du monde avant d’enfin atteindre sa destination.

Pour compléter notre personification d’Internet, on peut comparer la conversation avec Facebook à une partie de téléphone arabe : chaque changement de route est effectué par un « routeur ». C’est lui qui décide, à la réception d’un paquet, vers quelle route le réenvoyer.

Dans ce cas, on peut dire que le routeur répète le contenu du paquet qui arrive à un nouveau routeur, au quel il l’envoie, de la même façon qu’une personne répète à une autre ce qui lui a été dit.

En plus de ça, le bruit électromagnetique présent dans le suport de communication parasite la transmission, il peut s’agir d’une autre source électrique à côté du câble dans le quel passe le packet, ou bien l’émission d’une autre onde radio dans le cas des transmitions aérienne (une communication satelite, ou par wifi par exemple).

L’effet provoqué par ces interférances est le même que celui du bruit auditif pendant une conversation : le récepteur risque de mal comprendre ce qui a été dit.

Vu comme ça, on comprend qu’il faille mettre au point un système de vérification au niveau des paquets pour que nos entités s’assurent que la transmition aie bien eu lieu correctement : c’est le role du paquet de type TCP.

En effet, celui-si se charge de faire en sorte que chaque paquet soit bien reçu, dans son intégralité, et que l’ordre de réception des paquets et le même que celui d’envois.

Hé oui ! Pour communiquer correctement, avec la parole, nos mots forment des phrases. C’est ces mots, et notamment leur ordre qui apportent un sens à la phrase.

En effet, si les mots seraient mélangés alléatoirement dans une phrase, on aurrait asser de mal à comprendre l’information qui en dégage.

Il en est de même avec les paquets : si l’éméteur envois par exemple dix paquets, il peut être important que ces paquets arrivent dans l’ordre.

La méthaphore entre la transmition des paquets et la parole n’a pas de sens pour présenter le risque de « doublage », mais celle de notre voiture en route pour Californie le conserve pleinement : en effet, une multitude de routes différentes existent pour relier notre point de départ et la Californie, la deuxième voiture (partie après la première) aura donc toutes les chances d’arriver en premier, si celle-ci utilise des chemins plus cours ou plus rapide.

Un autre problème réside dans la diférence de puissance entre l’émetteur et le récepteur. Que se passe t-il si, par exemple, l’émetteur envois des parquets tellement rapidement sur le réseaux que seul la moitier d’entre eux sont lu par le récepteur parce qu’il n’arrive pas à suivre ?

Ou si les lignes sont saturer par les autres utilisateur et que du coup, la bande passante disponible ne permet pas d’envoyer à pleine puissance ?

Chacun de ces deux problèmes possède sa solution respective :

Le premier problème, celui de l’intégrité du paquet s’effectue simplement en demandant au récepteur de dire « ce qu’il a compris » du message qu’il vient de recevoir avant de répondre.

Si ça ne correspond pas, le récepteur renvois le paquet en espérant que cette fois ci, l’envois se déroule sans encombre.

Bien sûr, il est possible que le récepteur aie bien compris le paquet, mais que la réponse elle, subit des modifications dans le réseau, dans ce cas, le paquet est évidement renvoiyé, vu que le récepteur pensera que celui-ci ai été mal compris.

Maintenant, deux questions devraient être en supsen dans votre esprit. En effet, comment dire au récepteur qu’il a mal compris un paquet, et qu’il doit prendre une nouvelle version en considération ? Et comment faire si des paquets sont carrément perdu et qu’aucune « confirmation » n’arrive chez l’émetteur ?

En fait, au niveau de l’emmeteur, pas grand chose : si celui-ci a ure confirmation érronée sur le contenu du paquet, ou même pas de confirmation du tout, il renvoit le paquet.

Le problème consiste à faire comprendre au récepteur que le nouveau paquet qui arrive, n’en est en réalité pas un, mais est le même que l’ancien, l’erreur en moins.

Sur internet, on aime faire les choses simple. C’est pour cela que la solution choisie sera en fait… de numéroter les paquets !

Si le destinataire reçois les paquets 1, 2, 3, 4, 4, il saura que la première version du paquet 4 n’est plus à conserver, et le remplacera par le dernier paquet 4 arrivé.

De même, si la suite des paquets entrant est 1, 2, 4, il saura qu’en fait un paquet a été perdu sur la ligne, vu que le paquet numéro 3 sera manquant.

Le second problème réside dans notre problème de capaciter du réseau : que faire si la ligne est saturée ou bien que le destinataire n’arrive pas à suivre ?

C’est pas bien compliquer après tout, la seule solution est pour l’émetteur d’envoyer les paquets moins rapidement.

Le vrais défit qui doit troner dans votre tête, c’est plutôt de ce demander comment l’émetteur ferait pour savoir qu’il y a des problèmes de ce genre.

Encore une fois la réponse est simple : On a vu que chaque paquet nécessite une confirmation de la part du récepteur, si il manque la moitier des réceptions, on admetra que le récepteur n’arive pas à suivre, et qu’il perd des paquets, si les confirmations arrivent lentement, on déduira que le réseau est saturé.

On voit bien que ce système permet une communication très fiable entre deux ordinateurs. Le risque d’erreur est vraiment très faible, et les paquets TPC sont utilisés pratiquement par tout, surtout dans les applications ou les données doivent être très fiables, comme les emails,ou bien le chargement des pages internet, par exemple.

On remarque également que le procédé mis en place est plutôt lourd : vérifier les paquets, renvoyer en cas de besoin, etc. Ça fait perdre du temps pas négligeable dans certains cas.

Pour cela, le protocole UDP a été créer ! Il s’agit en fait d’exactement l’inverce de TCP :

Un paquet UDP n’a aucune garantie d’arriver à destination, et encore moins d’arriver dans l’ordre d’emission. En fait l’application source se charque d’envoyer le paquet sur le réseau, et le destinataire d’écouter pour capter, au hasard certains paquets : c’est le même principe que la poste : l’emmeteur envois un courrier à la poste, et le récepteur se contente d’ouvrir la boite au lettre chez lui et de voir ce qu’il y a dedans.

Il ne saura pas dans quel ordre les paquets doivent être lues, et encore moi si ceux-ci sont tous présent.

De même qu’avec la poste, nous recevons dès fois des colis endommagés, ils ne sont pas remplacer par des nouveaux, il en est de même avec les paquets UDP.

Les paquets UDP sont utilisés quand le rapadité joue un rôle clef. Par exemple pendant une vidéoconférence, pendant que deux personnes se parlent ou pendant le jeu en réseau.

Il est en effet préférable d’avoir perdu quelques pixels lors d’un échange vidéo que d’avoir un retard de 10 secondes entre ce qui est fait par le correspondant et ce qui est vu.

Pour conclure, nous pouvons dire qu’Internet et un vaste réseau, dans le quel on est pas sûr que ce qu’on dit sera forcément bien compris par notre destinataire.

C’est pour cette raison qu’on a le choix entre deux « modes » de conversations : la conversation sécurisée, à l’aide de paquets TCP, ou des vérifications auront lieux pour savoir si le message a correctement été diffusé, et le paquet UDP qui privilégiera une vitesse de traitement plutôt qu’une qualité de conversation.

Les deux méthodes ont chacunes des utilisatiions différentes : TCP est à favoriser dans le cas de conversation fiable, et UDP en cas de conversation rapide.

😉