TCP uzticamības transports
Mēs visi esam pazīstami ar TCP protokolu kā uzticamu transporta protokolu, bet kā tas nodrošina transporta uzticamību?
Lai panāktu ticamu pārraidi, jāņem vērā daudzi faktori, piemēram, datu korupcija, zaudējumi, dublēšanās un ārpus pasūtījuma šķembas. Ja šīs problēmas nevar atrisināt, nevar sasniegt uzticamu pārraidi.
Tāpēc TCP izmanto tādus mehānismus kā secības numurs, apstiprināšanas atbilde, kontrole, savienojuma pārvaldība un logu vadība, lai panāktu uzticamu pārraidi.
Šajā rakstā mēs koncentrēsimies uz bīdāmo logu, plūsmas kontroli un TCP sastrēgumu kontroli. Nākamajā sadaļā retranslācijas mehānisms ir pārklāts atsevišķi.
Tīkla plūsmas kontrole
Tīkla plūsmas kontrole vai kā tīkla trafika kontrole faktiski ir smalku attiecību izpausme starp ražotājiem un patērētājiem. Jūs, iespējams, esat daudz saskāries ar šo scenāriju darbā vai intervijās. Ja ražotāja spēja ražot ievērojami pārsniedz patērētāja spēju patērēt, tas liks rindai augt uz nenoteiktu laiku. Nopietnākā gadījumā jūs varat zināt, ka tad, kad RabbitMQ ziņojumi sakrīt pārāk daudz, tas var izraisīt visa MQ servera veiktspējas sadalīšanos. Tas pats attiecas uz TCP; Ja netiks pārbaudīts, tīklā tiks ievietoti pārāk daudz ziņojumu, un patērētāji būs pārsnieguši savu jaudu, savukārt ražotāji turpinās nosūtīt ziņojumu dublikātus, kas ievērojami ietekmēs tīkla veiktspēju.
Lai risinātu šo parādību, TCP nodrošina sūtītāja mehānismu, lai kontrolētu nosūtīto datu daudzumu, pamatojoties uz uztvērēja faktisko uzņemšanas spēju, kas pazīstams kā plūsmas kontrole. Uztvērējs uztur saņemšanas logu, bet sūtītājs uztur nosūtīšanas logu. Jāatzīmē, ka šie logi ir paredzēti tikai vienam TCP savienojumam, un ne visiem savienojumiem ir kopīgs logs.
TCP nodrošina plūsmas kontroli, izmantojot mainīgo uztveršanas logam. Saņemšanas logs sniedz sūtītājam norādi par to, cik daudz vietas joprojām ir pieejama. Sūtītājs kontrolē nosūtīto datu daudzumu atbilstoši uztvērēja faktiskajai pieņemšanas jaudai.
Uztvērēja resursdators paziņo sūtītājam par saņemto datu lielumu, un sūtītājs nosūta līdz šim ierobežojumam. Šis ierobežojums ir loga izmērs, atcerieties TCP galveni? Ir saņemšanas loga lauks, ko izmanto, lai norādītu baitu skaitu, ko uztvērējs spēj vai vēlas saņemt.
Sūtītāja resursdators periodiski nosūtīs loga zondes paketi, kuru izmanto, lai noteiktu, vai uztvērēja resursdators joprojām spēj pieņemt datus. Kad uztvērēja buferim draud pārpildīšana, loga lielums ir iestatīts uz mazāku vērtību, lai nosūtītu sūtītāju kontrolēt nosūtīto datu daudzumu.
Šeit ir tīkla plūsmas vadības diagramma:
Tīkla sastrēgumu kontrole
Pirms sastrēgumu kontroles ieviešanas mums jāsaprot, ka papildus saņemšanas logam un sūtīšanas logam ir arī sastrēgumu logs, kuru galvenokārt izmanto, lai atrisinātu problēmu, kādā ātrumā sūtītājs sāk sūtīt datus uz saņemšanas logu. Tāpēc sastrēguma logu uztur arī TCP sūtītājs. Mums ir nepieciešams algoritms, lai izlemtu, cik daudz datu ir piemērots, jo pārāk maz vai pārāk daudz datu nosūtīšana nav ideāla, tātad sastrēguma loga jēdziens.
Iepriekšējā tīkla plūsmas kontrolē mēs izvairījāmies no tā, ka sūtītājs aizpildīja uztvērēja kešatmiņu ar datiem, bet mēs nezinājām, kas notiek tīklā. Parasti datortīkli atrodas kopīgā vidē. Tā rezultātā var būt sastrēgumi tīklā sakarā ar citiem resursdatoriem.
Kad tīkls ir pārslogots, ja turpina nosūtīt lielu skaitu pakešu, tas var izraisīt tādas problēmas kā pakešu kavēšanās un zaudēšana. Šajā brīdī TCP atkārtotu datus, bet retranslācija palielinās slogu tīklā, kā rezultātā tiks veikti lielāki kavējumi un lielāki pakešu zudumi. Tas var nokļūt apburtā ciklā un turpināt kļūt lielāks.
Tādējādi TCP nevar ignorēt to, kas notiek tīklā. Kad tīkls ir pārslogots, TCP upurē sevi, samazinot to nosūtīto datu daudzumu.
Tāpēc tiek ierosināta sastrēgumu kontrole, kuras mērķis ir izvairīties no visa tīkla aizpildīšanas ar sūtītāja datiem. Lai regulētu sūtītāja datu daudzumu, TCP definē koncepciju, ko sauc par sastrēguma logu. Sastrēguma kontroles algoritms pielāgos sastrēguma loga lielumu atbilstoši tīkla sastrēguma pakāpei, lai kontrolētu sūtītāja nosūtīto datu daudzumu.
Kas ir sastrēgumu logs? Kāds tam sakars ar sūtīšanas logu?
Sastrēguma logs ir standarta mainīgais lielums, ko uztur sūtītājs, kas nosaka sūtītāja datu daudzumu. Sastrēguma logs mainās dinamiski atbilstoši tīkla sastrēgumu līmenim.
Sūtīšanas logs ir saskaņots ar loga lielumu starp sūtītāju un uztvērēju, kas norāda datu daudzumu, ko uztvērējs var saņemt. Sastrēguma logs un sūtīšanas logs ir saistīti; Sūtīšanas logs parasti ir vienāds ar minimālo sastrēgumu un saņemošo logu, tas ir, swnd = min (cwnd, rwnd).
Sastrēguma logs CWND mainās šādi:
Ja tīklā nav sastrēgumu, ti, nenotiek retranslācijas taimauts, sastrēgumu logs palielinās.
Ja tīklā ir sastrēgumi, sastrēgumu logs samazinās.
Sūtītājs nosaka, vai tīkls ir pārslogots, novērojot, vai ACK apstiprināšanas pakete tiek saņemta noteiktā laikā. Ja sūtītājs noteiktā laikā nesaņem ACK apstiprināšanas paketi, tiek uzskatīts, ka tīkls ir pārslogots.
Papildus sastrēgumu logam ir pienācis laiks apspriest TCP sastrēgumu kontroles algoritmu. TCP sastrēgumu kontroles algoritms sastāv no trim galvenajām daļām:
Lēns sākums:Sākotnēji CWND sastrēguma logs ir salīdzinoši mazs, un sūtītājs eksponenciāli palielina sastrēguma logu, lai ātri pielāgotos tīkla ietilpībai.
Izvairīšanās no sastrēgumiem:Pēc tam, kad sastrēgumu logs pārsniedz noteiktu slieksni, sūtītājs lineāri palielina sastrēguma logu, lai palēninātu sastrēguma loga augšanas ātrumu un izvairītos no tīkla pārslodzes.
Ātra atveseļošanās:Ja rodas sastrēgumi, sūtītāja uz pusi samazina sastrēgumu logu un nonāk ātrās atkopšanas stāvoklī, lai noteiktu tīkla atveseļošanās vietu, izmantojot saņemtos dublikātus ACK, un pēc tam turpina palielināt sastrēguma logu.
Lēns sākums
Kad ir izveidots TCP savienojums, sastrēguma logs CWND sākotnēji tiek iestatīts uz minimālo MSS (maksimālā segmenta lieluma) vērtību. Tādā veidā sākotnējā sūtīšanas likme ir saistīta ar MSS/RTT baitiem sekundē. Faktiskais pieejamais joslas platums parasti ir daudz lielāks nekā MSS/RTT, tāpēc TCP vēlas atrast optimālo nosūtīšanas ātrumu, ko var sasniegt, izmantojot lēni.
Lēnām palaišanas procesā sastrēguma loga CWND vērtība tiks inicializēta uz 1 MSS, un katru reizi, kad tiek atzīta pārraidītā pakešu segments, CWND vērtība tiks palielināta par vienu MSS, tas ir, CWND vērtība kļūs 2 MSS. Pēc tam CWND vērtība tiek dubultota katrai veiksmīgai pakešu segmenta pārraidei utt. Īpašais augšanas process ir parādīts nākamajā attēlā.
Tomēr sūtīšanas ātrums ne vienmēr var pieaugt; izaugsmei kādreiz ir jābeidzas. Tātad, kad beidzas sūtīšanas likme? Lēnām palaišanas parasti tiek izbeigts sūtīšanas ātruma pieaugums vienā no vairākiem veidiem:
Pirmais veids ir pakešu zaudēšanas gadījums lēnas sākuma sūtīšanas procesa laikā. Kad rodas pakešu zudums, TCP iestata sūtītāja sastrēguma logu CWND uz 1 un restartē lēnas sākuma procesu. Šajā brīdī tiek ieviesta lēna sākuma sliekšņa SSTHRESS koncepcija, kuras sākotnējā vērtība ir puse no CWND vērtības, kas rada pakešu zudumus. Tas ir, kad tiek atklāti sastrēgumi, SSTHRESH vērtība ir puse no loga vērtības.
Otrais veids ir tieši korelēt ar lēnām palaišanas sliekšņa SSHRESH vērtību. Tā kā SSTHRESH vērtība ir puse no loga vērtības, kad tiek atklāti sastrēgumi, pakešu zudums var rasties ar katru divkāršošanos, ja CWND ir lielāks par SSTHRESH. Tāpēc vislabāk ir iestatīt CWND uz SSTHRESH, kas liks TCP pārslēgties uz sastrēguma vadības režīmu un beigas palēnināt.
Pēdējais veids, kā lēns sākums var beigties, ir tad, ja tiek atklāti trīs lieki ACK, TCP veic ātru atkārtotu retranslāciju un nonāk atveseļošanās stāvoklī. (Ja nav skaidrs, kāpēc ir trīs ACK paketes, tas tiks izskaidrots atsevišķi retranslācijas mehānismā.)
Izvairīšanās no sastrēgumiem
Kad TCP nonāk sastrēgumu kontroles stāvoklī, CWND ir iestatīts uz pusi no sastrēguma sliekšņa SSTHRESH. Tas nozīmē, ka CWND vērtību nevar dubultot katru reizi, kad tiek saņemts pakešu segments. Tā vietā tiek izmantota salīdzinoši konservatīva pieeja, kurā pēc katras pārraides pabeigšanas CWND vērtību palielina tikai viens MSS (maksimālais pakešu segmenta garums). Piemēram, pat ja tiek atzīti 10 pakešu segmenti, CWND vērtība palielināsies tikai par vienu MSS. Šis ir lineārs augšanas modelis, un tam ir arī augšējā robeža uz augšanu. Kad rodas pakešu zudumi, CWND vērtība tiek mainīta uz MSS, un SSTHRESH vērtība ir iestatīta uz pusi no CWND. Vai arī tas pārtrauks arī MSS pieaugumu, kad tiks saņemtas 3 liekas ACK atbildes. Ja pēc CWND vērtības samazināšanas joprojām tiek saņemti trīs lieki ACK, SSTHRESH vērtību reģistrē kā pusi no CWND vērtības un ievadīts ātras atveseļošanās stāvoklis.
Ātra atveseļošanās
Ātrās atveseļošanās stāvoklī sastrēguma loga CWND vērtība tiek palielināta par vienu MSS par katru saņemto lieko ACK, tas ir, ACK, kas nenāk secībā. Tas ir paredzēts, lai izmantotu pakešu segmentus, kas ir veiksmīgi pārsūtīti tīklā, lai pēc iespējas uzlabotu pārraides efektivitāti.
Kad pienāk zaudētā pakešu segmenta ACK, TCP samazina CWND vērtību un pēc tam nonāk sastrēgumu izvairīšanās stāvoklī. Tas ir paredzēts, lai kontrolētu sastrēguma loga lielumu un izvairītos no vēl vairāk palielināt tīkla sastrēgumus.
Ja pēc sastrēgumu kontroles stāvokļa notiek taimauts, tīkla stāvoklis kļūst nopietnāks un TCP migrē no sastrēgumu novēršanas stāvokļa uz lēnas starta stāvokli. Šajā gadījumā sastrēguma loga CWND vērtība ir iestatīta uz 1 MSS, maksimālais pakešu segmenta garums, un lēnas palaišanas sliekšņa SSTHRESH vērtība ir iestatīta uz pusi no CWND. Tā mērķis ir pārvērtēt pārslodzes loga lielumu pēc tīkla atveseļošanās, lai līdzsvarotu pārraides ātrumu un tīkla sastrēgumu pakāpi.
Kopsavilkums
Kā uzticams transporta protokols TCP ievieš uzticamu transportu pēc secības numura, apstiprināšanas, retranslācijas kontroles, savienojuma pārvaldības un logu vadības. Starp tiem plūsmas kontroles mehānisms kontrolē sūtītāja nosūtīto datu daudzumu atbilstoši uztvērēja faktiskajai saņēmēja spējai, kas ļauj izvairīties no tīkla sastrēgumu un veiktspējas sadalīšanās problēmām. Sastrēgumu kontroles mehānisms ļauj izvairīties no tīkla sastrēgumu rašanās, pielāgojot sūtītāja nosūtīto datu daudzumu. Sastrēgumu loga un sūtīšanas loga jēdzieni ir savstarpēji saistīti, un datu apjoms pie sūtītāja tiek kontrolēts, dinamiski pielāgojot sastrēguma loga lielumu. Lēna sākums, izvairīšanās no sastrēgumiem un ātra atveseļošanās ir trīs galvenās TCP sastrēgumu kontroles algoritma daļas, kas pielāgo sastrēguma loga lielumu, izmantojot dažādas stratēģijas, lai pielāgotos tīkla jaudai un sastrēguma pakāpei.
Nākamajā sadaļā mēs sīki izpētīsim TCP atkārtotas pārraides mehānismu. Retranslācijas mehānisms ir svarīga TCP sastāvdaļa, lai panāktu uzticamu pārraidi. Tas nodrošina ticamu datu pārraidi, pārraidot zaudētus, sabojātus vai aizkavējušos datus. Nākamajā sadaļā sīki tiks ieviests un analizēts retranslācijas mehānisma ieviešanas princips un stratēģija. Sekojiet līdzi!
Pasta laiks: 24.-2025. Februāris
