Accueil

Bannière

#11 Script : Les protocoles réseaux (IP/UDP/TCP)

Qu'est ce qu'un protocole? Ou quelles sont les significations de IP, UDP ou de TCP?

Tags : script podcast

Salut! Vous êtes prêt pour cet épisode? Aujourd’hui le programme va un peu changer. En effet cet épisode est sponsorisé par Raid Shadow Legends! C’est pas vrai. Mais le sujet a été choisis par PofMagicfingers, encore merci pour son don! Et aujourd’hui on va parler technique, on va parler de trois protocoles en particulier, l’IP, l’UDP et le TCP! Vous ne le savez peut être pas mais vous utilisez ces protocoles tous les jours ou presque. On commencera par parler de la notion de protocole, ensuite ce sera au tour de l’IP, après ça on évoquera le protocole UDP, puisqu’il est plus simple à comprendre, et on enchaînera par le TCP.

Déjà commençons par expliquer un peu qu’est ce qu’est un protocole et pourquoi il est important d’en avoir. En gros un protocole c’est un ensemble de règles fixées pour permettre la transmission d’information. La langue française est techniquement un protocole, puisqu’il existe des règles de tournure de phrases (la grammaire), des règles sur comment doivent êtres écrites les informations (l’orthographe), etc. Et sans cette langue, on ne pourrait pas échanger des informations entre nous. Et bien en informatique c’est pareil! Pour pouvoir échanger entre programmes, logiciels ou autre et bien il faut des règles. Des règles sur comment encoder, décoder ou transmettre ce que l’on souhaite. Et aussi, les protocoles sont là pour qu’on ai pas à réinventer la roue à chaque fois qu’on doit faire quelque chose, et pouvoir choisir le protocole le plus adapté à nos besoins.

Autre notion importante à évoquer avant de parler d’UDP et de TCP est le protocole IP (pour Internet Protocol). Celui là est le fondement même de la notion de réseau en informatique. Quand on est dans le domaine des ordinateurs, on aime bien avoir des choses uniques, facilement identifiables, pour pouvoir retrouver facilement ce dont on parle. IP est là pour ça. Il nous donne le moyen d’identifier facilement le destinataire d’un message, en identifiant à quel réseau il appartient, et ensuite dans ce réseau à quel machine il correspond. C’est un protocole complet et complexe, qui permet par exemple d’imbriquer des réseaux entre eux, ou cote à cote. Les adresses IP ont plusieurs versions (IPv4 et IPv6)... Mais je ne vais pas plus rentrer dans les détails. Je vais juste parler des bases d’IPv4 puisque c’est le plus répandu, mais IPv6 fonctionne sur le même système.

En gros une adresse IPv4 est composée de 4 octets, c’est à dire 4 “bloc de 8 éléments pouvant être 0 ou 1, en binaire. En notation décimale, cela veut dire une valeur entre 0 et 255. Ces 4 octets sont séparés par un point. Par exemple 127.0.0.1, 10.0.32.64 ou au hasard 45.234.73.123. Cette adresse va être définie à chaque fois par une machine, appelée routeur, qui gère le sous réseau, appartenant elle même à un sous réseau. Par exemple, votre fournisseur d’accès est un sous réseau d’internet, avec ses serveurs comme routeur, et votre box internet est un membre de ce sous réseau. Votre box, elle, va gérer le sous réseau de votre maison. Ca permet via un nombre limité d’adresse, d’en augmenter vraiment beaucoup le nombre. Et pour finir par une image, avant qu’on rentre dans le coeur de l’épisode, vous habitez dans un immeuble, et on vous envoie une lettre, et bien cette lettre va passer par un premier centre de trie qui le redirigera vers un autre centre de trie, et ainsi de suite, jusqu’à ce qu'il arrive dans votre immeuble où le facteur trouvera votre propre boite aux lettres à votre nom.

