TCP -luotettavuuskuljetus
Olemme kaikki perehtyneet TCP -protokollaan luotettavana kuljetusprotokollana, mutta miten se varmistaa kuljetuksen luotettavuuden?
Luotettavan siirron saavuttamiseksi on otettava huomioon monia tekijöitä, kuten tietojen korruptio, häviö, päällekkäisyys ja tilauksen ulkopuoliset sirut. Jos näitä ongelmia ei voida ratkaista, luotettavaa siirtoa ei voida saavuttaa.
Siksi TCP käyttää mekanismeja, kuten sekvenssinumero, kuittausvastaus, uudelleenohjaus, yhteydenhallinta ja ikkunoiden hallinta luotettavan siirron saavuttamiseksi.
Tässä artikkelissa keskitymme TCP: n liukuvaan ikkunaan, virtauksen hallintaan ja ruuhkien hallintaan. Uudelleenlähetysmekanismi katetaan erikseen seuraavassa osassa.
Verkon virtausohjaus
Verkkovirran hallinta tai tietoverkon liikenteen hallinta on oikeastaan osoitus tuottajien ja kuluttajien hienovaraisesta suhteesta. Olet todennäköisesti törmännyt tähän skenaarioon paljon työssä tai haastatteluissa. Jos tuottajan kyky tuottaa huomattavasti ylittää kuluttajan kykyä kuluttaa, se aiheuttaa jonon kasvamisen määräämättömäksi ajaksi. Vakavammassa tapauksessa saatat tietää, että kun RabbitMQ -viestit kasaantuvat liikaa, se voi aiheuttaa koko MQ -palvelimen suorituskyvyn heikkenemisen. Sama pätee TCP: hen; Jos jätetään tarkistamatta, verkkoon laitetaan liian monta viestiä, ja kuluttajat ovat ylittäneet kapasiteettinsa, kun taas tuottajat lähettävät edelleen kaksoisviestit, mikä vaikuttaa suuresti verkon suorituskykyyn.
Tämän ilmiön käsittelemiseksi TCP tarjoaa lähettäjälle mekanismin ohjaamaan lähetetyn tiedon määrää vastaanottimen todellisen vastaanottokapasiteetin perusteella, jota kutsutaan virtauksen hallintaan. Vastaanotin ylläpitää vastaanottoikkunaa, kun lähettäjä ylläpitää lähetysikkunaa. On huomattava, että nämä ikkunat ovat vain yhdelle TCP -yhteydelle, eikä kaikki yhteydet jakavat ikkunaa.
TCP tarjoaa virtausohjauksen käyttämällä muuttujaa vastaanottoikkunaan. Vastaanotto -ikkuna antaa lähettäjälle ilmoituksen siitä, kuinka paljon välimuistitilaa on edelleen saatavana. Lähettäjä hallitsee vastaanottimen todellisen hyväksymiskapasiteetin mukaista tiedon määrää.
Vastaanottimen isäntä ilmoittaa lähettäjälle, joka on saamansa tietojen koon, ja lähettäjä lähettää tähän rajaan. Tämä raja on ikkunan koko, muistatko TCP -otsikon? Siellä on vastaanottoikkuna -kenttä, jota käytetään ilmoittamaan tavujen lukumäärä, jonka vastaanotin pystyy tai halukas vastaanottamaan.
Lähettäjä isäntä lähettää säännöllisesti ikkuna -anturipaketin, jota käytetään havaitsemaan, pystyykö vastaanottimen isäntä edelleen hyväksymään tietoja. Kun vastaanottimen puskuri on vaarassa ylivuotoa, ikkunan koko on asetettu pienemmäksi arvoon ohjaamaan lähettäjää ohjaamaan lähetettyjen tietojen määrää.
Tässä on verkon virtauksen ohjauskaavio:
Verkon ruuhkien hallinta
Ennen ruuhkien hallinnan käyttöönottoa meidän on ymmärrettävä, että vastaanottoikkunan ja lähetysikkunan lisäksi on myös ruuhkaikkuna, jota käytetään pääasiassa ratkaisemaan ongelman, jossa lähettäjä alkaa lähettää tietoja vastaanottoikkunaan. Siksi TCP -lähettäjä ylläpitää ruuhkaikkunaa. Tarvitsemme algoritmia päättääksemme, kuinka paljon tietoja on tarkoituksenmukaista lähettää, koska liian vähän tai liian paljon tietoa ei ole ihanteellinen, joten konsepti ruuhka -ikkunasta.
Edellisessä verkkovirranhallinnassa vältimme lähettäjä, joka täytti vastaanottimen välimuistin datalla, mutta emme tienneet, mitä verkossa tapahtui. Tyypillisesti tietokoneverkot ovat yhteisessä ympäristössä. Seurauksena on, että verkon ruuhkia voi johtua muiden isäntien välisestä viestinnästä.
Kun verkko on ruuhkainen, jos lähetti suurta määrää paketteja, se voi aiheuttaa ongelmia, kuten viive ja pakettien menetys. Tässä vaiheessa TCP lähettää tiedot uudelleen, mutta uudelleenlähetys lisää verkon taakkaa, mikä johtaa suurempiin viivästyksiin ja lisää pakettitappioita. Tämä voi päästä noidankehään ja kasvaa jatkuvasti.
Siten TCP ei voi sivuuttaa verkossa tapahtuvaa. Kun verkko on ruuhkainen, TCP uhraa itsensä vähentämällä lähettämänsä tiedon määrää.
Siksi ehdotetaan ruuhkien hallintaa, jonka tavoitteena on välttää koko verkon täyttäminen lähettäjän tiedoilla. Lähettäjän lähettämän tietomäärän säätelemiseksi TCP määrittelee konseptin, jota kutsutaan ruuhkaikkunaan. Ruuhkien ohjausalgoritmi säätää ruuhkaikkunan kokoa verkon ruuhka -asteen mukaan lähettäjän lähettämän tiedon määrän hallitsemiseksi.
Mikä on ruuhka -ikkuna? Mitä tällä on lähetysikkunan kanssa?
Ruuhka -ikkuna on lähettäjän ylläpitämä tilamuuttuja, joka määrittää lähettäjän lähettämän tiedon määrän. Ruuhka -ikkuna muuttuu dynaamisesti verkon ruuhka -tason mukaan.
Lähettävä ikkuna on sovitettu ikkunan koosta lähettäjän ja vastaanottajan välillä, joka osoittaa vastaanottajan vastaanottaman tietomäärän. Ruuhka -ikkuna ja lähetysikkuna liittyvät; Lähettävä ikkuna on yleensä yhtä suuri kuin ruuhkien ja vastaanottavien ikkunoiden minimi, ts. SWND = min (CWND, RWND).
Ruuhka -ikkuna CWND muuttuu seuraavasti:
Jos verkossa ei ole ruuhkia, ts. Uudelleenlähetyksen aikakatkaisua ei tapahdu, ruuhkaikkuna kasvaa.
Jos verkossa on ruuhkia, ruuhka -ikkuna vähenee.
Lähettäjä määrittää, onko verkko ruuhkainen tarkkailemalla, saako ACK -kuittauspaketti määrätyn ajan kuluessa. Jos lähettäjä ei vastaanota ACK -kuittauspakettia määritetyn ajan kuluessa, katsotaan, että verkko on ruuhkainen.
Ruuhka -ikkunan lisäksi on aika keskustella TCP -ruuhkien ohjausalgoritmista. TCP -ruuhkien hallintaalgoritmi koostuu kolmesta pääosasta:
Hidas alku:Aluksi CWND -ruuhka -ikkuna on suhteellisen pieni, ja lähettäjä lisää ruuhka -ikkunaa eksponentiaalisesti sopeutuakseen nopeasti verkon kapasiteettiin.
Ruuhkien välttäminen:Kun ruuhka -ikkuna ylittää tietyn kynnyksen, lähettäjä lisää ruuhka -ikkunaa lineaarisella tavalla hidastamaan ruuhkaikkunan kasvua ja välttämään verkon ylikuormitusta.
Nopea toipuminen:Jos ruuhkia tapahtuu, lähettäjä puolittaa ruuhka -ikkunan ja siirtyy nopeaan palautustilaan määrittääkseen verkon palautuksen sijainnin vastaanotetun kaksois -ACK: n kautta ja jatkaa sitten ruuhka -ikkunan lisäämistä.
Hitaasti aloitus
Kun TCP -yhteys muodostetaan, ruuhkaikkunan CWND asetetaan alun perin MSS: n vähimmäisarvoon (suurin segmentin koko). Tällä tavoin alkuperäinen lähetysnopeus on MSS/RTT -tavua/sekunti. Todellinen käytettävissä oleva kaistanleveys on yleensä paljon suurempi kuin MSS/RTT, joten TCP haluaa löytää optimaalisen lähetysnopeuden, joka voidaan saavuttaa hitaasti käynnistämällä.
Hitaassa käynnistysprosessissa ruuhkaikkunan CWND-arvo alustetaan 1 MSS: ksi, ja joka kerta kun lähetetty pakettisegmentti tunnustetaan, CWND: n arvoa korotetaan yksi MSS, ts. CWND: n arvosta tulee 2 MSS. Sen jälkeen CWND: n arvo kaksinkertaistuu jokaisesta pakettisegmentin onnistuneesta siirrosta ja niin edelleen. Erityinen kasvuprosessi on esitetty seuraavassa kuvassa.
Lähetysaste ei kuitenkaan aina kasva; Kasvun on päätyttävä joskus. Joten milloin lähetysnopeus nousee? Hidas käynnistys lopettaa tyypillisesti lähetysnopeuden nousun yhdellä monella tavalla:
Ensimmäinen tapa on pakettien menetys hitaan käynnistyksen lähetysprosessin aikana. Kun pakettitappio tapahtuu, TCP asettaa lähettäjän ruuhkaikkunan CWND: n 1: ksi ja käynnistää hitaan käynnistysprosessin uudelleen. Tässä vaiheessa esitellään hitaan käynnistyskynnyksen SSTHresh -käsite, jonka alkuperäinen arvo on puolet CWND: n arvosta, joka tuottaa paketin menetystä. Toisin sanoen, kun ruuhkia havaitaan, SSTHRESH: n arvo on puolet ikkunan arvosta.
Toinen tapa on korreloida suoraan hitaan käynnistyskynnyksen SSTHRESH-arvon kanssa. Koska SSTHRESH: n arvo on puolet ikkunan arvosta ruuhkien havaitsemisen yhteydessä, paketin menetys voi tapahtua jokaisen kaksinkertaistuessa, kun CWND on suurempi kuin SSTHRESH. Siksi on parasta asettaa CWND SSTHRESH: lle, mikä aiheuttaa TCP: n siirtymisen ruuhkien ohjaustilaan ja lopettamaan hidas käynnistys.
Viimeinen tapa, jolla hidas aloitus voi loppua, on, jos kolme redundanttia ACK: ta havaitaan, TCP suorittaa nopean uudelleenlähetyksen ja tulee palautustilaan. (Jos ei ole selvää, miksi ACK -paketteja on kolme, se selitetään erikseen uudelleenlähetysmekanismissa.)
Ruuhkien välttäminen
Kun TCP siirtyy ruuhkien ohjaustilaan, CWND on asetettu puoleen ruuhkien kynnysarvosta. Tämä tarkoittaa, että CWND: n arvoa ei voida kaksinkertaistaa joka kerta, kun pakettisegmentti vastaanotetaan. Sen sijaan otetaan huomioon suhteellisen konservatiivinen lähestymistapa, jossa CWND: n arvoa korotetaan vain yhdellä MSS: llä (maksimaalinen paketti -segmentin pituus) kunkin lähetyksen valmistumisen jälkeen. Esimerkiksi, vaikka 10 pakettisegmenttiä tunnustetaan, CWND: n arvo nousee vain yhdellä MSS: llä. Tämä on lineaarinen kasvumalli ja sillä on myös yläraja kasvussa. Kun pakettitappio tapahtuu, CWND: n arvo vaihdetaan MSS: ksi ja SSTHRESH: n arvo asetetaan puoleen CWND: stä. Tai se pysäyttää myös MSS: n kasvun, kun 3 redundantista ACK -vastetta vastaanotetaan. Jos CWND: n arvon puolittamisen jälkeen on vielä kolme redundanttia ACK: ta, SSTHRESH: n arvo kirjataan puoleen CWND: n arvosta ja nopea palautustila syötetään.
Nopea toipuminen
Nopeassa palautumistilassa ruuhka -ikkunan CWND -arvoa korotetaan yksi MSS jokaiselle vastaanotetulle redundanttille ACK: lle, ts. ACK, joka ei saapu sekvenssiin. Tällä on käytettävä pakettisegmenttejä, jotka on onnistuneesti lähetetty verkossa siirtotehokkuuden parantamiseksi niin paljon kuin mahdollista.
Kun kadonneen paketti -segmentin ACK saapuu, TCP vähentää CWND: n arvoa ja tulee sitten ruuhkien välttämistilaan. Tämän tarkoituksena on hallita ruuhkien ikkunan kokoa ja välttää verkon ruuhkien lisäämistä edelleen.
Jos aikakatkaisu tapahtuu ruuhkien ohjaustilan jälkeen, verkon olosuhteet muuttuvat vakavammaksi ja TCP siirtyy ruuhkien välttämistilasta hitaaseen käynnistystilaan. Tässä tapauksessa ruuhkaikkunan CWND-arvo on asetettu 1 MSS: iin, paketti-segmentin enimmäismäärän ja hitaan käynnistyskynnyksen SSTHRESH-arvon arvoon asetetaan puoleen CWND: stä. Tämän tarkoituksena on lisätä ruhkiaikkunan kokoa uudelleen sen jälkeen, kun verkko on toistunut siirtoprosentin ja verkon ruuhkien asteen tasapainottamiseksi.
Yhteenveto
Luotettavana kuljetusprotokollana TCP toteuttaa luotettavan kuljetuksen sekvenssinumerolla, kuittauksella, uudelleenlähetysohjauksella, yhteydenhallinnalla ja ikkunoiden hallintaan. Niistä virtauksen ohjausmekanismi hallitsee lähettäjän lähettämän tiedon määrää vastaanottimen todellisen vastaanottokapasiteetin mukaisesti, mikä välttää verkon ruuhkien ja suorituskyvyn heikkenemisen ongelmat. Ruuhkien ohjausmekanismi välttää verkon ruuhkien esiintymisen säätämällä lähettäjän lähettämän tiedon määrää. Ruuhka -ikkunan ja lähetysikkunan käsitteet liittyvät toisiinsa, ja lähettäjän tietojen määrää ohjataan säätämällä dynaamisesti ruuhkaikkunan kokoa. Hidas käynnistys, ruuhkien välttäminen ja nopea palautuminen ovat TCP -ruuhkien ohjausalgoritmin kolme pääosaa, jotka säätävät ruuhkaikkunan kokoa eri strategioiden avulla sopeutuaksesi verkon kapasiteettiin ja ruuhka -asteeseen.
Seuraavassa osassa tutkimme yksityiskohtaisesti TCP: n uudelleenlähetysmekanismia. Siirtymämekanismi on tärkeä osa TCP: tä luotettavan siirron saavuttamiseksi. Se varmistaa tietojen luotettavan siirron uudelleensijoittamalla kadonneen, vioittuneen tai viivästyneen datan. Uudelleenlähetysmekanismin toteutusperiaate ja strategia otetaan käyttöön ja analysoidaan yksityiskohtaisesti seuraavassa osassa. Pysy kuulolla!
Viestin aika: helmikuu-24-2025
