logo

TCP-hertransmissie

De TCP-hertransmissie houdt in dat de pakketten die verloren of beschadigd zijn, opnieuw via het netwerk worden verzonden. Hier is hertransmissie een mechanisme dat wordt gebruikt door protocollen zoals TCP betrouwbare communicatie te bieden. Betrouwbare communicatie betekent hier dat het protocol de bezorging van het pakket garandeert, zelfs als het datapakket verloren is gegaan of beschadigd is.

css afbeeldingsgrootte wijzigen

De netwerken zijn onbetrouwbaar en garanderen geen vertraging of hertransmissie van verloren of beschadigde pakketten. Het netwerk dat gebruik maakt van een combinatie van bevestiging en hertransmissie van beschadigde of verloren pakketten, biedt betrouwbaarheid.

Hertransmissiemechanisme

Hier betekent hertransmissie dat de datapakketten verloren zijn gegaan, wat leidt tot een gebrek aan bevestiging. Dit gebrek aan bevestiging leidt tot een time-out van een timer, wat leidt tot het opnieuw verzenden van datapakketten. Hier betekent de timer dat als er geen bevestiging wordt ontvangen voordat de timer afloopt, het datapakket opnieuw wordt verzonden.

Laten we de volgende scenario's van hertransmissie eens bekijken.

Scenario 1: Wanneer het datapakket verloren gaat of foutief is.

TCP-hertransmissie

In dit scenario wordt het pakket naar de ontvanger verzonden, maar wordt er binnen die time-outperiode geen bevestiging ontvangen. Wanneer de time-outperiode is verstreken, wordt het pakket opnieuw verzonden. Wanneer het pakket opnieuw wordt verzonden, wordt de bevestiging ontvangen. Zodra de bevestiging is ontvangen, zal er geen hertransmissie meer plaatsvinden.

Scenario 2: Wanneer het pakket wordt ontvangen, maar de bevestiging verloren gaat.

TCP-hertransmissie

In dit scenario wordt het pakket aan de andere kant ontvangen, maar gaat de bevestiging verloren, dat wil zeggen dat de ACK niet wordt ontvangen aan de kant van de afzender. Zodra de time-outperiode is verstreken, wordt het pakket opnieuw verzonden. Er zijn twee exemplaren van de pakketten aan de andere kant; Hoewel het pakket correct is ontvangen, wordt de bevestiging niet ontvangen, dus verzendt de afzender het pakket opnieuw. In dit geval had de hertransmissie vermeden kunnen worden, maar door het verlies van de ACK wordt het pakket opnieuw verzonden.

Scenario 3: Wanneer de vroege time-out optreedt.

TCP-hertransmissie

In dit scenario wordt het pakket verzonden, maar vanwege de vertraging in de bevestiging of de time-out die vóór de daadwerkelijke time-out heeft plaatsgevonden, wordt het pakket opnieuw verzonden. In dit geval is het pakket onnodig opnieuw verzonden vanwege de vertraging in de bevestiging of is de time-out eerder ingesteld dan de daadwerkelijke time-out.

In de bovenstaande scenario's kan het eerste scenario niet worden vermeden, maar de andere twee scenario's kunnen wel worden vermeden. Laten we eens kijken hoe we deze situaties kunnen vermijden.

Hoe lang moet de afzender wachten?

De afzender stelt de time-outperiode voor een ACK in. De time-outperiode kan van twee typen zijn:

    Te kort:Als de time-outperiode te kort is, zullen de hertransmissies verloren gaan.Te lang:Als de time-outperiode te lang is, zal er een buitensporige vertraging optreden wanneer het pakket verloren gaat.

Om de bovengenoemde twee situaties te overwinnen, TCP stelt de time-out in als functie van de RTT (retourtijd), waarbij de retourtijd de tijd is die het pakket nodig heeft om van de bron naar de bestemming te reizen en vervolgens weer terug te komen.

Hoe kunnen we de RTT verkrijgen?

Hoe te updaten in Java

De RTT kan variëren afhankelijk van de kenmerken van het netwerk. Dat wil zeggen dat als het netwerk overbelast is, dit betekent dat de RTT erg hoog is. We kunnen de RTT schatten door simpelweg naar de ACK's te kijken.

Laten we eens kijken hoe we de RTT kunnen meten.

Wij zullen gebruik maken van de origineel algoritme om de RTT te meten.

