Le protocole TCP: La fiabilité avant tout

L’un des protocoles les plus emblématiques et les plus utilisés dans la couche de transport est le protocole TCP. Il est conçu pour fournir une communication fiable, ordonnée et sans erreur entre les applications situées sur les hôtes d’un réseau IP. Au cœur de son fonctionnement, TCP s’appuie sur les principes fondamentaux du protocole de transfert de données fiable que nous avions vu précédemment. Il utilise ainsi des numéros de séquence pour suivre l’ordre des segments de données, des acquittements pour confirmer la réception des segments, et des timers pour gérer les retransmissions. Il est à noter que TCP ne fait pas appel aux acquittements négatifs.

Ce qui distingue particulièrement TCP est sa capacité à établir une connexion avant d’envoyer des données. Cette négociation, appelée “handshake”, garantit que les deux extrémités de la communication sont prêtes à échanger des données et qu’elles sont d’accord sur les paramètres initiaux. En outre, pour gérer le flux de données et éviter la congestion, TCP utilise une technique appelée “sliding window”. Cette fenêtre glissante assure que les segments de données sont envoyés et reçus à un rythme acceptable pour les deux parties, ce qui contribue à optimiser les performances et à éviter les engorgements.

L’ouverture de connexion

La négociation de connexion, communément appelée “three-way handshake”, est un mécanisme fondamental du protocole TCP pour établir une connexion fiable entre deux hôtes. Ce processus garantit que les deux parties, à savoir l’émetteur et le récepteur, sont prêtes à commencer une communication et qu’elles ont convenu des paramètres nécessaires pour cette communication. Il s’agit d’une étape importante à réaliser avant le transfert de données, car elle assure que chaque hôte est conscient de l’intention de l’autre de communiquer et qu’ils ont convenu des paramètres nécessaires pour une communication fiable.

En termes simples, le “three-way handshake” peut être comparé à une poignée de main lors d’une rencontre entre deux personnes, où les deux parties confirment leur présence et leur intention de s’engager dans une conversation. Dans le contexte de TCP, ce processus est principalement un échange de messages qui confirme que les deux hôtes sont prêts et disposés à échanger des données. 

Détail des étapes du three-way handshake :

• SYN: L’hôte initiateur envoie un segment TCP avec le flag SYN activé pour indiquer qu’il souhaite établir une connexion. Ce segment précise également un numéro de séquence initial.
• SYN-ACK: En réponse, l’hôte récepteur envoie un segment avec à la fois les flags SYN et ACK activés. Ce segment confirme la réception du segment initial et propose également son propre numéro de séquence initial.
• ACK: Enfin, l’hôte initiateur envoie un segment avec le flag ACK activé pour confirmer la réception du segment SYN-ACK. À l’issue de cette étape, la connexion est établie, et les deux hôtes peuvent commencer à échanger des données.

Le three-way handshake de TCP est non seulement très important pour établir une connexion, mais aussi pour échanger des informations qui vont améliorer et optimiser la communication future entre les deux appareils. En d’autres termes, le three-way handshake de TCP permet non seulement d’établir une connexion fiable entre deux appareils, mais aussi de définir les paramètres de communication pour optimiser la transmission de données entre eux. Cela permet d’assurer une communication fiable entre les deux appareils. Les éléments échangés principaux sont les suivants.

• L’ISN est l’un des premiers éléments échangés lors du handshake. Chaque hôte génère un ISN pour la nouvelle connexion. Ce numéro servira de point de départ pour la numérotation des segments échangés pendant la session. L’utilisation d’un ISN généré de manière aléatoire (plutôt qu’un compteur séquentiel) est une mesure de sécurité destinée à empêcher certaines formes d’attaques.
• Le MSS est un paramètre qui indique la taille maximale des données qu’un segment TCP peut transporter. Le MSS est utilisé pour éviter la fragmentation des segments lors de leur transfert à travers le réseau.
• L’échange d’informations lors du handshake aide les hôtes à configurer le timer TCP de manière optimale, évitant ainsi des retransmissions prématurées ou tardives, pour garantir une communication fluide.

La fermeture de connexion

La négociation de fin de connexion est tout aussi importante que l’établissement initial de la connexion. Cela garantit que toutes les données en cours d’envoi sont correctement transmises et reçues avant que la connexion ne soit fermée. Pour orchestrer cette fin de connexion, TCP utilise un processus appelé “four-way handshake”.

Ce four-way handshake sert à assurer que les deux parties (émetteur et récepteur) sont mutuellement informées et d’accord pour mettre fin à la connexion. C’est une procédure nécessaire car, dans une communication typique, les deux parties peuvent ne pas être prêtes à terminer en même temps. L’une peut encore avoir des données à envoyer alors que l’autre est prête à clôturer. Grâce au four-way handshake, chaque partie peut demander de terminer sa connexion, garantissant ainsi que toutes les données sont correctement transmises et reconnues avant que la connexion ne soit complètement terminée.

