Transport de fiabilité TCP
Nous connaissons tous le protocole TCP en tant que protocole de transport fiable, mais comment assure-t-il la fiabilité du transport?
Pour obtenir une transmission fiable, de nombreux facteurs doivent être pris en compte, tels que la corruption des données, la perte, la duplication et les éclats hors commande. Si ces problèmes ne peuvent pas être résolus, une transmission fiable ne peut pas être réalisée.
Par conséquent, TCP utilise des mécanismes tels que le numéro de séquence, la réponse de l'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 coulissante, le contrôle du débit et le contrôle de la congestion du TCP. Le mécanisme de retransmission est couvert séparément dans la section suivante.
Contrôle de flux de réseau
Le contrôle du flux de réseau ou le savoir sous le nom de contrôle du trafic réseau est en fait une manifestation de la relation subtile entre les producteurs et les consommateurs. Vous avez probablement beaucoup rencontré ce scénario au travail ou dans les interviews. Si la capacité du producteur à produire dépasse considérablement la capacité du consommateur à consommer, elle entraînera une croissance indéfiniment de la file d'attente. Dans un cas plus grave, vous savez peut-être que lorsque les messages RabbitMQ s'accumulent trop, cela peut entraîner la dégradation des performances de l'ensemble du serveur MQ. Il en va de même pour TCP; S'il n'est pas contrôlé, trop de messages seront mis dans le réseau, et les consommateurs auront dépassé leur capacité, tandis que les producteurs continueront d'envoyer des messages en double, ce qui affectera grandement les performances du réseau.
Pour résoudre ce phénomène, TCP fournit un mécanisme pour que l'expéditeur contrôle la quantité de données envoyées en fonction de la capacité de réception réelle du récepteur, appelé contrôle du débit. Le récepteur maintient une fenêtre de réception, tandis que l'expéditeur maintient une fenêtre d'envoi. Il convient de noter que ces fenêtres ne sont que pour une seule connexion TCP et que toutes les connexions ne partagent pas une fenêtre.
TCP fournit un contrôle de débit en utilisant une variable pour une fenêtre de réception. La fenêtre de réception donne à l'expéditeur une indication de la quantité d'espace de cache 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 du récepteur informe l'expéditeur de la taille des données qu'il peut recevoir, et l'expéditeur envoie à cette limite. Cette limite est la taille de la fenêtre, rappelez-vous l'en-tête TCP? Il y a un champ de fenêtre de réception, qui est utilisé pour indiquer le nombre d'octets que le récepteur est capable ou disposé à recevoir.
L'hôte de l'expéditeur enverra périodiquement un paquet de sonde de fenêtre, qui est utilisé pour détecter si l'hôte du récepteur est toujours en mesure d'accepter des données. Lorsque le tampon du récepteur risque de déborder, la taille de la fenêtre est définie sur une valeur plus petite pour demander à l'expéditeur de contrôler la quantité de données envoyées.
Voici un diagramme de contrôle de flux de réseau:
Contrôle de la congestion du réseau
Avant d'introduire le contrôle de la congestion, nous devons comprendre qu'en plus de la fenêtre de réception et de la fenêtre d'envoi, il y a également une fenêtre de congestion, qui est principalement utilisée pour résoudre le problème à quelle vitesse le rythme commence à envoyer des données à la fenêtre de réception. Par conséquent, la fenêtre de congestion est également maintenue par l'expéditeur TCP. Nous avons besoin d'un algorithme pour décider de la quantité de données appropriée à envoyer, car envoyer trop peu ou trop de données n'est pas idéal, d'où le concept d'une fenêtre de congestion.
Dans le contrôle du flux de réseau précédent, ce que nous avons évité, c'est que l'expéditeur remplit le cache du récepteur avec des données, mais nous ne savions pas ce qui se passait dans le réseau. En règle générale, les réseaux informatiques sont dans un environnement partagé. En conséquence, il peut y avoir une congestion du réseau en raison de la communication entre les autres hôtes.
Lorsque le réseau est congestionné, si un grand nombre de paquets se poursuivent, il peut entraîner des problèmes tels que le retard et la perte de paquets. À ce stade, TCP retransmetra les données, mais la retransmission augmentera la charge du réseau, entraînant des retards plus importants et plus de pertes de paquets. Cela peut entrer dans un cercle vicieux et continuer à grossir.
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 qu'il envoie.
Par conséquent, un contrôle de la congestion est proposé, qui vise à éviter de remplir l'ensemble du réseau avec des données de l'expéditeur. Pour réguler la quantité de données que l'expéditeur doit envoyer, TCP définit un concept appelé la fenêtre de congestion. L'algorithme de contrôle de la congestion ajustera la taille de la fenêtre de congestion 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? Qu'est-ce que cela a à voir avec la fenêtre d'envoi?
La fenêtre de congestion est une variable d'état maintenue par l'expéditeur qui détermine la quantité de données que l'expéditeur peut envoyer. La fenêtre de congestion change 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 récepteur qui indique 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 au minimum des fenêtres de congestion et de réception, c'est-à-dire 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 d'expiration de retransmission ne se produit, la fenêtre de congestion augmente.
S'il y a de la congestion dans 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é, il est considéré que le réseau est congestionné.
En plus de la fenêtre de congestion, il est temps de discuter de l'algorithme de contrôle de la congestion TCP. L'algorithme de contrôle de la congestion TCP se compose de trois parties principales:
Démarrage lent:Initialement, la fenêtre de congestion CWND est relativement faible, et l'expéditeur augmente la fenêtre de congestion de façon exponentielle pour s'adapter rapidement à la capacité du réseau.
Évitement de la congestion:Une fois que la fenêtre de congestion a dépassé 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:Si la congestion se produit, l'expéditeur fait référence à 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 ACK en double reçus, puis continue d'augmenter la fenêtre de congestion.
Démarrage lent
Lorsqu'une connexion TCP est établie, la fenêtre de congestion CWND est initialement définie sur une valeur MSS MSS (segment maximale). De cette façon, le taux d'envoi initial concerne les octets MSS / RTT / seconde. La bande passante disponible réelle est généralement beaucoup plus grande que MSS / RTT, donc TCP veut trouver le taux d'envoi optimal, qui peut être réalisé au moyen d'un démarrage lent.
Dans le processus de démarrage lent, la valeur de la fenêtre de congestion CWND sera initialisée à 1 MSS, et chaque fois que le segment de paquets transmis est reconnu, la valeur de CWND sera augmentée d'un MSS, c'est-à-dire que la valeur du CWND deviendra 2 MSS. Après cela, la valeur de CWND est doublée pour chaque transmission réussie d'un segment de paquets, etc. Le processus de croissance spécifique est illustré dans la figure suivante.
Cependant, le taux d'envoi ne peut pas toujours augmenter; La croissance doit se terminer un jour. Alors, quand l'augmentation du taux d'envoi se termine-t-elle? Le démarrage lent termine généralement l'augmentation du taux d'envoi de plusieurs manières:
La première façon est le cas de la perte de paquets pendant le processus d'envoi de démarrage lent. Lorsqu'une perte de paquets se produit, TCP définit la fenêtre de congestion de l'expéditeur CWND à 1 et redémarre le processus de démarrage lent. À ce stade, un concept de seuil de démarrage lent SSTHRESH est introduit, dont la valeur initiale est la moitié de la valeur de CWND qui génère une perte de paquets. Autrement dit, lorsque la congestion est détectée, la valeur de SSthresh est la moitié de la valeur de la fenêtre.
La deuxième façon est de corréler directement avec la valeur du seuil de démarrage lent SSTHRESH. Étant donné que la valeur de SSThresh est la moitié de la valeur de la fenêtre lorsque la congestion est détectée, une perte de paquets peut se produire à chaque doublement lorsque CWND est plus grand que SSTHRESH. Par conséquent, il est préférable de définir CWND sur SSTHRESH, ce qui amènera TCP à passer en mode de contrôle de la congestion et à terminer le démarrage lent.
La dernière façon dont le démarrage lent peut se terminer est que si trois ACK redondants sont détectés, TCP effectue une retransmission rapide et entre dans l'état de récupération. (S'il n'est pas clair pourquoi il y a trois paquets ACK, il sera expliqué séparément dans le mécanisme de retransmission.)
Évitement de la congestion
Lorsque TCP entre dans l'état de contrôle de la congestion, CWND est fixé à la moitié du seuil de congestion SSTRESHS. Cela signifie que la valeur de CWND ne peut pas être doublée chaque fois qu'un segment de paquets est reçu. Au lieu de cela, une approche relativement conservatrice est adoptée dans laquelle la valeur du CWND est augmentée d'un seul MSS (longueur maximale du segment de paquets) une fois chaque transmission terminée. Par exemple, même si 10 segments de paquets sont reconnus, la valeur du CWND ne fera qu'augmenter d'un seul MSS. Il s'agit d'un modèle de croissance linéaire et il a également une limite supérieure sur la croissance. Lorsque la perte de paquets se produit, la valeur de CWND est changée en un MSS et la valeur de SSThresh est définie sur la moitié de CWND. Ou cela arrêtera également la croissance de MSS lorsque 3 réponses ACK redondantes seront reçues. Si trois ACK redondants sont toujours reçus après avoir enregistré de moitié la valeur de CWND, la valeur de SSThresh est enregistrée comme la moitié de la valeur de CWND et l'état de récupération rapide est entré.
Récupération rapide
Dans l'état 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 ACK qui n'arrive pas en séquence. Il s'agit d'utiliser les segments de paquets qui ont été transmis avec succès dans le réseau pour améliorer l'efficacité de transmission autant que possible.
Lorsqu'un ACK du segment des paquets perdus arrive, TCP diminue la valeur de CWND puis entre dans l'état d'évitement de la congestion. Il s'agit de contrôler la taille de la fenêtre de congestion et d'éviter d'augmenter davantage la congestion du réseau.
Si un délai d'expiration se produit après l'état de contrôle de la congestion, l'état du réseau devient plus grave et le TCP migre de l'état d'évitement de la congestion à l'état de démarrage lent. Dans ce cas, la valeur de la fenêtre de congestion CWND est définie sur 1 MSS, la longueur maximale du segment de paquets et la valeur du seuil de démarrage lent SSThresh est définie sur la moitié de CWND. Le but de cela est d'augmenter de manière rééviluelle la taille de la fenêtre de congestion après que le réseau se soit remis pour équilibrer le taux de transmission et le degré de congestion du réseau.
Résumé
En tant que protocole de transport fiable, TCP met en œuvre un transport fiable par numéro de séquence, reconnaissance, contrôle de retransmission, gestion de la connexion et contrôle des fenêtres. Parmi eux, le mécanisme de contrôle des flux contrôle la quantité de données envoyées par l'expéditeur en fonction de la capacité de réception réelle du récepteur, ce qui évite les problèmes de congestion du réseau et de dégradation des performances. Le mécanisme de contrôle de la congestion évite la survenue de 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 les uns aux autres, et la quantité de données à l'expéditeur est contrôlée en ajustant dynamiquement la taille de la fenêtre de congestion. Le démarrage lent, l'évitement de la congestion et la reprise rapide sont les trois principales parties de l'algorithme de contrôle de la congestion TCP, qui ajustent la taille de la fenêtre de congestion à travers 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. Le mécanisme de retransmission est une partie importante du TCP pour atteindre une transmission fiable. Il garantit la transmission fiable des données en retransmettant les données perdues, corrompues ou retardées. Le principe de mise en œuvre et la stratégie du mécanisme de retransmission seront introduits et analysés en détail dans la section suivante. Restez à l'écoute!
Heure du poste: février-24-2025