Et en vitesse avant de rentrer dans le ventre du sujet, je vais aussi parler du modèle OSI (pour Open System Intercommunication). C’est un modèle de traitement de données, composé de 7 couches qui permet de bien séparer les différentes étapes du transfert de données, en traitant les données couches par couche et en les imbriquant ensembles. Il y a la partie logicielle, comprenant les 4 premières couches. Cette partie permet de gérer la présentation de vos données (comment savoir quel type de données c’est, comment le décoder à la fin), la transformation de vos données en segments, qui pourront être transmis, ou encore la connection entre les machines et le contrôle du flux des données.

L’autre partie de ce modèle est la partie physique. Cette partie, gérée automatiquement par les composants de la machine, va s’occuper de chercher le parcours des données, le passage par les composants, et enfin leur transfert physique, envoyant des bits par le WiFi ou Internet. Mais vous allez me dire pourquoi autant de complexité. C’est le même principe que pour les protocoles : pour simplifier et ne pas avoir à réinventer la roue à chaque fois. Imaginez vous codez un site internet et vous avez besoin de chercher des données. Est-ce que vous voulez à chaque fois avoir à contrôler la connection au serveur, et même le contrôle de la carte réseau? Et bien c’est grâce à ce modèle que vous n’avez pas à le faire, puisque vous allez utiliser des protocoles de haut niveaux, facilement accessible, qui eux vont se débrouiller pour interagir avec des protocoles plus bas niveaux et complexes, qui eux à leur tour vont aller chercher du côté des composants.

Modèle OSI

Par OffnfoptTravail personnel, Domaine public, Lien

Je vous mettrais de toute manière dans la description un lien vers la page Wikipédia du modèle OSI, si ça vous intéresse. Mais pour résumer vos données quand vous allez les envoyer depuis votre application, elles vont passer par votre protocole de présentation, qui va les transformer et les mettres dans une boite, ensuite le protocole de transport va venir mettre une boite encore autour et gérer les échanges, pour que finalement vos composants envoient ces boîtes transformées au travers du réseau physique.

Et… Voilà, maintenant que le point est fait sur la notion de protocole et sur le principe des IP, on va commencer à rentrer dans l’incompréhension du sujet avec l’UDP (pour User Datagram Control). L’UDP va se baser sur le protocole IP et arrive (tout comme TCP) à la couche 4 du modèle OSI, c’est à dire la partie Transport. Il est considéré comme un protocole Non Fiable, puisqu’il n'inclut aucune vérification de la bonne arrivée des données, ou de leur ordre, mais c’est cette absence de vérification qui le rends plus rapide que des protocoles comme TCP. Il va donc surtout être utilisé pour de simple échanges à base de questions réponses rapides, comme le principe des DNS. Sa rapiditée d’action en fait aussi un protocole privilégié pour les systèmes de visio et audio conférences par internet, pour les jeux en ligne, ou encore pour tout ce qui est streaming en direct de vidéo ou d’audio. En effet dans chacun de ces cas, si on perd quelques données c’est pas grave, mais il faut que ça aille vite. C’est pour ça que le son ou l’image d’une visio conférence peut parfois avoir des coupures lorsque la connexion est mauvaise : une partie des informations a été perdue au passage. Et enfin, le protocole UDP est utilisé quand on a besoin d’envoyer un message à plusieurs personnes, comme dans le cas d’un système de streaming audio, ou en informatique avec un broadcast.

Utilisant le protocole IP, le protocole UDP apporte à la communication entre les ordinateurs le système des ports, très utile! Puisque avec IP votre ordinateur est identifié de manière unique, il faut aussi identifier l’application à laquelle on s’adresse! Et c’est là l’objectif des ports. Je crois que j’en avais déjà parlé mais je vais refaire un point au cas ou. Chaque port est associé à une application en particulier et est codée sur 16 bits (soit entre 0 et 65535). Certains d’entre eux sont réservés (c’est a dire connu et reconnus pour une application en particulier), comme 80 pour tout ce qui est serveur web, 22 pour les connections en SSH ou 53 pour les serveurs DNS. Donc à partir de là vous pouvez spécifier en particulier à quel application vous vous adressez. Pour reprendre mon image d’avant avec l’immeuble, maintenant le facteur c’est exactement à quel appartement emmener la lettre mais aussi à quelle personne et dans quelle pièce !

