Transport de fiabilité TCP
Nous connaissons tous le protocole TCP comme protocole de transport fiable, mais comment garantit-il la fiabilité du transport ?
Pour garantir une transmission fiable, de nombreux facteurs doivent être pris en compte, tels que la corruption, la perte, la duplication et les fragments désordonnés des données. Si ces problèmes ne peuvent être résolus, la transmission fiable ne peut être assurée.
Par conséquent, 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 renvoi, la gestion des connexions et le contrôle des fenêtres pour obtenir 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 de TCP. Le mécanisme de retransmission est traité séparément dans la section suivante.
Contrôle de flux réseau
Le contrôle de flux réseau, ou contrôle du trafic réseau, est en réalité une manifestation de la relation subtile entre producteurs et consommateurs. Vous avez probablement souvent rencontré ce scénario au travail ou lors d'entretiens. Si la capacité de production du producteur dépasse largement la capacité de consommation du consommateur, la file d'attente s'allongera indéfiniment. Dans un cas plus grave, vous savez peut-être qu'une 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 : si aucune mesure n'est prise, un trop grand nombre de messages seront envoyés sur le réseau, ce qui entraînera une saturation des capacités des consommateurs, tandis que les producteurs continueront d'envoyer des messages en double, ce qui affectera considérablement les performances du réseau.
Pour remédier à ce phénomène, TCP fournit un mécanisme permettant à l'expéditeur de contrôler la quantité de données envoyées en fonction de la capacité de réception réelle du récepteur, appelé contrôle de flux. Le récepteur gère une fenêtre de réception, tandis que l'expéditeur gère une fenêtre d'envoi. Il est à noter que ces fenêtres ne concernent qu'une seule connexion TCP et que toutes les connexions ne partagent pas la même fenêtre.
TCP assure le contrôle de flux en utilisant une variable pour une fenêtre de réception. Cette fenêtre indique à l'expéditeur l'espace cache encore disponible. L'expéditeur contrôle la quantité de données envoyées en fonction de la capacité d'acceptation réelle du récepteur.
L'hôte récepteur informe l'expéditeur de la taille des données qu'il peut recevoir, et l'expéditeur envoie jusqu'à cette limite. Cette limite correspond à la taille de la fenêtre. Vous souvenez-vous de l'en-tête TCP ? Il existe un champ « fenêtre de réception », utilisé pour indiquer le nombre d'octets que le récepteur peut ou souhaite recevoir.
L'hôte émetteur envoie périodiquement un paquet de sondage de fenêtre, qui permet de vérifier si l'hôte récepteur est toujours en mesure d'accepter des données. Lorsque la mémoire tampon du récepteur risque de déborder, la taille de la fenêtre est réduite pour indiquer à l'émetteur de contrôler 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, principalement utilisée pour déterminer le débit auquel l'expéditeur 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'expéditeur TCP. Un algorithme est nécessaire pour déterminer la quantité de données à envoyer, car envoyer trop peu ou trop de données n'est pas idéal, d'où le concept de fenêtre de congestion.
Dans le contrôle de flux réseau précédent, nous évitions que l'expéditeur ne remplisse le cache du récepteur avec des données, sans savoir ce qui se passait sur le réseau. Généralement, les réseaux informatiques sont partagés. Par conséquent, la communication entre les autres hôtes peut entraîner une congestion du réseau.
Lorsque le réseau est congestionné, l'envoi continu d'un grand nombre de paquets peut entraîner des problèmes tels que des retards et des pertes de paquets. À ce stade, TCP retransmet les données, mais cette retransmission alourdit la charge du réseau, entraînant des retards plus importants et davantage de pertes de paquets. Ce phénomène peut entrer dans un cercle vicieux et s'aggraver.
Ainsi, TCP ne peut ignorer ce qui se passe sur le réseau. Lorsque le réseau est congestionné, TCP se sacrifie en réduisant la quantité de données envoyées.
Par conséquent, un contrôle de congestion est proposé, visant à éviter de surcharger le réseau avec les données de l'expéditeur. Pour réguler la quantité de données envoyées par l'expéditeur, TCP définit un concept appelé fenêtre de congestion. L'algorithme de contrôle de congestion ajuste la taille de cette fenêtre en fonction du degré de congestion du réseau, afin de contrôler la quantité de données envoyées par l'expéditeur.
Qu'est-ce qu'une fenêtre de congestion ? Quel est son rapport avec la fenêtre d'envoi ?
La fenêtre de congestion est une variable d'état gérée par l'expéditeur qui détermine la quantité de données qu'il peut envoyer. Elle é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'expéditeur et le destinataire, indiquant la quantité de données que le destinataire 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 au minimum des fenêtres de congestion et de réception, soit swnd = min(cwnd, rwnd).
La fenêtre de congestion cwnd change comme suit :
S'il n'y a pas de congestion dans le réseau, c'est-à-dire qu'aucun délai de retransmission ne se produit, la fenêtre de congestion augmente.
S'il y a congestion sur le réseau, la fenêtre de congestion diminue.
L'expéditeur détermine si le réseau est congestionné en observant si le paquet d'accusé de réception ACK est reçu dans le délai spécifié. Si l'expéditeur ne reçoit pas le paquet d'accusé de réception ACK dans le délai spécifié, le réseau est considéré comme congestionné.
Outre la fenêtre de congestion, il est temps d'aborder l'algorithme de contrôle de congestion TCP. Cet algorithme se compose de trois parties principales :
Démarrage lent :Au départ, la fenêtre de congestion cwnd est relativement petite et l'expéditeur augmente la fenêtre de congestion de manière exponentielle pour s'adapter rapidement à la capacité du réseau.
Évitement des embouteillages :Une fois que la fenêtre de congestion dépasse un certain seuil, l'expéditeur augmente la fenêtre de congestion de manière linéaire pour ralentir le taux de croissance de la fenêtre de congestion et éviter de surcharger le réseau.
Récupération rapide :En cas de congestion, l'expéditeur 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 via les accusés de réception en double 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 définie sur une valeur MSS (taille maximale de segment). Ainsi, le débit d'envoi initial est d'environ MSS/RTT octets/seconde. La bande passante réellement disponible étant généralement bien supérieure à MSS/RTT, TCP cherche à trouver le débit d'envoi optimal, ce qui peut être obtenu grâce à un démarrage lent.
Lors du démarrage lent, la valeur de la fenêtre de congestion cwnd est initialisée à 1 MSS. À chaque accusé de réception du segment de paquet transmis, elle augmente d'un MSS, passant 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 est illustré dans la figure suivante.
Cependant, le taux d'envoi ne peut pas toujours augmenter ; il doit bien s'arrêter un jour ou l'autre. Alors, quand cette augmentation prend-elle fin ? Un démarrage lent met généralement fin à cette augmentation de plusieurs manières :
La première méthode est celle de la perte de paquets lors du processus d'envoi d'un démarrage lent. Lorsqu'une perte de paquets se produit, TCP définit la fenêtre de congestion cwnd de l'expéditeur à 1 et relance le processus de démarrage lent. À ce stade, le concept de seuil de démarrage lent ssthresh est introduit, dont la valeur initiale est la moitié de la valeur de cwnd générant la perte de paquets. Autrement dit, lorsqu'une congestion est détectée, la valeur de ssthresh est égale à la moitié de la valeur de la fenêtre.
La deuxième méthode consiste à établir une corrélation directe avec la valeur du seuil de démarrage lent ssthresh. Comme la valeur de ssthresh est la moitié de la valeur de la fenêtre lors de la détection d'une congestion, une perte de paquets peut survenir à chaque doublement lorsque cwnd est supérieur à ssthresh. Il est donc préférable de définir cwnd sur ssthresh, ce qui entraînera le basculement de TCP en mode de contrôle de congestion et la fin du démarrage lent.
La dernière façon de mettre fin au démarrage lent est la détection de trois accusés de réception redondants. TCP effectue alors une retransmission rapide et passe en mode de récupération. (Si la raison de la présence de trois paquets ACK n'est pas claire, elle sera expliquée séparément dans le mécanisme de retransmission.)
Évitement de la congestion
Lorsque TCP entre en état de contrôle de congestion, cwnd est défini à la moitié du seuil de congestion ssthresh. Cela signifie que la valeur de cwnd ne peut pas être doublée à chaque réception d'un segment de paquet. Une approche relativement prudente est adoptée : la valeur de cwnd est augmentée d'une seule MSS (longueur maximale du segment de paquet) 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 de croissance. En cas de perte de paquets, cwnd est converti en MSS et ssthresh est défini à la moitié de cwnd. La croissance de MSS est également stoppée à la réception de trois ACK redondants. Si trois ACK redondants sont toujours reçus après la division par deux de cwnd, ssthresh est enregistré comme la moitié de cwnd et l'état 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 augmentée d'un MSS pour chaque ACK redondant reçu, c'est-à-dire un ACK non séquentiel. Cela permet d'exploiter les segments de paquets transmis avec succès sur le réseau afin d'optimiser l'efficacité de la transmission.
Lorsqu'un accusé de réception du segment de paquet perdu arrive, TCP diminue la valeur de cwnd et passe en mode d'évitement de congestion. Cela permet de contrôler la taille de la fenêtre de congestion et d'éviter d'aggraver la congestion du réseau.
Si un timeout survient après l'état de contrôle de congestion, l'état du réseau s'aggrave et TCP passe de l'état d'évitement de congestion à l'état de démarrage lent. Dans ce cas, la valeur de la fenêtre de congestion cwnd est fixée à 1 MSS, la longueur maximale du segment de paquet, et la valeur du seuil de démarrage lent ssthresh est fixée à la moitié de cwnd. L'objectif est d'augmenter progressivement la taille de la fenêtre de congestion après la reprise du réseau afin d'équilibrer le débit de transmission et le degré de congestion.
Résumé
Protocole de transport fiable, TCP assure un transport fiable grâce à un numéro de séquence, un accusé de réception, un contrôle de retransmission, une gestion des connexions et un contrôle de fenêtre. Parmi ces mécanismes, le contrôle de flux régule la quantité de données envoyées par l'expéditeur en fonction de la capacité de réception réelle du destinataire, évitant ainsi les problèmes de congestion du réseau et de dégradation des performances. Ce contrôle prévient la congestion du réseau en ajustant la quantité de données envoyées par l'expéditeur. Les concepts de fenêtre de congestion et de fenêtre d'envoi sont liés, et la quantité de données à l'expéditeur est contrôlée par l'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 sont les trois principaux éléments de l'algorithme de contrôle de congestion TCP, qui ajuste la taille de la fenêtre de congestion par différentes stratégies pour s'adapter à la capacité et au degré de congestion du réseau.
Dans la section suivante, nous examinerons en détail le mécanisme de retransmission de TCP. Ce mécanisme est essentiel pour garantir une transmission fiable des données. Il assure la fiabilité de la transmission 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
