J'ai rédigé récemment un post indiquant les pré-requis réseaux à avoir pour passer la certification PNPT, pour ceux qui ne l'ont pas vu, il est juste ici
En le rédigeant, je me suis dis que les notions abordées étaient vraiment importantes et qu'il fallait aller plus loin dans la description de celles-ci. C'est pourquoi je rédige aujourd'hui ce post sur les protocoles TCP et UDP.
Quick Rappel : Le modèle OSI
Juste un petit rappel sur le modèle OSI, j'en parlais dans mon post précédent comme étant un modèle de communication qui se veut comme un standard auprès des différents construire afin de fournir un système de communication interopérable.
Il s'agit d'une structure formée de 7 couches distinctes qui sont les suivantes :
Couche Physique
Couche Liaison de Données
Couche Réseau
Couche de Transport
Couche de Session
Couche de Présentation
Couche d'Application
Chacune de ces couches a pour finalité la fourniture d'un service propre et dispose à cette fin d'un ensemble de mécanismes et de protocoles qui leurs appartiennent.
C'est dans ce cadre qu'apparaisse TCP et UDP. Il s'agit de deux protocoles appartenant à la couche de transport qui a pour rôle d'établir des canaux de communications entre deux interlocuteurs qui communiquent ensemble sur un réseau.
Connecté et fiable : TCP
Dans les communications en général, il est préférable lors d'échanges de messages que ceux-ci arrivent bien à destination et quand ils arrivent qu'ils soient exempt de toute corruption. Ca ne date pas de l'ère des réseaux informatiques, mais en tout temps, l'homme dans ses communications a toujours cherché des moyens pour fiabiliser la restitution de l'information et que si il y'a nécessité de passer par des intermédiaires, ceux-ci ne puisse pas modifier le message.
Les échanges réseaux n'échappent pas à la règle et c'est pour cela que TCP intervient. De son nom complet, Transmission Control Protocol ou Protocole de contrôle de transmissions en Français, on voit bien la volonté derrière ce nom de fournir un moyen de contrôler les transmissions.
Alors concrétement, comment ça fonctionne ?
Tout d'abord, il s'agirait de voir à quoi ça ressemble concrétement. Si tu regardes une en-tête TCP, tu peux voir un certain nombre d'informations.
Sur la capture d'écran ci-dessus tu peux voir un exemple d'en-tête TCP que j'ai capturé via le logiciel Wireshark. Au niveau de cet en-tête, on peut identifier différentes informations :
Le port source : Ici le port à partir duquel mon PC a contacté le serveur
Le port destination : Le port ciblé par mon PC, ici le port 443 puisqu'il s'agit d'une connexion Web via le protocole HTTPS.
Le numéro de séquence
Le numéro d'acquittement
Des Flags : Permet d'ajouter des informations de contexte à la communication. Ici, on peut voir que le flag SYN est levé, ce qui indique une demande d'établissement de connexion.
Orienté connexion : On dit de TCP qu'il est orienté connexion, c'est à dire, qu'à tout moment un canal de communication va exister entre deux interlocuteurs. Les deux extrémités de ce canal sont symbolisés par des ports réseaux derrière lesquelles des services vont être à l'écoute. Les exemples les plus courants de ports réseaux sont ceux liés à la navigation Web avec les ports 80 et 443.
Au moment de l'initialisation de la connexion, le protocole TCP met en place ce qu'on appelle un "Three Way Handshake", il s'agit d'un échange entre le client et le serveur pour permettre justement d'ouvrir un canal de communication entre les deux tiers.
Ce "3-way handshake" est symbolisé par l'échange de 3 paquets réseaux spécifiques à cette séquence qui utilise justement les flags TCP et en particulier les flags SYN et ACK.
Paquet 1 : Le client envoi une demande au serveur.
Dans le premier paquet qui part, le client veut faire une requête au serveur. Dans le cas d'un serveur web avec des flux HTTPS, le service web écoute les requêtes sur le port 443. Cependant, puisqu'on utilise le protocole TCP, avant tout envoie de données il est nécessaire d'ouvrir la connexion, le client demande alors au serveur en lui envoyer un paquet SYN de demande d'ouverture de session.
Paquet 2 : Le serveur répond au client.
Suite à cette demande, si le serveur peut répondre au client, il lui répond par un paquet dans lequel il lève les flags SYN,ACK.
Le flag ACK est utilisé tout au long de la connexion, que ce soit par le client ou le serveur, pour indiquer que les données ont bien été reçu et qu'il est prêt à recevoir d'autres données. Dans le cas du "3-Way handshake", il s'agit pour le serveur d'indiquer qu'il a bien reçu la demande d'ouverture de session par la combinaison de l'ACK au SYN.
Paquet 3 : Le client confirme au serveur et se prépare à envoyer les données
A la réception du paquet de confirmation du serveur, le client confirme à son tour qu'il a bien reçu la validation d'ouverture de session et qu'il est prêt à envoyer des données. Cela se traduit par un nouveau paquet marqué d'un flag ACK.
A partir de ce moment, le canal est considéré comme étant ouvert et les échanges de données vont alors pouvoir commencer.
On notera dans les captures d'écrans précédentes les valeurs des champs Sequence Number et Acknowledgment number. Ces champs que j'ai mentionné mais que je n'ai pas expliqué ont pour rôle de permettre la synchronisation des envois de données entre les deux tiers.
Lors du "3-way Handshake", le client et le serveur définisse un numéro de Sequence Number initial, en l'occurence dans les captures ci-dessus 0, qui marque le début de la communication. Ce numéro sert de référence aux deux interlocuteurs pour savoir quelle quantité de donnée a été envoyée. De même, l'Acknowledgment Number permet à chacun de savoir quel est la quantité de donnée que le destinataire a reçu.
Si on reprend l'exemple ci-dessus, lors du paquet SYN n°1, le client indique un sequence number de 0 et un acknowledment number de 0 (ce qui est logique puisqu'il n'a encore rien reçu). Le serveur lui répond alors avec un sequence number de 0, car il n'a pas encore envoyé de données auparavant, et un ack number de 1. Le paquet ACK n°3 du client fait de même en incrémentant le sequence number à 1 et son ack number à 1.
Pourquoi un incrément de 1 ? Pourquoi pas 42 ? L'incrément est lié à la taille du segment TCP qui est transmis et plus globalement au nombre d'octets transmis au cours de la communication.
Si je prend un nouvel échange, un peu plus avancé dans le flux TCP, je peux voir que mon client marque son sequence number à 763, ce qui indique que 763 octets ont été envoyés depuis l'ouverture de la session, soit depuis le "3-way handshake".
Petit exercice maintenant, si on part du principe que le sequence number est la quantité de données envoyées jusqu'à présent, puisque mon segment TCP fait 170 octets, quel sera le acknowledgment number du paquet que le serveur enverra lors de la réception de mon paquet ?
La réponse est 933 ! Soit 763, la quantité de données reçue par le serveur au préalable + 170 la quantité de données envoyée dans le dernier segment !
Pour les plus clairvoyants, la réponse était aussi marqué dans le champ Next Sequence Number. Il s'agit de la logique inverse, le client a envoyé 763 octets + 170 qu'il va à présent envoyer.
C'est bon je ne t'ai pas perdu ? En résumé, ce fonctionnement est indispensable à la fiabilité de la communication car il permet aux deux interlocuteurs de déterminer si les données ont bien été reçues par le destinataire et si il peut continuer à en envoyer ou le cas échéant, renvoyer les données qui n'auraient pas été reçues. Bien sûr, il ne s'agit pas des seuls mécanismes existants, on peut aussi parler de la somme de contrôle qui permet de s'assurer de l'intégrité d'un segment ou encore du RTT qui permet d'estimer le temps au bout duquel un segment est considéré comme perdu et doit être retransmis. Néanmoins, à mon sens, les deux processus décrits sont les plus importants et leur compréhension permet de résumer en grande partie ce que fait TCP.
UDP ou la loi du Best-Effort
D'un côté on a TCP qui est très codifié dans sa mise en oeuvre et de l'autre on a son petit frère rebelle UDP, User Datagram Protocol, qui est beaucoup plus simple dans la mise en oeuvre.
Ici, pas de poignée de main secrète, de retransmission ou d'acquittement de réception, UDP se veut simple et rapide à mettre en oeuvre. C'est d'ailleurs par la rapidité qu'il apporte qui a fait de UDP un protocole majoritairement utilisé aujourd'hui pour des flux de communications pour lesquels on ne se soucie pas vraiment de si le segment arrive pourvu qu'il arrive vite quand tout va bien.
Tu l'auras compris, UDP n'est pas considéré comme fiable mais est considéré comme un protocole qu'on dit de "Best Effort". Pour autant, des protocoles largement utilisés reposent sur UDP, le protocole DNS ou le protocole DHCP, deux protocoles utilisés tous les jours reposent entièrement sur UDP.
Comme un exemple vaut mieux que milles mots, je te laisse voir la capture suivante :
Beaucoup plus lisible n'est ce pas ? Ici pas de flags, pas de sequence number...Simple et efficace, les seules informations contenues dans l'en-tête sont les ports concernés, la taille du segment, une somme de contrôle pour quand même vérifier l'intégrité du segment et c'est tout ! Et c'est aussi valable pour la réponse, pas de fioritures.
Tu vois l'idée ? Best-Effort ! Les interlocuteurs ne se soucient pas de la bonne réception du message par les destinataires, la seule chose qui importe c'est que le message arrive rapidement ! C'est pourquoi UDP est utilisé pour DNS, DHCP ou encore pour a VoIP ou le ToIP. Dans le cadre d'une visioconférence, les logiciels sont conçus pour se permettre la perte d'un ou plusieurs paquets, du moment que cela reste raisonnable, l'information dans sa globalité peut être transmise dans tous les cas et cela en temps réel avec la voix qui arrive sans que la phrase de son interlocuteur ne soit saccadée.
Ima.....gi.....nez........si........au....té.....lé...pho.ne....c'....ét...ait.....com....me....ça
Conclusion
Voilà qui vient conclure ce post, j'espère t'avoir fais tenir jusqu'au bout, enfin ça doit être le cas si tu lis cette conclusion. Comme tu as pu le voir, TCP et UDP sont des protocoles qui ont chacun leur utilité et leur rôle au quotidien. L'un fiable et connecté mais plus lent permet de garantir un transfert intégre des données dans leur totalité. Le second, plus rapide mais moins fiable, permet de transmettre des données en temps réel.
Comments