La retransmissió TCP significa tornar a enviar a través de la xarxa els paquets que s'han perdut o s'han danyat. Aquí, la retransmissió és un mecanisme utilitzat per protocols com ara TCP per proporcionar una comunicació fiable. Aquí, una comunicació fiable significa que el protocol garanteix el lliurament del paquet fins i tot si el paquet de dades s'ha perdut o s'ha fet malbé.
convertir un objecte java a json
Les xarxes no són fiables i no garanteixen el retard o la retransmissió dels paquets perduts o danyats. La xarxa que utilitza una combinació de reconeixement i retransmissió de paquets danyats o perduts ofereix fiabilitat.
Mecanisme de retransmissió
Aquí, la retransmissió significa que s'han perdut els paquets de dades, la qual cosa comporta una manca de reconeixement. Aquesta manca de reconeixement desencadena un temporitzador que s'esgota el temps d'espera, la qual cosa condueix a la retransmissió de paquets de dades. Aquí, el temporitzador significa que si no es rep cap confirmació abans que caduqui el temporitzador, el paquet de dades es retransmet.
Considerem els següents escenaris de retransmissió.
Escenari 1: quan el paquet de dades es perd o és erroni.
En aquest escenari, el paquet s'envia al receptor, però no es rep cap reconeixement dins d'aquest període de temps d'espera. Quan expira el període de temps d'espera, el paquet es torna a enviar. Quan es retransmet el paquet, es rep el reconeixement. Un cop rebut l'avís, la retransmissió no es tornarà a produir.
Escenari 2: quan es rep el paquet però es perd el reconeixement.
En aquest escenari, el paquet es rep a l'altre costat, però el reconeixement es perd, és a dir, l'ACK no es rep al costat del remitent. Un cop expirat el període de temps d'espera, el paquet es torna a enviar. A l'altre costat hi ha dues còpies dels paquets; tot i que el paquet es rep correctament, no es rep l'avís, de manera que el remitent retransmet el paquet. En aquest cas, es podria haver evitat la retransmissió, però a causa de la pèrdua de l'ACK, el paquet es retransmet.
Escenari 3: quan es produeix el temps d'espera primerenc.
En aquest escenari, el paquet s'envia, però a causa del retard en el reconeixement o el temps d'espera s'ha produït abans del temps d'espera real, el paquet es retransmet. En aquest cas, el paquet s'ha tornat a enviar innecessàriament a causa del retard en el reconeixement o el temps d'espera s'ha establert abans del temps d'espera real.
En els escenaris anteriors, el primer escenari no es pot evitar, però els altres dos escenaris es poden evitar. A veure com podem evitar aquestes situacions.
Quant de temps ha d'esperar el remitent?
El remitent estableix el període de temps d'espera per a un ACK. El període de temps d'espera pot ser de dos tipus:
Per superar les dues situacions anteriors, TCP estableix el temps d'espera en funció de l'RTT (temps d'anada i tornada), on el temps d'anada i tornada és el temps necessari perquè el paquet viatgi des de l'origen a la destinació i torni de nou.
Com podem obtenir la RTT?
El RTT pot variar en funció de les característiques de la xarxa, és a dir, si la xarxa està congestionada, vol dir que el RTT és molt alt. Podem estimar el RTT simplement mirant els ACK.
Vegem com podem mesurar la RTT.
Farem servir el algorisme original per mesurar el RTT.
Pas 1: Primer, mesurem el Mostra RTT per a cada segment o parell ACK. Quan l'emissor envia el paquet, sabem el temporitzador amb el qual s'envia el paquet i també sabem el temporitzador en què es rep l'avís. Calcula el temps entre aquests dos, i això es converteix en el Mostra RTT .
Pas 2: No prendrem només una mostra. Seguirem prenent diferents mostres i calculant la mitjana ponderada d'aquestes mostres, i aquesta es converteix en l'EstRTT (Estimated RTT).
on, α+ β = 1
α es troba entre 0,8 i 0,9
ls comanda linux
β es troba entre 0,1 i 0,2
Pas 3: El temps d'espera s'estableix en funció de l'EstRTT.
què significa google
temps d'espera = 2 * EstRTT.
El temps d'espera s'estableix per ser el doble de l'RTT estimat. Així és com es calcula el factor de temps d'espera real.
Un defecte en aquest enfocament
Hi ha un error en l'algoritme original. Considerem dos escenaris.
Escenari 1.
El diagrama anterior mostra que l'emissor envia les dades, que es diu que són una transmissió original. Dins del període de temps d'espera, no es rep cap justificant. Per tant, el remitent retransmet les dades. Després de retransmetre les dades, es rep el reconeixement. Suposem que el reconeixement es rep per a la transmissió original, no per a la retransmissió. Com que rebem el reconeixement de la transmissió original, així Mostra RTT es calcula entre el moment de la transmissió original i el moment en què es rep l'avís. Però en realitat, el Mostra RTT hauria d'haver estat entre el moment de la retransmissió i el moment del reconeixement.
Escenari 2.
El diagrama anterior mostra que el remitent envia el paquet de dades original del qual també rebem el reconeixement. Però el reconeixement es rep després de retransmetre les dades. Si suposem que el reconeixement pertany a la retransmissió, aleshores Mostra RTT es calcula entre el moment de la retransmissió i el moment del reconeixement.
En els dos escenaris anteriors, hi ha una ambigüitat de no saber si el reconeixement és per a la transmissió original o per a la retransmissió.
Conclusió de l'algorisme anterior.
- Aquí, ACK no vol dir reconèixer una transmissió, sinó que, en realitat, reconeix la recepció de les dades.
- Si considerem el primer escenari, la retransmissió es fa pel paquet perdut. En aquest cas, suposem que ACK pertany a la transmissió original a causa de la qual el SampleRTT està resultant molt gran.
- Si considerem el segon escenari, s'envien dos mateixos paquets, de manera que es produeix duplicitat en aquest cas. En aquest cas, suposem que ACK pertany a la retransmissió a causa de la qual el SampleRTT és molt petit.
Per superar els problemes anteriors, l'algorisme de Karn/Partridge dóna una solució senzilla. Aquest algorisme va donar una solució senzilla que recull les mostres enviades alhora i no considera les mostres en el moment de la retransmissió per calcular el RTT estimat.
Algoritme Karn/Partridge
En els dos escenaris anteriors, es produeix la retransmissió i hem considerat la mostra RTT. Però aquest algorisme no té en compte el Sample RTT quan es retransmet. Des que s'ha produït la retransmissió, el que significa que passa alguna cosa en aquest temps d'anada i tornada o que es pot produir alguna congestió en una xarxa. Per superar aquest problema, aquest algorisme duplica el temps d'espera després de cada retransmissió. Aquest algorisme s'implementa a la xarxa TCP.
Limitació
1 milió en dígits
No considera la variància en RTT.
Per superar la limitació anterior, es va desenvolupar l'algorisme de Jacobson/Karels que introdueix el factor de variància en RTT.
Algoritme Jacobson/Karels
Aquest algorisme es va desenvolupar per superar la limitació de la Karn/Perdiu algorisme. Calcula la diferència entre SampleRTT i EstimatedRTT i augmenta l'RTT en funció de la diferència.
Càlculs per a RTT mitjana
- En primer lloc, calculem el factor de diferència.
Diff = SampleRTT - EstimatedRTT
- Ara, calculem l'RTT estimat, que es calcularà de la mateixa manera que hem fet anteriorment.
EstRTT = EstRTT + (δ*Dif.)
- Ara, calculem la mitjana del factor de diferència.
Dev = Dev + δ ( |Dif| - Dev)
Aquí, Dev és un factor de desviació, i δ és un factor entre 0 i 1. El Dev és una estimació de la variància de la EstRTT .
- Considerarem la variància mentre calculem el valor del temps d'espera.
On, µ =1 i ɸ =4
Retransmissió ràpida
L'estratègia basada en el temps d'espera per a la retransmissió és ineficient. TCP és un tipus de protocol de finestra lliscant, de manera que sempre que es produeix la retransmissió, comença a enviar-lo a partir del paquet perdut.
Suposem que transmeto els paquets 0, 1, 2 i 3. Com que el paquet 0 i el paquet 1 es reben a l'altra banda, el paquet 2 es perd en una xarxa. He rebut el reconeixement del paquet 0 i el paquet 1, així que envio dos paquets més, és a dir, el paquet 4 i el paquet 5. Quan s'enviïn els paquets 3, 4 i 5, obtindré el reconeixement del paquet 1 com a reconeixements TCP són acumulatives, de manera que reconeix fins al paquet que ha rebut en ordre. No he rebut el reconeixement del paquet 2, 3,4 i 5 dins del període de temps d'espera, així que retransmet els paquets 2, 3, 4 i 5. Com que el paquet 2 s'ha perdut, però altres paquets, és a dir, 3, 4 ,5 es reben a l'altra banda, encara es retransmeten a causa d'aquest mecanisme de temps d'espera.
Com es pot eliminar aquesta ineficiència de temps d'espera?
La millor solució sota una finestra corredissa:
Suposem que s'ha perdut n paquet, però tot i així, s'han rebut els paquets n+1, n+2, etc. El receptor està rebent contínuament els paquets i enviant els paquets ACK dient que el receptor encara està esperant l'enèsim paquet. El receptor està enviant reconeixements repetits o duplicats. En el cas anterior, l'ACK del paquet 1 s'envia tres vegades, ja que el paquet 2 s'ha perdut. Aquest paquet ACK duplicat és una indicació que falta l'enèsim paquet, però es reben els paquets posteriors.
La situació anterior es pot resoldre de les maneres següents:
- El remitent pot prendre els 'ACKs duplicats' com una pista primerenca que s'ha perdut el paquet enèsimo, de manera que el remitent pugui fer la retransmissió tan aviat com sigui possible, és a dir, el remitent no hauria d'esperar fins que es produeixi el temps d'espera.
- El remitent pot implementar una estratègia de transmissió ràpida en TCP. En una estratègia de transmissió ràpida, l'emissor hauria de considerar els ACK duplicats triples com a activador i retransmetre'ls.
TCP utilitza tres ACK duplicats com a activador i després realitza la retransmissió. En el cas anterior, quan es reben tres ACK del paquet 1, el remitent hauria d'enviar el paquet perdut, és a dir, el paquet 2, sense esperar que es produeixi el període de temps d'espera.
proves de rendiment