Transport de fiabilité TCP
Nous connaissons tous le protocole TCP comme un protocole de transport fiable, mais comment assure-t-il la fiabilité du transport ?
Pour garantir une transmission fiable, de nombreux facteurs doivent être pris en compte, tels que la corruption, la perte et la duplication des données, ainsi que le désordre de leur transmission. Si ces problèmes ne sont pas résolus, une transmission fiable est impossible.
Par conséquent, le protocole TCP utilise des mécanismes tels que le numéro de séquence, la réponse d'accusé de réception, le contrôle de retransmission, la gestion des connexions et le contrôle de la fenêtre pour assurer une transmission fiable.
Dans cet article, nous nous concentrerons sur la fenêtre glissante, le contrôle de flux et le contrôle de congestion du protocole TCP. Le mécanisme de retransmission est traité séparément dans la section suivante.
Contrôle du flux réseau
Le contrôle de flux réseau, également appelé contrôle du trafic réseau, est en réalité une manifestation de la relation subtile entre producteurs et consommateurs. Vous avez probablement déjà rencontré ce scénario à maintes reprises au travail ou lors d'entretiens d'embauche. Si la capacité de production d'un producteur dépasse largement la capacité de consommation d'un consommateur, la file d'attente s'allongera indéfiniment. Dans un cas plus grave, vous savez peut-être que l'accumulation excessive de messages RabbitMQ peut entraîner une dégradation des performances de l'ensemble du serveur MQ. Il en va de même pour TCP : sans contrôle, un trop grand nombre de messages seront envoyés sur le réseau, les consommateurs seront saturés, tandis que les producteurs continueront d'envoyer des messages dupliqués, ce qui affectera considérablement les performances du réseau.
Pour pallier ce problème, le protocole TCP offre un mécanisme permettant à l'émetteur de contrôler la quantité de données envoyées en fonction de la capacité de réception réelle du récepteur : c'est le contrôle de flux. Le récepteur utilise une fenêtre de réception, tandis que l'émetteur utilise une fenêtre d'envoi. Il est important de noter que ces fenêtres sont spécifiques à une seule connexion TCP et que toutes les connexions ne partagent pas une même fenêtre.
Le protocole TCP assure le contrôle de flux grâce à une variable définissant la fenêtre de réception. Cette fenêtre indique à l'émetteur l'espace cache encore disponible. L'émetteur contrôle ainsi la quantité de données envoyées en fonction de la capacité de réception réelle du récepteur.
L'hôte destinataire notifie à l'émetteur la taille des données qu'il peut recevoir, et l'émetteur envoie jusqu'à cette limite. Cette limite correspond à la taille de la fenêtre de réception ; souvenez-vous de l'en-tête TCP ? Il existe un champ « fenêtre de réception » qui indique le nombre d'octets que le destinataire est capable ou disposé à recevoir.
L'hôte émetteur envoie périodiquement un paquet de test de fenêtre afin de vérifier si l'hôte récepteur est toujours en mesure de recevoir des données. Lorsque la mémoire tampon du récepteur risque d'être saturée, la taille de la fenêtre est réduite pour indiquer à l'émetteur de limiter la quantité de données envoyées.
Voici un diagramme de contrôle de flux réseau :
Contrôle de la congestion du réseau
Avant d'aborder le contrôle de congestion, il est important de comprendre qu'en plus des fenêtres de réception et d'envoi, il existe une fenêtre de congestion. Celle-ci sert principalement à déterminer le débit auquel l'émetteur commence à envoyer des données vers la fenêtre de réception. Par conséquent, la fenêtre de congestion est également gérée par l'émetteur TCP. Un algorithme est nécessaire pour déterminer la quantité de données appropriée à envoyer, car un envoi insuffisant ou excessif est préjudiciable ; d'où l'importance du concept de fenêtre de congestion.
Dans le système de contrôle de flux réseau précédent, nous évitions que l'expéditeur ne sature le cache du destinataire avec des données, mais nous ignorions ce qui se passait sur le réseau. En général, les réseaux informatiques sont des environnements partagés. Par conséquent, une congestion du réseau peut survenir en raison des communications entre les différents hôtes.
En cas de congestion du réseau, l'envoi continu d'un grand nombre de paquets peut entraîner des problèmes tels que des retards et des pertes de paquets. Le protocole TCP retransmet alors les données, ce qui augmente la charge sur le réseau et engendre des retards plus importants et davantage de pertes de paquets. Ce phénomène peut s'installer dans un cercle vicieux et s'amplifier continuellement.
Ainsi, le protocole TCP ne peut ignorer ce qui se passe sur le réseau. En cas de congestion, TCP réduit la quantité de données transmises, ce qui limite sa capacité.
Par conséquent, un mécanisme de contrôle de la congestion est proposé afin d'éviter la saturation du réseau par les données de l'émetteur. Pour réguler la quantité de données que l'émetteur doit envoyer, le protocole TCP définit la notion de fenêtre de congestion. L'algorithme de contrôle de la congestion ajuste la taille de cette fenêtre en fonction du degré de congestion du réseau, afin de limiter la quantité de données transmises par l'émetteur.
Qu'est-ce qu'une fenêtre de congestion ? Quel est son lien avec la fenêtre d'envoi ?
La fenêtre de congestion est une variable d'état gérée par l'émetteur qui détermine la quantité de données qu'il peut envoyer. Cette fenêtre évolue dynamiquement en fonction du niveau de congestion du réseau.
La fenêtre d'envoi est une taille de fenêtre convenue entre l'émetteur et le récepteur, indiquant la quantité de données que le récepteur peut recevoir. La fenêtre de congestion et la fenêtre d'envoi sont liées ; la fenêtre d'envoi est généralement égale à la plus petite des fenêtres de congestion et de réception, c'est-à-dire : fenêtre d'envoi = min(fenêtre de congestion, fenêtre de réception).
La fenêtre de congestion cwnd évolue comme suit :
S'il n'y a pas de congestion sur le réseau, c'est-à-dire qu'aucun délai d'expiration de retransmission ne se produit, la fenêtre de congestion augmente.
En cas de congestion du réseau, la fenêtre de congestion diminue.
L'émetteur détermine si le réseau est saturé en vérifiant si le paquet d'accusé de réception (ACK) est reçu dans le délai imparti. Si l'émetteur ne reçoit pas ce paquet dans le délai imparti, le réseau est considéré comme saturé.
Outre la fenêtre de congestion, il convient d'aborder l'algorithme de contrôle de congestion TCP. Cet algorithme se compose de trois parties principales :
Démarrage progressif :Initialement, la fenêtre de congestion cwnd est relativement petite, et l'émetteur augmente la fenêtre de congestion de manière exponentielle pour s'adapter rapidement à la capacité du réseau.
Éviter les embouteillages :Lorsque la fenêtre de congestion dépasse un certain seuil, l'émetteur augmente la fenêtre de congestion de manière linéaire afin de ralentir le taux de croissance de la fenêtre de congestion et d'éviter la surcharge du réseau.
Récupération rapide :En cas de congestion, l'émetteur réduit de moitié la fenêtre de congestion et entre dans l'état de récupération rapide pour déterminer l'emplacement de la récupération du réseau grâce aux accusés de réception dupliqués reçus, puis continue d'augmenter la fenêtre de congestion.
Démarrage lent
Lors de l'établissement d'une connexion TCP, la fenêtre de congestion (cwnd) est initialement fixée à une valeur minimale de MSS (taille maximale de segment). Le débit d'envoi initial est ainsi d'environ MSS/RTT octets/seconde. La bande passante réellement disponible étant généralement bien supérieure à MSS/RTT, TCP cherche à optimiser son débit d'envoi, ce qui peut être réalisé grâce à un démarrage lent.
Lors du démarrage progressif, la valeur de la fenêtre de congestion (cwnd) est initialisée à 1 MSS. À chaque accusé de réception d'un segment de paquet transmis, la valeur de cwnd est incrémentée de 1 MSS, atteignant ainsi 2 MSS. Ensuite, la valeur de cwnd est doublée à chaque transmission réussie d'un segment de paquet, et ainsi de suite. Le processus de croissance détaillé est illustré dans la figure suivante.
Cependant, le taux d'envoi ne peut pas augmenter indéfiniment ; cette croissance finit par s'interrompre. Alors, quand l'augmentation du taux d'envoi prend-elle fin ? Un démarrage progressif met généralement fin à cette augmentation de plusieurs manières :
Le premier cas de figure concerne la perte de paquets lors de l'envoi pendant la phase de démarrage lent. Lorsqu'une perte de paquets survient, TCP réinitialise la fenêtre de congestion de l'émetteur (cwnd) à 1 et relance le processus de démarrage lent. C'est à ce stade qu'intervient le concept de seuil de démarrage lent (ssthresh), dont la valeur initiale est égale à la moitié de la valeur de cwnd ayant entraîné la perte de paquets. Autrement dit, en cas de congestion, la valeur de ssthresh est égale à la moitié de la valeur de la fenêtre.
La seconde méthode consiste à établir une corrélation directe avec la valeur du seuil de démarrage lent (ssthresh). Étant donné que la valeur de ssthresh correspond à la moitié de la valeur de la fenêtre de congestion (cwnd) en cas de congestion, des pertes de paquets peuvent survenir à chaque doublement de cette valeur lorsque cwnd est supérieur à ssthresh. Il est donc préférable de définir cwnd à la valeur de ssthresh, ce qui entraînera le passage du protocole TCP en mode de contrôle de congestion et la fin du démarrage lent.
La dernière façon de résoudre un démarrage lent est la détection de trois accusés de réception redondants ; TCP effectue alors une retransmission rapide et entre en état de récupération. (Si la présence de trois paquets d'accusé de réception n'est pas claire, elle sera expliquée séparément dans la section consacrée au mécanisme de retransmission.)
Éviter la congestion
Lorsque TCP entre en mode de contrôle de congestion, la taille de la fenêtre de congestion (cwnd) est fixée à la moitié du seuil de congestion (ssthresh). Cela signifie que la valeur de cwnd ne peut pas doubler à chaque réception d'un segment de paquet. Au lieu de cela, une approche relativement prudente est adoptée : la valeur de cwnd n'augmente que d'une longueur maximale de segment de paquet (MSS) après chaque transmission. Par exemple, même si 10 segments de paquet sont acquittés, la valeur de cwnd n'augmentera que d'une MSS. Il s'agit d'un modèle de croissance linéaire, avec une limite supérieure. En cas de perte de paquets, la valeur de cwnd est modifiée pour atteindre une MSS, et celle de ssthresh est fixée à la moitié de cwnd. La croissance de la MSS est également stoppée après la réception de trois accusés de réception (ACK) redondants. Si trois ACK redondants sont toujours reçus après la réduction de moitié de la valeur de cwnd, la valeur de ssthresh est enregistrée comme étant la moitié de celle de cwnd et le mode de récupération rapide est activé.
Récupération rapide
En mode de récupération rapide, la valeur de la fenêtre de congestion (cwnd) est incrémentée d'un MSS pour chaque accusé de réception redondant (ACK) reçu, c'est-à-dire un ACK qui n'arrive pas dans la séquence. Ceci permet d'exploiter au mieux les segments de paquets ayant été transmis avec succès sur le réseau afin d'optimiser l'efficacité de la transmission.
Lorsqu'un accusé de réception (ACK) du segment de paquet perdu est reçu, TCP diminue la valeur de cwnd puis passe en mode d'évitement de congestion. Ceci permet de contrôler la taille de la fenêtre de congestion et d'éviter une aggravation de la congestion du réseau.
Si un délai d'attente est dépassé après la phase de contrôle de congestion, l'état du réseau se dégrade et le protocole TCP passe de l'état d'évitement de congestion à l'état de démarrage lent. Dans ce cas, la fenêtre de congestion (cwnd) est fixée à 1 MSS (longueur maximale d'un segment de paquet) et le seuil de démarrage lent (ssthresh) est fixé à la moitié de cwnd. L'objectif est d'augmenter progressivement la taille de la fenêtre de congestion après le rétablissement du réseau afin d'équilibrer le débit de transmission et le niveau de congestion.
Résumé
En tant que protocole de transport fiable, TCP garantit la fiabilité du transport grâce à la numérotation séquentielle, l'accusé de réception, le contrôle de retransmission, la gestion des connexions et le contrôle de fenêtre. Le mécanisme de contrôle de flux ajuste la quantité de données envoyées par l'émetteur en fonction de la capacité de réception réelle du récepteur, évitant ainsi les problèmes de congestion et de dégradation des performances du réseau. Le mécanisme de contrôle de congestion prévient la congestion du réseau en ajustant la quantité de données envoyées par l'émetteur. Les concepts de fenêtre de congestion et de fenêtre d'envoi sont liés, et la quantité de données envoyées par l'émetteur est contrôlée par un ajustement dynamique de la taille de la fenêtre de congestion. Le démarrage lent, l'évitement de la congestion et la récupération rapide constituent les trois composantes principales de l'algorithme de contrôle de congestion de TCP. Ces composantes ajustent la taille de la fenêtre de congestion selon différentes stratégies afin de s'adapter à la capacité et au niveau de congestion du réseau.
Dans la section suivante, nous examinerons en détail le mécanisme de retransmission du protocole TCP. Ce mécanisme est essentiel pour garantir la fiabilité des transmissions. Il assure la transmission fiable des données en retransmettant les données perdues, corrompues ou retardées. Le principe et la stratégie de mise en œuvre du mécanisme de retransmission seront présentés et analysés en détail dans la section suivante. À suivre !
Date de publication : 24 février 2025