Étapes du Four-way Handshake:

• FIN: Lorsque la partie initiatrice (souvent le client) est prête à mettre fin à la connexion, elle envoie un segment avec le drapeau FIN activé pour indiquer qu’elle a terminé l’envoi de données.
• FIN-ACK: La partie réceptrice (souvent le serveur) reconnaît la demande de fin de la partie initiatrice en envoyant un segment avec le drapeau ACK activé.
• FIN: Une fois que la partie réceptrice a également terminé l’envoi de toutes ses données, elle envoie son propre segment avec le drapeau FIN activé.
• FIN-ACK: Enfin, la partie initiatrice reconnaît la demande de fin de la partie réceptrice en envoyant un dernier segment avec le drapeau ACK activé. Après cela, la connexion est officiellement terminée et les ressources peuvent être libérées des deux côtés.

Le contrôle du flux

La technique de la fenêtre glissante, ou “sliding window”, est au cœur du mécanisme de contrôle de flux du protocole TCP. Elle permet de gérer l’envoi et la réception de segments de manière efficace tout en s’assurant que les données sont transmises de manière fiable et dans le bon ordre. La notion de fenêtre glissante fait référence à une plage de numéros de séquence valides à un moment donné pour l’envoi ou la réception de segments. Cette fenêtre représente l’ensemble des segments que l’émetteur est autorisé à envoyer sans attendre un acquittement et l’ensemble des segments que le récepteur est prêt à recevoir. Il existe deux variantes, la variante “go back n“, et la variante “selective repeat“. C’est cette dernière qui est utilisée dans TCP.

Dans le mécanisme de base de la fenêtre glissante avec “selective repeat”, chaque segment est individuellement acquitté. Si un segment est détecté comme manquant ou erroné, seul ce segment est retransmis, plutôt que tous les segments ultérieurs. Cela rend la retransmission plus efficace, car elle minimise la quantité de données devant être retransmises. De plus, cela permet au récepteur d’accepter et de traiter les segments reçus après un segment manquant ou erroné, plutôt que de les rejeter.

Pour que le “selective repeat” fonctionne correctement, le récepteur doit avoir une capacité de stockage pour les segments qui sont reçus dans le désordre, en attendant que les segments manquants ou erronés soient retransmis et reçus.

Observons l’illustration plus en détail :

1. L’émetteur envoie les trois premiers segments, à savoir M1, M2 et M3, simultanément au récepteur. Cela est représenté par les trois flèches bleues partant de l’émetteur vers le récepteur.
2. Le récepteur reçoit correctement le segment M1, puis M2 et M3 et envoie un accusé de réception pour chaque segment. Cela est illustré par les flèches vertes retournant vers le côté de l’émetteur.
3. Après avoir reçu l’acquittement pour M1, la fenêtre glissante de l’émetteur se déplace d’une place, permettant à l’émetteur d’envoyer le message M4. Juste après, il reçoit également les ACK de M2 et M3, débloquant la fenêtre pour l’émission des deux segments suivants : M4, M5 et M6. 

La taille de la fenêtre glissante, qui détermine combien de segments peuvent être envoyés avant d’attendre un acquittement, est dynamique. Elle peut s’adapter en fonction de la congestion du réseau et des retours d’information du récepteur. Si le réseau est libre et que peu d’erreurs sont détectées, la taille de la fenêtre peut augmenter, permettant un débit plus élevé. Inversement, si des erreurs ou des pertes de paquets sont fréquentes, la taille de la fenêtre peut diminuer pour réduire le risque de congestion.

Observons l’illustration plus en détail :

• Au départ, l’émetteur envoie le premier segment, M1, au récepteur. Le récepteur reçoit correctement le segment M1 et envoie un accusé de réception pour celui-ci.
• Une fois l’acquittement pour M1 reçu, la fenêtre glissante de l’émetteur se déplace et s’agrandit, lui permettant d’envoyer simultanément les deux prochains messages, M2 et M3. Le récepteur reçoit ensuite correctement les segments M2 et M3 et renvoie des acquittements pour chacun d’eux.
• Après avoir reçu les acquittements pour M2 et M3, la fenêtre glissante de l’émetteur se déplace et s’agrandit à nouveau, permettant l’envoi simultané des trois segments suivants : M4, M5 et M6.

Les différentes phases de TCP

