TCP atkārtota pārraide nozīmē pazaudēto vai bojāto pakešu atkārtotu nosūtīšanu tīklā. Šeit retranslācija ir mehānisms, ko izmanto tādi protokoli kā TCP nodrošināt uzticamu saziņu. Šeit uzticama komunikācija nozīmē, ka protokols garantē pakešu piegādi pat tad, ja datu pakete ir pazaudēta vai bojāta.
kāda kolekcija java
Tīkli ir neuzticami un negarantē pazaudēto vai bojāto pakešu aizkavēšanos vai atkārtotu pārsūtīšanu. Tīkls, kas izmanto bojātu vai pazaudētu pakešu apstiprinājuma un atkārtotas pārsūtīšanas kombināciju, nodrošina uzticamību.
Retranslācijas mehānisms
Šeit atkārtota pārsūtīšana nozīmē, ka datu paketes ir pazaudētas, kas izraisa apstiprinājuma trūkumu. Šis apstiprinājuma trūkums izraisa taimeri līdz taimautai, kas noved pie datu pakešu atkārtotas pārsūtīšanas. Šeit taimeris nozīmē, ka, ja pirms taimera termiņa beigām netiek saņemts apstiprinājums, datu pakete tiek pārsūtīta atkārtoti.
Apskatīsim šādus retranslācijas scenārijus.
1. scenārijs: kad datu pakete ir pazaudēta vai kļūdaina.
Šajā scenārijā pakete tiek nosūtīta saņēmējam, bet šajā taimauta periodā netiek saņemts apstiprinājums. Kad taimauta periods beidzas, pakete tiek atkārtoti nosūtīta. Kad pakete tiek atkārtoti pārsūtīta, tiek saņemts apstiprinājums. Kad apstiprinājums ir saņemts, atkārtota pārraide vairs netiks veikta.
2. scenārijs: kad pakete ir saņemta, bet apstiprinājums tiek pazaudēts.
Šajā scenārijā pakete tiek saņemta no otras puses, bet tiek zaudēts apstiprinājums, t.i., ACK netiek saņemts sūtītāja pusē. Kad taimauta periods beidzas, pakete tiek nosūtīta atkārtoti. Otrā pusē ir divas pakešu kopijas; lai gan pakete tiek saņemta pareizi, apstiprinājums netiek saņemts, tāpēc sūtītājs atkārtoti pārsūta paketi. Šajā gadījumā no atkārtotas pārraides varēja izvairīties, taču ACK zaudēšanas dēļ pakete tiek pārsūtīta.
3. scenārijs: kad iestājas agrīnais taimauts.
Šādā gadījumā pakete tiek nosūtīta, bet apstiprinājuma aizkaves vai taimauta dēļ pirms faktiskā taimauta, pakete tiek pārsūtīta atkārtoti. Šajā gadījumā pakete ir atkārtoti bez vajadzības nosūtīta apstiprinājuma aizkavēšanās dēļ vai taimauts ir iestatīts agrāk nekā faktiskais taimauts.
Iepriekš minētajos scenārijos nevar izvairīties no pirmā scenārija, bet no pārējiem diviem scenārijiem var izvairīties. Apskatīsim, kā mēs varam izvairīties no šādām situācijām.
Cik ilgi sūtītājam jāgaida?
peles ritināšana nedarbojas
Sūtītājs iestata ACK taimauta periodu. Taimauta periods var būt divu veidu:
Lai pārvarētu divas iepriekš minētās situācijas, TCP iestata taimautu kā RTT (turp un atpakaļ laiks) funkciju, kur turp un atpakaļ laiks ir laiks, kas nepieciešams, lai pakete nokļūtu no avota līdz galamērķim un pēc tam atgrieztos vēlreiz.
Kā mēs varam iegūt RTT?
RTT var atšķirties atkarībā no tīkla īpašībām, t.i., ja tīkls ir pārslogots, tas nozīmē, ka RTT ir ļoti augsts. Mēs varam novērtēt RTT, vienkārši skatoties ACK.
Apskatīsim, kā mēs varam izmērīt RTT.
Mēs izmantosim oriģināls algoritms lai izmērītu RTT.
1. darbība: Pirmkārt, mēs izmērām RTT paraugs katram segmentam vai ACK pārim. Kad sūtītājs nosūta paketi, mēs zinām taimeri, kurā pakete tiek nosūtīta, kā arī mēs zinām taimeri, kurā tiek saņemts apstiprinājums. Aprēķiniet laiku starp šiem diviem, un tas kļūst par RTT paraugs .
2. darbība: Mēs neņemsim tikai vienu paraugu. Mēs turpināsim ņemt dažādus paraugus un aprēķināsim šo paraugu vidējo svērto vērtību, un tas kļūs par EstRTT (Estimated RTT).
kur α+ β = 1
α ir no 0,8 līdz 0,9
β ir no 0,1 līdz 0,2
3. darbība: Taimauts ir iestatīts, pamatojoties uz EstRTT.
taimauts = 2 * EstRTT.
Taimauts ir iestatīts kā divreiz lielāks par aprēķināto RTT. Šādi tiek aprēķināts faktiskais noildzes koeficients.
Šīs pieejas trūkums
Sākotnējā algoritmā ir kļūda. Apskatīsim divus scenārijus.
1. scenārijs.
Iepriekš redzamā diagramma parāda, ka sūtītājs nosūta datus, kas tiek uzskatīts par oriģinālu pārraidi. Taimauta periodā apstiprinājums netiek saņemts. Tātad sūtītājs atkārtoti pārsūta datus. Pēc datu atkārtotas pārsūtīšanas tiek saņemts apstiprinājums. Pieņemsim, ka apstiprinājums tiek saņemts par sākotnējo pārraidi, nevis par atkārtotu pārraidi. Tā kā mēs saņemam sākotnējās pārraides apstiprinājumu, tātad RTT paraugs tiek aprēķināts starp sākotnējās pārraides laiku un apstiprinājuma saņemšanas brīdi. Bet patiesībā, RTT paraugs jābūt starp atkārtotas pārraides laiku un apstiprinājuma laiku.
masīvs sakārtots java
2. scenārijs.
Iepriekš redzamā diagramma parāda, ka sūtītājs nosūta sākotnējo datu paketi, par kuru mēs arī saņemam apstiprinājumu. Bet apstiprinājums tiek saņemts pēc datu atkārtotas pārsūtīšanas. Ja pieņemam, ka apstiprinājums pieder pie retranslācijas, tad RTT paraugs tiek aprēķināts starp retranslācijas laiku un apstiprinājuma laiku.
Abos iepriekšminētajos scenārijos pastāv neskaidrība, ka nav zināms, vai apstiprinājums ir paredzēts sākotnējai vai atkārtotai pārraidei.
Iepriekš minētā algoritma secinājums.
- Šeit ACK nenozīmē pārraides apstiprināšanu, bet patiesībā tā apstiprina datu saņemšanu.
- Ja mēs ņemam vērā pirmo scenāriju, tiek veikta atkārtota pārraide zaudētajai paketei. Šajā gadījumā mēs pieņemam, ka ACK pieder sākotnējai pārraidei, kā dēļ SampleRTT ir ļoti liels.
- Ja ņemam vērā otro scenāriju, tiek nosūtītas divas vienas un tās pašas paketes, tāpēc šajā gadījumā rodas dublēšanās. Šajā gadījumā mēs pieņemam, ka ACK pieder atkārtotai pārraidei, kuras dēļ SampleRTT kļūst ļoti mazs.
Lai pārvarētu iepriekš minētās problēmas, vienkāršu risinājumu sniedz Karn/Partridge algoritms. Šis algoritms sniedza vienkāršu risinājumu, kas savāc vienā reizē nosūtītos paraugus un neņem vērā paraugus retranslācijas laikā, lai aprēķinātu aprēķināto RTT.
Karna/irbes algoritms
Iepriekš minētajos divos scenārijos notiek atkārtota pārraide, un mēs esam apsvēruši RTT paraugu. Taču šis algoritms atkārtotas pārraides laikā neņem vērā RTT paraugu. Kopš ir notikusi atkārtota pārraide, kas nozīmē, ka šajā turp un atpakaļ laikā kaut kas notiek vai tīklā var rasties pārslodze. Lai novērstu šo problēmu, šis algoritms pēc katras atkārtotas pārraides dubulto taimautu. Šis algoritms ir ieviests TCP tīklā.
Ierobežojums
Tas neņem vērā RTT atšķirības.
Lai pārvarētu iepriekš minēto ierobežojumu, tika izstrādāts Jacobson/Karels algoritms, kas ievieš dispersijas koeficientu RTT.
Jacobson/Karels Algorithm
Šis algoritms tika izstrādāts, lai pārvarētu ierobežojumus Karns/irbe algoritms. Tas aprēķina atšķirību starp SampleRTT un EstimatedRTT un palielina RTT, pamatojoties uz atšķirību.
Aprēķini par vidējo RTT
- Pirmkārt, mēs aprēķinām starpības koeficientu.
Atšķirība = SampleRTT — EstimatedRTT
- Tagad mēs aprēķinām EstimatedRTT, kas tiks aprēķināta tāpat kā iepriekš.
EstRTT = EstRTT + (δ*Atšķirība)
tipa mainīgie java
- Tagad mēs aprēķinām vidējo starpības koeficientu.
Dev = Dev + δ ( |Atšķirība| - Dev)
Šeit Dev ir novirzes koeficients, un δ ir koeficients no 0 līdz 1 Izstrādātājs ir novirzes aprēķins no EstRTT .
- Aprēķinot taimauta vērtību, mēs ņemsim vērā dispersiju.
kur, µ =1 un ɸ =4
Ātra retranslācija
Retranslācijas stratēģija, kas balstīta uz taimautu, ir neefektīva. TCP ir bīdāmo logu protokols, tāpēc ikreiz, kad notiek atkārtota pārraide, tas sāk to sūtīt no pazaudētās paketes.
Pieņemsim, ka es pārsūtu paketes 0, 1, 2 un 3. Tā kā pakete 0 un pakete 1 tiek saņemtas no otras puses, 2. pakete tiek zaudēta tīklā. Esmu saņēmis 0. un 1. paketes apstiprinājumu, tāpēc nosūtu vēl divas paketes, t.i., 4. un 5. paketi. Kad tiks nosūtītas 3., 4. un 5. paketes, saņemšu 1. paketes apstiprinājumu kā TCP apstiprinājumus. ir kumulatīvi, tāpēc tā apstiprina līdz pat paketei, ko tā ir saņēmusi kārtībā. Taimauta periodā neesmu saņēmis apstiprinājumu par 2., 3., 4. un 5. paketi, tāpēc pārsūtu 2., 3., 4. un 5. paketes. Tā kā 2. pakete ir pazaudēta, bet citas paketes, t.i., 3., 4. ,5 tiek saņemti otrā pusē, tie joprojām tiek pārsūtīti šī taimauta mehānisma dēļ.
mac operētājsistēmas
Kā var novērst šo taimauta neefektivitāti?
Labāks risinājums zem bīdāmā loga:
Pieņemsim, ka n pakete ir pazaudēta, bet tomēr ir saņemtas paketes n+1, n+2 un tā tālāk. Uztvērējs nepārtraukti saņem paketes un sūta ACK paketes, sakot, ka uztvērējs joprojām gaida n-to paketi. Uztvērējs sūta atkārtotus vai dublētus apstiprinājumus. Iepriekš minētajā gadījumā 1. paketes ACK tiek nosūtīts trīs reizes, jo 2. pakete ir pazaudēta. Šī ACK paketes dublikāts norāda, ka trūkst n-tās paketes, bet tiek saņemtas vēlākās paketes.
Iepriekš minēto situāciju var atrisināt šādos veidos:
- Sūtītājs var uztvert “dublētos ACK” kā agrīnu mājienu, ka n-tā pakete ir pazaudēta, lai sūtītājs varētu veikt atkārtotu pārsūtīšanu pēc iespējas ātrāk, t.i., sūtītājam nevajadzētu gaidīt, līdz iestājas taimauts.
- Sūtītājs var ieviest ātrās pārraides stratēģiju TCP. Ātrās pārraides stratēģijā sūtītājam ir jāuzskata trīskāršie ACK dublikāti par trigeri un jāpārraida.
TCP izmanto trīs dublētus ACK kā trigeri un pēc tam veic atkārtotu pārraidi. Iepriekš minētajā gadījumā, kad tiek saņemti trīs 1. paketes ACK, sūtītājam ir jānosūta pazaudētā pakete, t.i., 2. pakete, negaidot taimauta periodu.