Stap 1: Eerst meten wij de VoorbeeldRTT voor elk segment of ACK-paar. Wanneer de afzender het pakket verzendt, kennen we de timer waarop het pakket wordt verzonden, en ook de timer waarop de bevestiging wordt ontvangen. Bereken de tijd tussen deze twee, en dat wordt de VoorbeeldRTT .

Stap 2: We nemen niet slechts één monster. We zullen verschillende monsters blijven nemen en het gewogen gemiddelde van deze monsters berekenen, en dit wordt de EstRTT (geschatte RTT).

waarbij α+ β = 1

α ligt tussen 0,8 en 0,9

β ligt tussen 0,1 en 0,2

Stap 3: De time-out wordt ingesteld op basis van EstRTT.

time-out = 2 * EstRTT.

De time-out is ingesteld op tweemaal de geschatte RTT. Zo wordt de werkelijke time-outfactor berekend.

nick pulos zwarte bliksem

Een fout in deze aanpak

Er zit een fout in het oorspronkelijke algoritme. Laten we twee scenario's bekijken.

Scenario 1.

TCP-hertransmissie

Het bovenstaande diagram laat zien dat de afzender de gegevens verzendt, wat een originele verzending zou zijn. Binnen de time-outperiode wordt geen bevestiging ontvangen. De afzender verzendt de gegevens dus opnieuw. Na het opnieuw verzenden van de gegevens wordt de bevestiging ontvangen. Laten we aannemen dat er een bevestiging wordt ontvangen voor de oorspronkelijke verzending, en niet voor de hertransmissie. Omdat we de bevestiging krijgen van de originele transmissie, dus VoorbeeldRTT wordt berekend tussen het tijdstip van de oorspronkelijke verzending en het tijdstip waarop de bevestiging wordt ontvangen. Maar eigenlijk is de VoorbeeldRTT had moeten liggen tussen het tijdstip van de heruitzending en het tijdstip van de bevestiging.

Scenario 2.

TCP-hertransmissie

Het bovenstaande diagram laat zien dat de afzender het originele datapakket verzendt, waarvoor we ook de bevestiging krijgen. Maar de bevestiging wordt ontvangen na het opnieuw verzenden van de gegevens. Als we aannemen dat erkenning tot de heruitzending behoort, dan VoorbeeldRTT wordt berekend tussen het tijdstip van de heruitzending en het tijdstip van de bevestiging.

In de bovenstaande beide scenario's bestaat er een dubbelzinnigheid omdat we niet weten of de bevestiging voor de oorspronkelijke verzending of voor de hertransmissie is.

Conclusie van het bovenstaande algoritme.

  • Hier betekent ACK niet dat een verzending wordt bevestigd, maar feitelijk wordt hiermee de ontvangst van de gegevens bevestigd.
  • Als we het eerste scenario beschouwen, wordt de hertransmissie uitgevoerd voor het verloren pakket. In dit geval gaan we ervan uit dat ACK tot de oorspronkelijke transmissie behoort, waardoor de SampleRTT erg groot blijkt te zijn.
  • Als we het tweede scenario beschouwen, worden er twee dezelfde pakketten verzonden, zodat er in dit geval sprake is van dubbelhartigheid. In dit geval gaan we ervan uit dat ACK tot de hertransmissie behoort, waardoor de SampleRTT erg klein wordt.

Om de bovenstaande problemen te overwinnen, wordt een eenvoudige oplossing gegeven door het Karn/Partridge-algoritme. Dit algoritme gaf een eenvoudige oplossing die de in één keer verzonden monsters verzamelt en geen rekening houdt met de monsters op het tijdstip van herverzending voor het berekenen van de geschatte RTT.

Karn/Partridge-algoritme

In de bovenstaande twee scenario's vindt hertransmissie plaats en hebben we de voorbeeld-RTT overwogen. Maar dit algoritme houdt bij het opnieuw verzenden geen rekening met de Sample RTT. Omdat de hertransmissie heeft plaatsgevonden, wat betekent dat er iets gebeurt tijdens deze retourtijd of dat er enige congestie kan optreden in een netwerk. Om dit probleem te ondervangen, verdubbelt dit algoritme de time-out na elke hertransmissie. Dit algoritme is geïmplementeerd in het TCP-netwerk.

Beperking

