La principale différence : le contrôle de flux résout le problème de l'inadéquation des débits entre l'expéditeur et le récepteur ; le contrôle de la congestion résout le problème d'éviter l'épuisement des ressources du réseau. Le contrôle des flux est mis en œuvre via des fenêtres coulissantes ; le contrôle de la congestion est mis en œuvre via des fenêtres de congestion.
L'environnement d'exploitation de ce tutoriel : système Windows 7, ordinateur Dell G3.
Recommandations associées : "Enseignement de la programmation"
La différence entre le contrôle de flux et le contrôle de congestion
Le contrôle de flux TCP et le contrôle de congestion semblent être deux concepts relativement similaires, qui prêtent facilement à confusion. Mais en fait, ils sont complètement différents dans les objectifs et les méthodes souhaités.
Le contrôle de flux résout le problème de non-concordance de débit entre l'expéditeur et le destinataire. Si l'expéditeur envoie trop vite, le destinataire n'aura pas le temps de recevoir et de traiter. Le mécanisme utilisé est un mécanisme de fenêtre coulissante, qui contrôle le nombre de paquets envoyés mais non acquittés.
Le contrôle de la congestion résout le problème de la prévention de l'épuisement des ressources du réseau. En prenant des mesures d'évitement autodisciplinées, chacun peut éviter l'épuisement des ressources réseau limitées. En cas de perte de paquets, le débit d'envoi est contrôlé pour réduire la charge du réseau.
Contrôle du flux
La taille de la fenêtre reste inchangée lors d'un processus de communication de connexion spécifique. La fenêtre coulissante est un mécanisme. La taille de la fenêtre coulissante représente la taille des données qui peuvent être envoyées à l'extrémité émettrice et la taille des données qui peuvent être reçues à l'extrémité réceptrice.
Contrôle des embouteillages
Le processus d'augmentation linéaire après avoir dépassé la taille limite pendant la phase d'évitement de la congestion, et le processus de changement de la fenêtre de congestion à 1 et de réduction de moitié de la taille limite après la détection d'une perte de paquets.
Informations étendues
Le contrôle de flux est un contrôle de bout en bout. Par exemple, A envoie. un message à B via le réseau. Les données A envoient trop vite et B ne peut pas les recevoir (la fenêtre du tampon B est trop petite ou le traitement est trop lent). Le contrôle à ce moment est le contrôle de flux, et le principe est obtenu en modifiant le). taille de la fenêtre coulissante.
Le contrôle de la congestion se produit lorsque le réseau entre A et B est bloqué, ce qui entraîne une transmission trop lente ou une perte de paquets, et qu'il n'y a pas de temps pour la transmission. Empêcher l’injection d’une trop grande quantité de données dans le réseau évite la surcharge des routeurs ou des liens du réseau. Le contrôle de la congestion est un processus global qui implique tous les hôtes, routeurs et tous les facteurs liés à la réduction des performances du réseau.
Mécanisme de contrôle de flux :
Supposons que l'hôte A envoie des données à l'hôte B. La valeur de la fenêtre déterminée par les deux parties est 400. Supposons que chaque segment de message fait 100 octets de long, la valeur initiale du numéro de séquence est seq=1, un ACK majuscule indique que l'en-tête est considéré comme un ACK et un ack minuscule indique la valeur. du champ de confirmation.
L’hôte B du récepteur a effectué trois contrôles de flux. La première fois, la fenêtre est définie sur rwind=300, la deuxième fois, elle est réduite à rwind=100 et enfin elle est réduite à rwind=0, c'est-à-dire que l'expéditeur n'est plus autorisé à envoyer de données. Cet état qui amène l'expéditeur à suspendre l'envoi continuera jusqu'à ce que l'hôte B renvoie une nouvelle valeur de fenêtre.
Supposons que peu de temps après que B ait envoyé un segment de message sans fenêtre à A, le tampon de réception de B dispose d'un espace de stockage. B a donc envoyé un segment de message avec rwind=400 à A, mais ce segment de message a été perdu lors de la transmission. A attend de recevoir la notification de fenêtre non nulle envoyée par B, et B attend les données envoyées par A. Cela crée une impasse. Afin de résoudre cette situation de blocage, TCP dispose d'un minuteur continu pour chaque connexion. Tant qu'une partie de la connexion TCP reçoit la notification de fenêtre zéro de l'autre partie, elle démarre le temporisateur continu. Si le temps défini par le temporisateur continu expire, il envoie un segment de message de détection de fenêtre zéro (transportant seulement 1 octet de données). ), et l'autre partie La valeur actuelle de la fenêtre est donnée lors de la confirmation de ce segment de détection.
Mécanisme de contrôle des embouteillages :
Démarrage lent et évitement des embouteillages
La détermination du débit d'envoi de segments de message doit non seulement être basée sur la capacité de réception de l'extrémité réceptrice, mais également prendre en compte la situation globale de non-congestion du réseau. Ceci est déterminé par les deux quantités d'état du. fenêtre de réception et fenêtre de congestion. La fenêtre du récepteur (Reciver Window), également connue sous le nom de fenêtre annoncée, est la dernière valeur de fenêtre promise par le récepteur en fonction de la taille actuelle du tampon de réception et constitue un contrôle de flux provenant du récepteur. La fenêtre de congestion cwnd (Congestion Window) est une valeur de fenêtre définie par l'extrémité émettrice en fonction de son niveau de congestion du réseau estimé. Il s'agit d'un contrôle de flux provenant de l'extrémité émettrice.
Principe de démarrage lent :
1) Lorsque l'hôte commence à envoyer des données, si tous les octets de données de la plus grande fenêtre d'envoi sont immédiatement injectés dans le réseau, puis parce que la situation du réseau n'est pas claire, cela peut provoquer une congestion du réseau
2) Une meilleure façon est de le tester, c'est-à-dire d'augmenter progressivement la valeur de la fenêtre de contrôle de congestion de l'expéditeur à partir d'une petite arrivée
3) Habituellement, lorsque vous commencez simplement à envoyer un segment de message, vous pouvez d'abord définir le cwnd de la fenêtre de congestion sur la valeur du MSS du plus grand segment de message. Après chaque confirmation d'un nouveau segment, la fenêtre de congestion est augmentée jusqu'à une valeur MSS. Lorsque rwind est suffisamment grand, afin d'éviter que la croissance de la fenêtre de congestion cwind ne provoque une congestion du réseau, une autre variable est nécessaire : la seuil de démarrage lent. ssthresh
Le processus spécifique de contrôle de congestion est :
1) Initialisation de la connexion TCP, définissez la fenêtre de congestion sur 1
2) Exécution lente Démarrez l'algorithme, cwind croît de façon exponentielle, jusqu'à ce que cwind == ssthress commence à exécuter l'algorithme d'évitement de congestion, cwnd croît linéairement
3) Lorsqu'une congestion du réseau se produit, mettez à jour la valeur ssthresh à la moitié de la valeur ssthresh avant la congestion. Réinitialisez cwnd à 1 et suivez l’étape (2).
Retransmission rapide et récupération rapide
Une connexion TCP reste parfois inactive pendant une longue période en raison de l'attente de l'expiration du délai de retransmission. Le démarrage lent et l'évitement de la congestion ne peuvent pas bien résoudre ce problème. des méthodes de contrôle de congestion avec retransmission et récupération rapides sont proposées.
L'algorithme de retransmission rapide n'annule pas le mécanisme de retransmission, mais retransmet le segment perdu plus tôt dans certains cas (si l'expéditeur reçoit trois ACK de confirmation en double, il est conclu que si un paquet est perdu, le segment perdu sera être retransmis immédiatement sans attendre l'expiration du délai de retransmission). L'algorithme de démarrage lent n'est utilisé que lorsque TCP est établi.
L'algorithme de récupération rapide comporte les deux points suivants :
1) Lorsque l'expéditeur reçoit trois confirmations consécutives en double, il exécute l'algorithme de "réduction multiplicative" et réduit de moitié le seuil de démarrage lent, c'est pour éviter la congestion du réseau.
2) Puisque l'expéditeur estime maintenant que le réseau n'est probablement pas encombré, il n'exécute pas l'algorithme de démarrage lent maintenant, mais il définit la valeur cwnd sur la valeur après que le seuil de démarrage lent soit réduit de moitié, et. commence ensuite à exécuter l'algorithme d'évitement de congestion, augmentant linéairement la fenêtre de congestion.
Résumé :
Les deux premiers algorithmes sont utilisés avant que la congestion ne se produise, et les deux derniers algorithmes sont utilisés après la congestion (c'est-à-dire trois confirmations répétées).
Pour plus d'articles connexes, veuillez visiter le Site Web PHP chinois ! !
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!