Maintenant parlons un peu du fonctionnement technique d’UDP! Vous allez voir c’est plutôt simple. On va avoir un émetteur et un récepteur. L'émetteur veut envoyer un message au récepteur. On va commencer des deux côtés par créer un socket, c’est à dire le programme qui va gérer ces échanges, auquel on va associer l’adresse à laquelle on souhaite envoyer le message. Du côté du récepteur, on va alors dire le port qu’il va falloir écouter. Maintenant l'émetteur va envoyer ses données, sans se soucier de si elles arriveront ou pas et dans quel ordre, et le récepteur va écouter le port, et récupérer toutes les requêtes arrivant à cet endroit là. Et quand on a terminé, on ferme les sockets des deux cotés.

Il est important de préciser aussi que un port ne peut être lié qu’à une seule application. Si plusieurs applications essaient d’écouter le même port, on aura le droit à une belle erreur annonçant que le port est déjà utilisé. Par contre une application peut bien sûr utiliser plusieurs ports. Et information supplémentaire, un port représente une file d’attente, dans laquelle vont être placées les messages qui arrivent, si il y a de la place dedans. Si le port n’est pas ouvert, alors le message entrant va être détruit et un message va être renvoyé à l'émetteur, si il n’y a plus de place, il va juste être détruit. Le programme récepteur va simplement lire les paquets les un après les autres. Pour mettre en place un système de requêtes avec réponse, chacun des programmes va ouvrir un port à l’écoute, et envoyer ou recevoir des requêtes à tour de rôle. Si on veut juste envoyer un message dans un seul sens, pas besoin de s'embêter ! On envoie et on ferme la connexion.

Tout ceci conclut la partie sur UDP, il est temps de complexifier encore un peu la chose, avec le protocole TCP. Tout comme le protocole UDP il utilise le protocole IP pour savoir à qui il envoie, mais il vient ajouter quelques améliorations par rapport à UDP. Déjà il peut détecter si il y a eu des pertes lors de l'envoi, il va ensuite pouvoir les corriger, et enfin contrôler le flux pour qu’il arrive dans le bon ordre. Il va surtout être utilisé pour pleins de choses liés à Internet. HTTP et HTTPS se basent dessus, SMTP qui est utilisé pour les emails se base dessus, et aussi FTP qui est utilisé pour les échanges de fichiers est basé sur TCP.

Mais du coup comment fonctionne ce système de sécurisation? Et bien il est basé sur un système de question réponse. L'émetteur va envoyer un message, et attendre de recevoir un message d'acquittement de la part du récepteur. Si il ne le reçoit pas avant un certain temps, il renverra alors le même message. L’erreur pouvant subvenir durant le transport du message ou durant le transport de l'acquittement, l'émetteur va renvoyer le message sans distinction. C’est pour ça que dans chaque message est présent le numéro du segment du message, et quand le récepteur renverra l'acquittement, l’émetteur transmettra le prochain segment attendu.

