Retransmiterea TCP înseamnă retrimiterea prin rețea a pachetelor care au fost fie pierdute, fie deteriorate. Aici, retransmisia este un mecanism folosit de protocoale precum TCP pentru a oferi o comunicare fiabilă. Aici, comunicarea fiabilă înseamnă că protocolul garantează livrarea pachetului chiar dacă pachetul de date a fost pierdut sau deteriorat.
lista java este goală
Rețelele sunt nesigure și nu garantează întârzierea sau retransmiterea pachetelor pierdute sau deteriorate. Rețeaua care utilizează o combinație de recunoaștere și retransmitere a pachetelor deteriorate sau pierdute oferă fiabilitate.
Mecanism de retransmisie
Aici, retransmiterea înseamnă că pachetele de date au fost pierdute, ceea ce duce la o lipsă de confirmare. Această lipsă de confirmare declanșează un temporizator la expirarea timpului, ceea ce duce la retransmiterea pachetelor de date. Aici, temporizatorul înseamnă că, dacă nu se primește nicio confirmare înainte de expirarea temporizatorului, pachetul de date este retransmis.
Să luăm în considerare următoarele scenarii de retransmisie.
Scenariul 1: Când pachetul de date este pierdut sau este eronat.
În acest scenariu, pachetul este trimis la receptor, dar nu se primește nicio confirmare în acea perioadă de expirare. Când expiră perioada de expirare, pachetul este retrimis din nou. Când pachetul este retransmis, se primește confirmarea. Odată primită confirmarea, retransmisia nu va mai avea loc.
Scenariul 2: Când pachetul este primit, dar confirmarea este pierdută.
În acest scenariu, pachetul este primit pe cealaltă parte, dar confirmarea este pierdută, adică ACK-ul nu este primit pe partea expeditorului. Odată ce expiră perioada de expirare, pachetul este retrimis. Există două copii ale pachetelor pe cealaltă parte; deși pachetul este primit corect, confirmarea nu este primită, deci expeditorul retransmite pachetul. În acest caz, retransmisia ar fi putut fi evitată, dar din cauza pierderii ACK-ului, pachetul este retransmis.
Scenariul 3: când are loc timeout-ul timpuriu.
În acest scenariu, pachetul este trimis, dar din cauza întârzierii în confirmare sau a expirării timpului înainte de expirarea reală, pachetul este retransmis. În acest caz, pachetul a fost trimis din nou în mod inutil din cauza întârzierii în confirmare sau timeout-ul a fost setat mai devreme decât timeout-ul real.
În scenariile de mai sus, primul scenariu nu poate fi evitat, dar celelalte două scenarii pot fi evitate. Să vedem cum putem evita aceste situații.
Cât trebuie să aștepte expeditorul?
Expeditorul stabilește perioada de expirare pentru un ACK. Perioada de timeout poate fi de două tipuri:
Pentru a depăși cele două situații de mai sus, TCP setează timpul de expirare ca o funcție a RTT (durată dus-întors) unde timpul dus-întors este timpul necesar pentru ca pachetul să călătorească de la sursă la destinație și apoi să revină din nou.
Cum putem obține RTT-ul?
RTT-ul poate varia în funcție de caracteristicile rețelei, adică dacă rețeaua este aglomerată, înseamnă că RTT-ul este foarte mare. Putem estima RTT-ul pur și simplu urmărind ACK-urile.
Să vedem cum putem măsura RTT-ul.
Vom folosi algoritmul original pentru a măsura RTT-ul.
Pasul 1: În primul rând, măsurăm SampleRTT pentru fiecare segment sau pereche ACK. Când expeditorul trimite pachetul, atunci știm cronometrul la care este trimis pachetul și, de asemenea, știm cronometrul la care este primită confirmarea. Calculați timpul dintre acești doi și acesta devine SampleRTT .
starea git
Pasul 2: Nu vom lua doar o mostră. Vom continua să luăm diferite mostre și să calculăm media ponderată a acestor eșantioane, iar aceasta devine EstRTT (Estimated RTT).
unde, α+ β = 1
α este cuprins între 0,8 și 0,9
β este cuprins între 0,1 și 0,2
Pasul 3: Timeout-ul este setat pe baza EstRTT.
timeout = 2 * EstRTT.
Timeout-ul este setat să fie de două ori mai mare decât RTT estimat. Acesta este modul în care este calculat factorul de timeout real.
Un defect în această abordare
Există un defect în algoritmul original. Să luăm în considerare două scenarii.
dacă altceva java
Scenariul 1.
Diagrama de mai sus arată că expeditorul trimite datele, despre care se spune că este o transmisie originală. În perioada de expirare, nu se primește nicio confirmare. Deci, expeditorul retransmite datele. După retransmiterea datelor, se primește confirmarea. Să presupunem că confirmarea este primită pentru transmisia originală, nu pentru retransmisie. Din moment ce primim confirmarea transmisiei originale, deci SampleRTT se calculează între momentul transmiterii inițiale și momentul la care este primită confirmarea. Dar, de fapt, SampleRTT ar fi trebuit să fie între momentul retransmiterii și momentul confirmării.
Scenariul 2.
Diagrama de mai sus arată că expeditorul trimite pachetul de date original pentru care primim și confirmarea. Dar confirmarea se primește după retransmiterea datelor. Dacă presupunem că recunoașterea aparține retransmisiei, atunci SampleRTT se calculează între momentul retransmisiei și momentul confirmării.
În ambele scenarii de mai sus, există o ambiguitate de a nu ști dacă confirmarea este pentru transmisia originală sau pentru retransmisie.
Concluzia algoritmului de mai sus.
- Aici, ACK nu înseamnă a confirma o transmitere, ci de fapt, confirmă primirea datelor.
- Dacă luăm în considerare primul scenariu, retransmisia se face pentru pachetul pierdut. În acest caz, presupunem că ACK aparține transmisiei originale, datorită căreia SampleRTT devine foarte mare.
- Dacă luăm în considerare cel de-al doilea scenariu, sunt trimise două aceleași pachete, astfel încât apare duplicitatea în acest caz. În acest caz, presupunem că ACK aparține retransmisiei, datorită căreia SampleRTT devine foarte mic.
Pentru a depăși problemele de mai sus, o soluție simplă este dată de algoritmul Karn/Partridge. Acest algoritm a oferit o soluție simplă care colectează probele trimise la un moment dat și nu ia în considerare probele la momentul retransmisiei pentru calcularea RTT-ului estimat.
Algoritmul Karn/Partridge
În cele două scenarii de mai sus, are loc retransmisia și am luat în considerare Eșantionul RTT. Dar acest algoritm nu ia în considerare Sample RTT atunci când retransmite. Din moment ce a avut loc retransmisia, ceea ce înseamnă că se întâmplă ceva în acest timp dus-întors sau poate apărea o congestie într-o rețea. Pentru a depăși această problemă, acest algoritm dublează timpul de expirare după fiecare retransmisie. Acest algoritm este implementat în rețeaua TCP.
Prescripţie
Nu ia în considerare variația în RTT.
bin la bcd
Pentru a depăși limitarea de mai sus, a fost dezvoltat algoritmul Jacobson/Karels care introduce factorul de varianță în RTT.
Algoritmul Jacobson/Karels
Acest algoritm a fost dezvoltat pentru a depăși limitarea Karn/Partridge algoritm. Acesta calculează diferența dintre SampleRTT și EstimatedRTT și crește RTT-ul pe baza diferenței.
Calcule pentru RTT mediu
- Mai întâi, calculăm factorul de diferență.
Diferență = SampleRTT - EstimatedRTT
- Acum, calculăm EstimatedRTT, care va fi calculat în același mod ca și mai sus.
EstRTT = EstRTT + (δ*Dif)
- Acum, calculăm media factorului de diferență.
Dev = Dev + δ ( |Dif| - Dev)
Aici, Dev este un factor de abatere, iar δ este un factor între 0 și 1. The Dev este o estimare a varianței de la EstRTT .
- Vom lua în considerare variația în timp ce calculăm valoarea timeout.
Unde, µ =1 și ɸ =4
jbutton
Retransmisie rapidă
Strategia bazată pe timeout pentru retransmisie este ineficientă. TCP este un tip de protocol cu fereastră glisantă, așa că ori de câte ori are loc retransmisia, începe să-l trimită de la pachetul pierdut.
Să presupunem că transmit pachetele 0, 1, 2 și 3. Deoarece pachetul 0 și pachetul 1 sunt primite pe cealaltă parte, pachetul 2 se pierde într-o rețea. Am primit confirmarea pachetului 0 și a pachetului 1, așa că mai trimit două pachete, adică pachetul 4 și pachetul 5. Când sunt trimise pachetele 3, 4 și 5, atunci voi primi confirmarea pachetului 1 ca confirmări TCP sunt cumulative, deci confirmă până la pachetul pe care l-a primit în ordine. Nu am primit confirmarea pachetului 2, 3,4 și 5 în perioada de expirare, așa că retransmit pachetele 2, 3, 4 și 5. Deoarece pachetul 2 este pierdut, dar alte pachete, adică 3, 4 ,5 sunt recepționate pe cealaltă parte, sunt încă retransmise din cauza acestui mecanism de timeout.
Cum poate fi eliminată această ineficiență de timeout?
Soluția mai bună sub o fereastră glisantă:
Să presupunem că n pachet a fost pierdut, dar totuși, pachetele n+1, n+2 și așa mai departe au fost primite. Receptorul primește continuu pachetele și trimite pachetele ACK spunând că receptorul încă așteaptă al n-lea pachet. Destinatorul trimite confirmări repetate sau duplicate. În cazul de mai sus, ACK al pachetului 1 este trimis de trei ori, deoarece pachetul 2 a fost pierdut. Acest pachet ACK duplicat este o indicație că al n-lea pachet lipsește, dar pachetele ulterioare sunt primite.
Situația de mai sus poate fi rezolvată în următoarele moduri:
- Expeditorul poate lua „ACK-urile duplicate” ca un indiciu timpuriu că al n-lea pachet a fost pierdut, astfel încât expeditorul să poată face retransmisia cât mai devreme posibil, adică expeditorul nu ar trebui să aștepte până la expirarea timpului.
- Expeditorul poate implementa o strategie de transmisie rapidă în TCP. Într-o strategie de transmisie rapidă, expeditorul ar trebui să ia în considerare ACK-urile triple duplicate ca un declanșator și să-l retransmite.
TCP folosește trei ACK-uri duplicat ca declanșator și apoi efectuează retransmisia. În cazul de mai sus, când sunt primite trei ACK-uri ale pachetului 1, atunci expeditorul ar trebui să trimită pachetul pierdut, adică pachetul 2, fără a aștepta ca perioada de expirare să aibă loc.