La retransmission TCP consiste à renvoyer sur le réseau les paquets qui ont été perdus ou endommagés. Ici, la retransmission est un mécanisme utilisé par des protocoles tels que TCP pour assurer une communication fiable. Ici, une communication fiable signifie que le protocole garantit la livraison du paquet même si le paquet de données a été perdu ou endommagé.
liste déroulante javascript
Les réseaux ne sont pas fiables et ne garantissent pas le délai ou la retransmission des paquets perdus ou endommagés. Le réseau qui utilise une combinaison d'accusé de réception et de retransmission de paquets endommagés ou perdus offre une fiabilité.
Mécanisme de retransmission
Ici, la retransmission signifie que les paquets de données ont été perdus, ce qui entraîne un manque d'accusé de réception. Ce manque d'acquittement déclenche un timer jusqu'à expiration, ce qui entraîne la retransmission des paquets de données. Ici, le temporisateur signifie que si aucun accusé de réception n'est reçu avant l'expiration du temporisateur, le paquet de données est retransmis.
Considérons les scénarios de retransmission suivants.
Scénario 1 : Lorsque le paquet de données est perdu ou erroné.
Dans ce scénario, le paquet est envoyé au destinataire, mais aucun accusé de réception n'est reçu dans ce délai. Lorsque le délai d'attente expire, le paquet est renvoyé à nouveau. Lorsque le paquet est retransmis, l'accusé de réception est reçu. Une fois l’accusé de réception reçu, la retransmission n’aura plus lieu.
Scénario 2 : lorsque le paquet est reçu mais que l'accusé de réception est perdu.
Dans ce scénario, le paquet est reçu de l’autre côté, mais l’accusé de réception est perdu, c’est-à-dire que l’ACK n’est pas reçu du côté de l’expéditeur. Une fois le délai d'attente expiré, le paquet est renvoyé. Il y a deux copies des paquets de l'autre côté ; bien que le paquet soit reçu correctement, l'accusé de réception n'est pas reçu, donc l'expéditeur retransmet le paquet. Dans ce cas, la retransmission aurait pu être évitée, mais en raison de la perte de l'ACK, le paquet est retransmis.
Scénario 3 : lorsque le délai d'attente anticipé se produit.
Dans ce scénario, le paquet est envoyé, mais en raison du retard d'accusé de réception ou du délai d'expiration qui s'est produit avant le délai d'attente réel, le paquet est retransmis. Dans ce cas, le paquet a été renvoyé inutilement en raison du retard d'accusé de réception ou le délai d'attente a été défini plus tôt que le délai d'attente réel.
Dans les scénarios ci-dessus, le premier scénario ne peut être évité, mais les deux autres scénarios peuvent être évités. Voyons comment nous pouvons éviter ces situations.
Combien de temps l’expéditeur doit-il attendre ?
L'expéditeur définit le délai d'attente pour un ACK. Le délai d'attente peut être de deux types :
Afin de surmonter les deux situations ci-dessus, TCP définit le délai d'attente en fonction du RTT (round trip time) où le temps d'aller-retour est le temps nécessaire au paquet pour voyager de la source à la destination, puis revenir.
Comment peut-on obtenir le RTT ?
Le RTT peut varier en fonction des caractéristiques du réseau, c'est-à-dire que si le réseau est encombré, cela signifie que le RTT est très élevé. Nous pouvons estimer le RTT en regardant simplement les ACK.
Voyons comment nous pouvons mesurer le RTT.
Nous utiliserons le algorithme original pour mesurer le RTT.
Étape 1: Dans un premier temps, nous mesurons le ÉchantillonRTT pour chaque segment ou paire ACK. Lorsque l'expéditeur envoie le paquet, nous connaissons alors l'heure à laquelle le paquet est envoyé, ainsi que l'heure à laquelle l'accusé de réception est reçu. Calculez le temps entre ces deux, et cela devient le ÉchantillonRTT .
sql sélectionner comme
Étape 2: Nous ne prélèverons pas un seul échantillon. Nous allons continuer à prélever différents échantillons et calculer la moyenne pondérée de ces échantillons, et cela devient l'EstRTT (Estimated RTT).
où, α+ β = 1
α est compris entre 0,8 et 0,9
β est compris entre 0,1 et 0,2
Étape 3: Le délai d'attente est défini en fonction d'EstRTT.
délai d'attente = 2 * EstRTT.
Le délai d'attente est défini sur deux fois le RTT estimé. C'est ainsi que le facteur de délai d'attente réel est calculé.
Une faille dans cette approche
Il y a une faille dans l'algorithme d'origine. Considérons deux scénarios.
liste en java
Scénario 1.
Le diagramme ci-dessus montre que l'expéditeur envoie les données, ce qui est considéré comme une transmission originale. Pendant le délai d'attente, aucun accusé de réception n'est reçu. Ainsi, l'expéditeur retransmet les données. Après retransmission des données, l'accusé de réception est reçu. Supposons qu'un accusé de réception soit reçu pour la transmission originale et non pour la retransmission. Puisque nous obtenons l'accusé de réception de la transmission originale, donc ÉchantillonRTT est calculé entre le moment de la transmission initiale et le moment où l'accusé de réception est reçu. Mais en réalité, le ÉchantillonRTT aurait dû se situer entre le moment de la retransmission et le moment de l’accusé de réception.
Scénario 2.
Le diagramme ci-dessus montre que l'expéditeur envoie le paquet de données d'origine pour lequel nous obtenons également un accusé de réception. Mais l'accusé de réception est reçu après retransmission des données. Si nous supposons que l'accusé de réception appartient à la retransmission, alors ÉchantillonRTT est calculé entre le moment de la retransmission et le moment de l'accusé de réception.
Dans les deux scénarios ci-dessus, il existe une ambiguïté de ne pas savoir si l'accusé de réception concerne la transmission originale ou la retransmission.
Conclusion de l'algorithme ci-dessus.
- Ici, ACK ne signifie pas accuser réception d’une transmission, mais en réalité, il accuse réception des données.
- Si l'on considère le premier scénario, la retransmission se fait pour le paquet perdu. Dans ce cas, nous supposons que ACK appartient à la transmission d'origine, ce qui fait que le SampleRTT s'avère très volumineux.
- Si l’on considère le deuxième scénario, deux paquets identiques sont envoyés, donc une duplicité se produit dans ce cas. Dans ce cas, nous supposons que ACK appartient à la retransmission en raison de laquelle le SampleRTT devient très petit.
Pour résoudre les problèmes ci-dessus, une solution simple est donnée par l’algorithme de Karn/Partridge. Cet algorithme a donné une solution simple qui collecte les échantillons envoyés en une seule fois et ne prend pas en compte les échantillons au moment de la retransmission pour calculer le RTT estimé.
Algorithme Karn/Partridge
Dans les deux scénarios ci-dessus, une retransmission se produit et nous avons considéré l'échantillon RTT. Mais cet algorithme ne prend pas en compte le Sample RTT lors de la retransmission. Puisque la retransmission a eu lieu, cela signifie que quelque chose se produit pendant ce temps aller-retour ou qu'une certaine congestion peut survenir dans un réseau. Pour pallier ce problème, cet algorithme double le timeout après chaque retransmission. Cet algorithme est implémenté dans le réseau TCP.
Limitation
Il ne prend pas en compte la variance du RTT.
clause SQL
Pour surmonter la limitation ci-dessus, l'algorithme de Jacobson/Karels a été développé et introduit le facteur de variance dans RTT.
Algorithme de Jacobson/Karels
Cet algorithme a été développé pour surmonter les limites du Karn/Perdrix algorithme. Il calcule la différence entre le SampleRTT et l'EstimatedRTT et augmente le RTT en fonction de la différence.
Calculs pour le RTT moyen
- Tout d’abord, nous calculons le facteur de différence.
Diff = SampleRTT - EstimationRTT
- Maintenant, nous calculons l'EstimationRTT, qui sera calculé de la même manière que ci-dessus.
EstRTT = EstRTT + (δ*Diff)
- Maintenant, nous calculons la moyenne du facteur de différence.
Dév = Dév + δ ( |Diff| - Dév)
Ici, Dev est un facteur de déviation et δ est un facteur compris entre 0 et 1. Le Développeur est une estimation de la variance par rapport à EstRTT .
- Nous considérerons la variance lors du calcul de la valeur du délai d'attente.
Où, µ =1 et ɸ =4
types de données en Java
Retransmission rapide
La stratégie de retransmission basée sur un délai d'attente est inefficace. TCP est un type de protocole à fenêtre glissante, donc chaque fois que la retransmission se produit, il commence à l'envoyer à partir du paquet perdu.
Supposons que je transmette les paquets 0, 1, 2 et 3. Puisque le paquet 0 et le paquet 1 sont reçus de l'autre côté, le paquet 2 est perdu dans un réseau. J'ai reçu l'accusé de réception du paquet 0 et du paquet 1, j'envoie donc deux paquets supplémentaires, c'est-à-dire le paquet 4 et le paquet 5. Lorsque les paquets 3, 4 et 5 sont envoyés, j'obtiendrai l'accusé de réception du paquet 1 sous forme d'accusé de réception TCP. sont cumulatifs, il accuse donc réception jusqu'au paquet qu'il a reçu dans l'ordre. Je n'ai pas reçu l'accusé de réception des paquets 2, 3, 4 et 5 dans le délai d'attente, je retransmets donc les paquets 2, 3, 4 et 5. Puisque le paquet 2 est perdu, mais les autres paquets, c'est-à-dire 3, 4 ,5 sont reçus de l’autre côté, ils sont quand même retransmis en raison de ce mécanisme de délai d’attente.
Comment cette inefficacité du délai d’attente peut-elle être supprimée ?
La meilleure solution sous une fenêtre coulissante :
Supposons que n paquets aient été perdus, mais que les paquets n+1, n+2, etc. aient été reçus. Le récepteur reçoit en permanence les paquets et envoie les paquets ACK indiquant que le récepteur attend toujours le nième paquet. Le destinataire envoie des accusés de réception répétés ou en double. Dans le cas ci-dessus, l'ACK du paquet 1 est envoyé trois fois car le paquet 2 a été perdu. Ce paquet ACK en double indique que le nième paquet est manquant, mais que les paquets suivants sont reçus.
La situation ci-dessus peut être résolue des manières suivantes :
- L'expéditeur peut considérer les « ACK en double » comme un indice précoce que le nième paquet a été perdu afin que l'expéditeur puisse effectuer la retransmission le plus tôt possible, c'est-à-dire que l'expéditeur ne doit pas attendre que le délai d'attente se produise.
- L'expéditeur peut mettre en œuvre une stratégie de transmission rapide en TCP. Dans une stratégie de transmission rapide, l'expéditeur doit considérer les triples ACK en double comme un déclencheur et les retransmettre.
TCP utilise trois ACK en double comme déclencheur, puis effectue une retransmission. Dans le cas ci-dessus, lorsque trois ACK du paquet 1 sont reçus, l'expéditeur doit alors envoyer le paquet perdu, c'est-à-dire le paquet 2, sans attendre que le délai d'attente se produise.