Mais vous allez me dire “Attendre de recevoir à chaque fois l'acquittement ça doit être pas super efficace?” Et je vous répondrais! Bah oui, bien sûr que oui. C’est pour ça qu’il existe le principe de fenêtre glissante de transmission. En gros l'émetteur ne va pas envoyer juste un segment à la fois, mais plusieurs segments de la taille de la fenêtre en gros. Donc si notre taille de fenêtre est de 3, l’émetteur va envoyer 3 segments, et attendre de recevoir les confirmations. Mais la petite invention, c’est qu’il ne va pas attendre les 3 confirmations, mais attendre de recevoir la première, puis envoyer le segment 4… Si il reçoit la seulement confirmation pour le 2 et le 3, il va reessayer le 1, et quand celui ci sera confirmé, il passera de suite aux segments 4 5 et 6. C’est très inventif! Et très efficace. Mais là on parle d'envoi de message, mais on a pas encore parlé de comment se faisait la connection et la déconnection! Et oui, parce que par rapport à l’UDP qui est sans connection, là nous somme avec une connection obligatoire ! Et il y a donc une méthode précise à mettre en place. On va tout d’abord faire comme pour l’UDP et mettre le récepteur en écoute passive sur un port. L'émetteur va envoyer un premier signal de synchronisation qui va demander au serveur d’établir une connection. Ce à quoi le récepteur va répondre par un signal d'acquittement et de synchronisation. Et enfin l’émetteur va renvoyer un signal d'acquittement, à la suite duquel la connection sera effectivement établis.

Au niveau de la déconnexion c’est tout aussi compliqué! L'émetteur va commencer par envoyer un signal demandant la fin de la connection, signal auquel va répondre le récepteur par un signal d'acquittement. Quand l'émetteur reçoit ce signal, il sait qu’il ne doit plus envoyer de message, puisque le récepteur ne va pas tarder à couper la connection. Après un petit moment, qui laisse le temps à des derniers messages d’arriver, l'émetteur va envoyer un signal de fin auquel le récepteur va répondre un signal d'acquittement, et voilà la connection est coupée!

Comme vous aurez pu le remarquer, le protocole TCP est bien plus compliqué mais c’est cette complexité qui le rend beaucoup plus sûr au niveau des transports des données. Durant cet épisode j’ai pas mal survoler certaines choses comme les explications techniques des trames, en bit à bit, ou certains problèmes liés au TCP comme le syndrome de la fenêtre stupide. C’était fait exprès, puisque c’est le genre de choses techniques qui peuvent vraiment perdre des gens, surtout sur un format exclusivement audio.

Pour conclure cet épisode, j’aimerais aussi rappeler quelque chose. Les protocoles qu’on a vu là maintenant, il y a peu de chance que vous les manipulez directement comme ça, à la main. En effet soit vous allez juste choisir un protocole de présentation, plus simple à utiliser, et qui lui tout seul va choisir ce protocole de transport, soit vous allez utiliser des bibliothèques qui font ça tout seul. Il y a seulement dans quelques langages de bas niveau comme le C où on fait vraiment ça à la main, mais pour le faire comme ça c’est soit parce que tu es maso, soit par principe pédagogique.

En tout cas j’espère que cet épisode vous aura plus et intéressé. Je me suis moins attardé sur l’histoire, pour laisser de la place au côté technique. Je vous laisse comme d’habitude mes sources en description, et en parlant de source je voudrais remercier mon prof de réseau, M.Wemmert, qui m’a donné l’autorisation d’utiliser son cours d’amphi, que j’avais suivit en début d’année. Ce cours était ma source principale pour cet épisode.

Je voulais aussi remercier les personnes qui m’ont aidés à relire cet épisode, pour pas que je dise trop de conneries, et pour voir si j’étais bien clair, à savoir Pof et Mankoty. Merci encore à Pof pour son don et cette idée de sujet bien technique mais bien intéressante. Pour le prochain épisode on parlera enfin du JavaScript, ça fait bien longtemps que je devais le faire. Comme d’hab, vous pouvez vous abonner au podcast sur plus ou moins toutes les plateformes, et même YouTube, vous pouvez aussi me suivre sur Twitter @Bigaston, et me soutenir financièrement sur utip.io/Bigaston ! Je vous souhaite une bonne soirée ou journée! Et au mois prochain!

🔗 Les liens

Licence Creative Commons

Publié le 24/06/2020