La gestion de la fenêtre glissante dans TCP est un élément clé pour assurer un transfert de données fiable. Le processus comporte plusieurs phases destinées à équilibrer l’efficacité et la fiabilité: SlowStart, CongestionAvoidance et FastRecovery. Ces phases permettent de réguler la taille de la fenêtre de transmission pour s’adapter aux conditions du réseau, évitant ainsi la congestion et minimisant les erreurs.

La phase de SlowStart est la première étape dans le processus de contrôle de la congestion. Au début d’une nouvelle connexion, la taille de la fenêtre est initialement fixée à une petite valeur. À chaque accusé de réception reçu avec succès, la taille de la fenêtre est augmentée de 1, doublant ainsi presque la fenêtre à chaque tour complet de transmission et d’accusé de réception. Cela permet à la fenêtre de croître de manière exponentielle jusqu’à ce qu’un seuil prédéfini soit atteint ou qu’une perte de paquet soit détectée.

Après le SlowStart, le protocole entre dans la phase de CongestionAvoidance. À ce stade, l’objectif est d’augmenter la taille de la fenêtre de manière plus modérée pour éviter de saturer le réseau. Au lieu de doubler la taille de la fenêtre, celle-ci est augmentée de manière additive, généralement de 1 pour chaque tour complet sans incident. Ce processus (appelé TCP Reno) continue jusqu’à ce que la perte d’un paquet soit détectée.

Lorsqu’une perte de paquet est détectée à la suite d’un timeout, le protocole TCP considère que la connexion est peut-être très congestionnée et réagit de manière plus abrupte. La taille de la fenêtre est considérablement réduite et le protocole revient à la phase de SlowStart. Le processus de croissance de la fenêtre redémarre alors depuis un état initial. Ce retour à la phase de SlowStart suite à un timeout est une mesure radicale qui vise à minimiser l’impact sur un réseau déjà potentiellement instable. Il sert à remettre le mécanisme de contrôle de congestion à un état initial prudent, d’où il peut à nouveau commencer à sonder les capacités du réseau.

Lorsque la perte d’un paquet est signalée par la réception d’accusés de réception en double, le protocole entre dans la phase de FastRecovery. Le seuil de congestion est ajusté et la taille de la fenêtre est réduite, mais pas aussi radicalement que lors d’un timeout. Le but ici est de récupérer rapidement du comportement qui a conduit à la congestion sans entrer de nouveau en phase de SlowStart. La fenêtre continue alors de croître de manière additive, comme dans la phase de CongestionAvoidance, jusqu’à ce que le réseau soit stable.

Observons l’illustration plus en détail :

• SlowStart (en bleu): Au commencement, on note une augmentation rapide et exponentielle de la vitesse de transmission. Ceci est typique de la phase de Slow Start où, pour chaque accusé de réception reçu, la taille de la fenêtre est augmentée, permettant ainsi d’envoyer de plus en plus de segments simultanément. 
• CongestionAvoidance (en vert): Après cette première détection de congestion, la vitesse de transmission augmente de manière plus linéaire et modérée. C’est le début de la phase de Congestion Avoidance. Pour chaque tour complet, la fenêtre glissante augmente de manière additive, et non plus exponentielle comme dans la phase précédente. 
• FastRecovery (en orange): Suite à la détection de congestion, signalée par l’éclair sur le graphique, on constate une légère baisse de la vitesse de transmission, mais elle repart rapidement à la hausse.
• Loss (en rouge): Le point d’explosion sur le graphique indique une perte importante de données, causée par un timeout. Cette perte drastique entraîne une forte réduction de la vitesse de transmission et le protocole revient à la phase de SlowStart.

Il faut donc savoir distinguer la réception de trois accusés de réception en double d’un délai d’attente expiré pour gérer la fenêtre glissante dans TCP. Cette distinction est possible car plusieurs paquets sont souvent en transit en même temps et le délai d’attente est généralement bien plus long que le temps d’un aller-retour. La réception d’un seul accusé de réception en double peut simplement indiquer que les paquets sont arrivés dans le désordre. Par contre, recevoir trois accusés de réception en double de suite est un signe plus sûr qu’un paquet a été perdu. En d’autres termes, la réception de trois accusés de réception en double indique que quelque chose ne va pas et que TCP doit prendre des mesures pour récupérer le paquet perdu.

Quant au délai d’attente, il est réglé pour qu’il expire seulement lorsque la probabilité est élevée que plusieurs paquets soient effectivement perdus et non juste retardé. Ainsi, lorsque le délai d’attente expire, on peut être assez certain qu’un gros groupes de données sont perdus. Il est donc important de comprendre que la réception de trois accusés de réception en double conduit généralement à une phase de FastRecovery, tandis que l’expiration d’un délai d’attente entraîne un retour à la phase de SlowStart.