Er wordt geen rekening gehouden met de variantie in RTT.

    Als de variantie klein is, blijkt de EstimatedRTT accuraat te zijn. Als de variantie groot is, is de EstimatedRTT niet nauwkeurig.

Om de bovenstaande beperking te overwinnen, werd het Jacobson/Karels-algoritme ontwikkeld dat de variantiefactor in RTT introduceert.

Jacobson/Karels-algoritme

Dit algoritme is ontwikkeld om de beperking van de Karn/Patrijs algoritme. Het berekent het verschil tussen de SampleRTT en EstimatedRTT en verhoogt de RTT op basis van het verschil.

Berekeningen voor gemiddelde RTT

  • Eerst berekenen we de verschilfactor.

Verschil = SampleRTT - Geschatte RTT

Java-klasse voorbeeld
  • Nu berekenen we de EstimatedRTT, die op dezelfde manier wordt berekend als hierboven.

EstRTT = EstRTT + (δ*Verschil)

  • Nu berekenen we het gemiddelde van de verschilfactor.

Dev = Dev + δ ( |Verschil| - Dev)

Hier is Dev een afwijkingsfactor, en δ een factor tussen 0 en 1. The Ontwikkelaar is een schatting van de variantie van de EstRTT .

arrays retourneren in Java
  • We houden rekening met de variantie bij het berekenen van de time-outwaarde.
Time-out = µ * EstRTT + ɸ * Dev

Waar, µ =1 en ɸ =4

Snelle hertransmissie

De op time-outs gebaseerde strategie voor hertransmissie is inefficiënt. TCP is een protocol met een glijdend venster, dus telkens wanneer de hertransmissie plaatsvindt, begint het met het verzenden ervan vanaf het verloren pakket.

TCP-hertransmissie

Stel dat ik de pakketten 0, 1, 2 en 3 verzend. Omdat pakket 0 en pakket 1 aan de andere kant worden ontvangen, gaat pakket 2 verloren in een netwerk. Ik heb de bevestiging van pakket 0 en pakket 1 ontvangen, dus ik verzend nog twee pakketten, dat wil zeggen pakket 4 en pakket 5. Wanneer pakketten 3, 4 en 5 worden verzonden, krijg ik de bevestiging van pakket 1 als TCP-bevestigingen zijn cumulatief, dus het bevestigt het pakket dat het in volgorde heeft ontvangen. Ik heb de bevestiging van pakket 2, 3,4 en 5 niet binnen de time-outperiode ontvangen, dus verzend ik de pakketten 2, 3, 4 en 5 opnieuw. Omdat pakket 2 verloren is gegaan, kunnen andere pakketten, d.w.z. 3, 4 ,5 aan de andere kant worden ontvangen, worden ze nog steeds opnieuw verzonden vanwege dit time-outmechanisme.

Hoe kan deze time-outinefficiëntie worden opgeheven?

De betere oplossing onder een schuifraam:

Stel dat n pakket verloren is gegaan, maar toch zijn de pakketten n+1, n+2, enzovoort ontvangen. De ontvanger ontvangt voortdurend de pakketten en verzendt de ACK-pakketten, waarbij hij aangeeft dat de ontvanger nog steeds op het zoveelste pakket wacht. De ontvanger verzendt herhaalde of dubbele bevestigingen. In het bovenstaande geval wordt de ACK van pakket 1 driemaal verzonden omdat pakket 2 verloren is gegaan. Dit dubbele ACK-pakket is een indicatie dat het n-de pakket ontbreekt, maar dat de latere pakketten zijn ontvangen.

Bovenstaande situatie kan op de volgende manieren worden opgelost:

  • De afzender kan de 'dubbele ACK's' gebruiken als een vroege aanwijzing dat het n-de pakket verloren is gegaan, zodat de afzender de hertransmissie zo vroeg mogelijk kan uitvoeren, dat wil zeggen dat de afzender niet moet wachten tot de time-out optreedt.
  • De afzender kan in TCP een snelle transmissiestrategie implementeren. Bij een snelle transmissiestrategie moet de afzender de driedubbele dubbele ACK's als een trigger beschouwen en deze opnieuw verzenden.

TCP gebruikt drie dubbele ACK's als trigger en voert vervolgens een hertransmissie uit. In het bovenstaande geval, wanneer drie ACK's van pakket 1 worden ontvangen, moet de afzender het verloren pakket, dat wil zeggen pakket 2, verzenden zonder te wachten tot de time-outperiode is aangebroken.