Prieš pradėdamas šios dienos vaizdo įrašų pamoką, noriu padėkoti visiems, prisidėjusiems prie mano kurso populiarumo „YouTube“. Kai pradėjau jį maždaug prieš 8 mėnesius, nesitikėjau tokios sėkmės – šiandien mano pamokas peržiūrėjo 312724 11208 žmonės, turiu 7 6 prenumeratorius. Niekada nesvajojau, kad ši kukli pradžia pasieks tokias aukštumas. Tačiau negaiškime laiko ir eikime tiesiai į šiandienos pamoką. Šiandien mes užpildysime spragas, atsiradusias per paskutines 3 vaizdo pamokas. Nors šiandien tik 3 diena, XNUMX diena buvo suskirstyta į XNUMX vaizdo pamokas, todėl šiandien iš tikrųjų žiūrėsite aštuntąją video pamoką.
Šiandien apžvelgsime 3 svarbias temas: DHCP, TCP transportą ir dažniausiai pasitaikančius prievadų numerius. Jau kalbėjome apie IP adresus, o vienas iš svarbiausių IP adresų konfigūravimo faktorių yra DHCP.
DHCP reiškia „Dynamic Host Configuration Protocol“ ir yra protokolas, padedantis dinamiškai konfigūruoti pagrindinių kompiuterių IP adresus. Taigi mes visi matėme šį langą. Spustelėjus parinktį „Automatiškai gauti IP adresą“, kompiuteris ieško DHCP serverio, sukonfigūruoto tame pačiame potinklyje, ir siunčia įvairius IP adreso paketus bei užklausas. DHCP protokolas turi 6 pranešimus, iš kurių 4 yra svarbūs norint priskirti IP adresą.
Pirmasis pranešimas yra DHCP DISCOVERY pranešimas. DHCP aptikimo pranešimas yra panašus į pasisveikinimo pranešimą. Kai prie tinklo prisijungia naujas įrenginys, jis klausia, ar tinkle yra DHCP serveris.
Tai, ką matote skaidrėje, atrodo kaip transliavimo užklausa, kai įrenginys susisiekia su visais tinklo įrenginiais, ieškodamas DHCP serverio. Kaip jau sakiau, tai yra transliacijos užklausa, todėl ją girdi visi tinklo įrenginiai.
Jei tinkle yra DHCP serveris, jis siunčia paketą – DHCP OFFER pasiūlymą. Pasiūlymas reiškia, kad DHCP serveris, atsakydamas į aptikimo užklausą, siunčia klientui konfigūraciją, prašydamas kliento priimti konkretų IP adresą.
DHCP serveris rezervuoja IP adresą, šiuo atveju 192.168.1.2, jo nepateikia, o rezervuoja šį adresą įrenginiui. Tuo pačiu metu pasiūlymo pakete yra savo DHCP serverio IP adresas.
Jei šiame tinkle yra daugiau nei vienas DHCP serveris, kitas DHCP serveris, gavęs kliento transliavimo užklausą, jam taip pat pasiūlytų savo IP adresą, pavyzdžiui, 192.168.1.50. Neįprasta, kad tame pačiame tinkle sukonfigūruoti du skirtingi DHCP serveriai, tačiau kartais taip nutinka. Taigi, kai klientui siunčiamas DHCP pasiūlymas, jis gauna 2 DHCP pasiūlymus ir dabar turi nuspręsti, kurį DHCP pasiūlymą nori priimti.
Tarkime, kad klientas priima pirmąją paraišką. Tai reiškia, kad klientas siunčia DHCP REQUEST užklausą, kurioje pažodžiui sakoma: „Sutinku su IP adresu 192.168.1.2, kurį siūlo DHCP serveris 192.168.1.1“.
Gavęs užklausą, 192.168.1.1 DHCP serveris atsako „gerai, aš pripažįstu“, tai yra, patvirtina užklausą ir siunčia šį DHCP ACK klientui. Tačiau prisimename, kad kitas DHCP serveris klientui rezervavo 1.50 IP adresą. Gavęs kliento transliavimo užklausą, jis sužinos apie gedimą ir grąžins tą IP adresą į telkinį, kad galėtų priskirti jį kitam klientui, jei gautų kitą užklausą.
Tai yra 4 svarbūs pranešimai, kuriais DHCP keičiasi priskirdamas IP adresus. Tada DHCP turi dar 2 informacinius pranešimus. Klientas išsiunčia informacinį pranešimą, jei jam reikia daugiau informacijos, nei buvo gauta DHCP OFFER sąlygoje antrajame žingsnyje. Jei serveris nepateikė pakankamai informacijos DHCP pasiūlyme arba klientui reikia daugiau informacijos, nei buvo pasiūlymo pakete, jis prašo papildomos DHCP informacijos. Yra dar vienas pranešimas, kurį klientas siunčia serveriui – tai DHCP RELEASE. Jis informuoja, kad klientas nori išleisti esamą IP adresą.
Tačiau dažniausiai atsitinka taip, kad vartotojas atsijungia nuo tinklo, kol klientas nespėja nusiųsti serveriui DHCP RELEASE. Taip atsitinka, kai išjungiate kompiuterį, ką mes darome. Tokiu atveju tinklo klientas arba kompiuteris tiesiog nespėja informuoti serverio, kad būtų išleistas panaudotas adresas, todėl DHCP RELEASE žingsnis nėra būtinas. Norint gauti IP adresą, reikia atlikti šiuos veiksmus: DHCP atradimas, DHCP pasiūlymas, DHCP užklausa ir DHCP rankos paspaudimas.
Vienoje iš kitų pamokų papasakosiu, kaip sukonfigūruojame DHCP serverį kuriant DNCP telkinį. Apibendrinimas reiškia, kad nurodote serveriui priskirti IP adresus nuo 192.168.1.1 iki 192.168.1.254. Taigi DHCP serveris sukurs telkinį, į jį patalpins 254 IP adresus ir tik iš šio telkinio galės priskirti adresus klientams tinkle. Taigi tai yra kažkas panašaus į administracinį nustatymą, kurį gali atlikti vartotojas.
Dabar pažvelkime į TCP perdavimą. Nežinau, ar esate susipažinęs su paveikslėlyje pavaizduotu „telefonu“, bet kai buvome vaikai, naudodavome šias skardines, sujungtas virvele, kad galėtume kalbėtis.
Deja, šiandieninė karta negali sau leisti tokios „prabangos“. Aš turiu galvoje, kad šiandien vaikai nuo vienerių metų yra prie televizoriaus, žaidžia PSP ir galbūt tai diskutuotina, bet manau, kad mūsų vaikystė buvo geriausia, mes iš tikrųjų eidavome į lauką ir žaidėme, o šiandienos vaikų negalima atitraukti nuo sofos. .
Mano sūnui dar tik metukai ir aš jau matau, kad jis priklausomas nuo iPad, turiu omenyje, kad jis dar labai mažas, bet manau, kad šiandieniniai vaikai jau gimsta mokėdami elgtis su elektroniniais prietaisais. Taigi, aš norėjau pasakyti, kad vaikystėje žaisdami skardinėse darydavome skylutes, o kai jas surišdavome virvele ir kažką sakydavome į vieną skardinę, tada kitame gale žmogus girdėdavo, kas sakoma. jam tiesiog pridedant skardinę prie ausies. Taigi tai labai panašu į tinklo ryšį.
Šiandien net TCP perdavimai turi turėti ryšį, kuris turi būti užmegztas prieš pradedant faktinį duomenų perdavimą. Kaip aptarėme ankstesnėse pamokose, TCP yra į ryšį orientuotas perdavimas, o UDP yra į ryšį orientuotas perdavimas. Galima sakyti, kad UDP yra ta vieta, kur aš metau kamuolį, ir jūs turite pamatyti, ar sugebėsite jį sugauti. Nesvarbu, ar tu pasiruošęs tai padaryti, ar ne – ne mano problema, aš tiesiog jį paliksiu.
TCP labiau panašu į tai, kad kalbatės su vaikinu ir iš anksto įspėjate jį, kad messite kamuolį, taip užmezgate ryšį, o tada metate kamuolį, kad jūsų partneris būtų labiau pasirengęs jį pagauti. Taigi TCP iš tikrųjų sukuria ryšį ir tada pradeda faktinį perdavimą.
Pažiūrėkime, kaip tai sukuria tokį ryšį. Šis protokolas ryšiui sukurti naudoja 3 krypčių rankos paspaudimą. Tai nėra labai techninis terminas, tačiau jis jau seniai naudojamas apibūdinti TCP ryšį. Trijų krypčių rankos paspaudimą inicijuoja siunčiantis įrenginys, o klientas siunčia paketą su SYN vėliava į serverį.
Tarkime, kad mergina priekiniame plane, kurios veidą matome, yra įrenginys A, o mergina fone, kurios veido nesimato, yra įrenginys B. Mergina A siunčia SYN paketą merginai B ir ji sako: „Puiku, kas- tada jis nori su manimi bendrauti. Taigi, turiu atsakyti, kad esu pasiruošęs bendrauti! Kaip tai padaryti? Galima tiesiog atsiųsti kitą SYN paketą ir tada ACK, nurodantį, kad buvo gautas originalus SYN paketas. Tačiau užuot siuntęs ACK atskirai, serveris sudaro bendrą paketą, kuriame yra SYN ir ACK, ir perduoda jį tinklu.
Taigi šiuo metu įrenginys A išsiuntė SYN paketą ir gavo atgal SYN/ACK paketą. Dabar įrenginys A turi išsiųsti įrenginiui B ACK paketą, ty patvirtinti, kad gavo sutikimą iš įrenginio B užmegzti ryšį. Taigi, abu įrenginiai gavo SYN ir ACK paketus, o dabar galime teigti, kad ryšys užmegztas, tai yra, buvo atliktas 3 etapų rankos paspaudimas naudojant TCP protokolą.
Toliau apžvelgsime TCP langų technologiją. Paprasčiau tariant, tai TCP/IP naudojamas metodas, leidžiantis derėtis dėl siuntėjo ir gavėjo galimybių.
Tarkime, sistemoje „Windows“ bandome perkelti didelį failą, tarkime, 2 GB dydžio, iš vieno disko į kitą. Pačioje perkėlimo pradžioje sistema informuos, kad failo perkėlimas užtruks maždaug 1 metus. Tačiau po kelių sekundžių sistema pasitaisys ir pasakys: „O, palauk, manau, tai užtruks apie 6 mėnesius, o ne metus“. Praeis šiek tiek daugiau laiko ir „Windows“ pasakys: „Manau, kad galėčiau perkelti failą per 1 mėnesį“. Po to bus rodomas pranešimas „1 diena“, „6 valandos“, „3 valandos“, „1 valanda“, „20 minučių“, „10 minučių“, „3 minutės“. Tiesą sakant, visas failų perkėlimo procesas užtruks tik 3 minutes. Kaip tai nutiko? Iš pradžių, kai jūsų įrenginys bando susisiekti su kitu įrenginiu, jis išsiunčia vieną paketą ir laukia patvirtinimo. Jei įrenginys ilgai laukia patvirtinimo, jis galvoja: „jei man reikės perduoti 2 GB duomenų tokiu greičiu, tai užtruks apie 2 metus“. Po kurio laiko jūsų įrenginys gauna ACK ir galvoja: „gerai, aš išsiunčiau vieną paketą ir gavau ACK, vadinasi, gavėjas gali gauti 1 paketą. Dabar pabandysiu jam nusiųsti 10 paketų, o ne vieną. Siuntėjas išsiunčia 10 paketų ir po kurio laiko gauna ACK patvirtinimą iš priimančio įrenginio, o tai reiškia, kad gavėjas laukia kito, 11-ojo paketo. Siuntėjas galvoja: „puiku, kadangi gavėjas iš karto tvarkė 10 paketų, dabar bandysiu jam išsiųsti 100, o ne dešimt. Jis išsiunčia 100 paketų, o gavėjas atsako, kad juos gavo ir dabar laukia 101 paketo. Taigi laikui bėgant perduodamų paketų skaičius didėja.
Štai kodėl matote spartų failų kopijavimo laiko sumažėjimą, palyginti su tuo, kas buvo nurodyta iš pradžių – taip yra dėl padidėjusios galimybės perkelti didelius duomenų kiekius. Tačiau ateina laikas, kai tolesnis perdavimo apimties didinimas tampa neįmanomas. Tarkime, kad išsiuntėte 10000 9000 paketų, bet imtuvo įrenginio buferis gali priimti tik 9000 9001 Šiuo atveju gavėjas siunčia ACK su pranešimu: „Gavau 9000 9000 paketų ir dabar esu pasirengęs priimti 9000 3“. Iš to siuntėjas daro išvadą, kad priimančiojo įrenginio buferio talpa yra tik XNUMX, tai reiškia, kad nuo šiol vienu metu išsiųsiu ne daugiau nei XNUMX paketų. Tokiu atveju siuntėjas greitai apskaičiuoja laiką, per kurį jis perduos likusį duomenų kiekį XNUMX paketų dalimis ir duoda XNUMX minutes. Šios trys minutės yra tikrasis perdavimo laikas. TCP Windowing tai daro.
Tai vienas iš tų srauto mažinimo mechanizmų, kai siunčiantis įrenginys galiausiai supranta, koks yra tikrasis tinklo pajėgumas. Jums gali kilti klausimas, kodėl jie negali iš anksto susitarti, kokia yra priimančiojo įrenginio talpa? Faktas yra tas, kad tai techniškai neįmanoma, nes tinkle yra įvairių tipų įrenginių. Tarkime, kad turite iPad ir jo duomenų perdavimo/imtuvo greitis skiriasi nuo iPhone, galbūt turite skirtingų tipų telefonus, o gal turite labai seną kompiuterį. Todėl kiekvienas turi skirtingą tinklo pralaidumą.
Būtent todėl buvo sukurta TCP Windowing technologija, kai duomenų perdavimas prasideda mažu greičiu arba perduodant minimalų paketų skaičių, palaipsniui didinant srauto „langą“. Siunčiate vieną paketą, 5 paketus, 10 paketų, 1000 paketų, 10000 XNUMX paketų ir lėtai atidarote tą langą, kol „atidarymas“ pasiekia didžiausią galimą srauto apimtį, siunčiamą per tam tikrą laikotarpį. Taigi langų sąvoka yra TCP protokolo veikimo dalis.
Toliau apžvelgsime dažniausiai pasitaikančius prievadų numerius. Klasikinė situacija yra tada, kai turite 1 pagrindinį serverį, galbūt duomenų centrą. Tai apima failų serverį, žiniatinklio serverį, pašto serverį ir DHCP serverį. Dabar, jei vienas iš klientų kompiuterių susisieks su duomenų centru, kuris yra paveikslėlio viduryje, jis pradės siųsti failų serverio srautą į kliento įrenginius. Šis srautas rodomas raudonai ir bus perduotas per tam tikrą prievadą konkrečiai programai iš konkretaus serverio.
Kaip serveris žinojo, kur turėtų vykti tam tikras srautas? Jis tai sužino iš paskirties prievado numerio. Jei pažvelgsite į rėmelį, pamatysite, kad kiekviename duomenų perdavime yra nurodytas paskirties prievado numeris ir šaltinio prievado numeris. Matote, kad mėlynas ir raudonas srautas, o mėlynas srautas yra žiniatinklio serverio srautas, abu nukreipiami į tą patį fizinį serverį, kuriame įdiegti skirtingi serveriai. Jei tai duomenų centras, tada jis naudoja virtualius serverius. Taigi, kaip jie žinojo, kad raudonasis srautas turėjo grįžti į tą kairįjį nešiojamąjį kompiuterį su tuo IP adresu? Jie tai žino dėl prievadų numerių. Jei kreipsitės į Vikipedijos straipsnį „TCP ir UDP prievadų sąrašas“, pamatysite, kad jame pateikiami visi standartiniai prievadų numeriai.
Jei slinksite žemyn šiuo puslapiu, pamatysite, koks didelis šis sąrašas. Jame yra maždaug 61 000 skaičių. Prievado numeriai nuo 1 iki 1024 yra žinomi kaip dažniausiai naudojami prievadų numeriai. Pavyzdžiui, prievadas 21/TCP skirtas ftp komandoms siųsti, 22 prievadas – ssh, 23 prievadas – Telnet, tai yra, nešifruotiems pranešimams siųsti. Labai populiarus 80 prievadas perduoda duomenis per HTTP, o 443 prievadas perduoda užšifruotus duomenis per HTTPS, kuris yra panašus į saugią HTTP versiją.
Kai kurie prievadai yra skirti ir TCP, ir UDP, o kai kurie atlieka skirtingas užduotis, priklausomai nuo to, ar ryšys yra TCP, ar UDP. Taigi oficialiai TCP prievadas 80 naudojamas HTTP, o neoficialiai UDP 80 prievadas naudojamas HTTP, tačiau pagal kitą HTTP protokolą - QUIC.
Todėl TCP prievadų numeriai ne visada skirti tam pačiam veiksmui kaip UDP. Šio sąrašo nereikia mokytis mintinai, jo neįmanoma atsiminti, tačiau reikia žinoti kai kuriuos populiarius ir dažniausiai pasitaikančius prievadų numerius. Kaip jau sakiau, kai kurie iš šių prievadų turi oficialią paskirtį, kuri aprašyta standartuose, o dalis – neoficialią, kaip ir Chromium atveju.
Taigi, šioje lentelėje išvardyti visi įprasti prievadų numeriai ir šie numeriai naudojami srautui siųsti ir gauti naudojant konkrečias programas.
Dabar pažiūrėkime, kaip duomenys juda tinkle, remdamiesi mažai žinoma informacija. Tarkime, kad kompiuteris 10.1.1.10 nori susisiekti su šiuo kompiuteriu arba šiuo serveriu, kurio adresas yra 30.1.1.10. Po kiekvieno įrenginio IP adresu yra jo MAC adresas. Pateikiu MAC adreso, kuriame yra tik paskutiniai 4 simboliai, pavyzdį, tačiau praktiškai tai yra 48 bitų šešioliktainis skaičius su 12 simbolių. Kadangi kiekvienas iš šių skaičių susideda iš 4 bitų, 12 šešioliktainių skaitmenų reiškia 48 bitų skaičių.
Kaip žinome, jei šis įrenginys nori susisiekti su šiuo serveriu, pirmiausia reikia atlikti pirmąjį trijų krypčių rankos paspaudimo žingsnį, tai yra, išsiųsti SYN paketą. Kai pateikiama ši užklausa, kompiuteris 3 nurodys šaltinio prievado numerį, kurį Windows sukuria dinamiškai. „Windows“ atsitiktinai pasirenka prievado numerį nuo 10.1.1.10 iki 1 65,000. Tačiau kadangi pradiniai skaičiai diapazone nuo 1 iki 1024 yra plačiai žinomi, tokiu atveju sistema atsižvelgs į didesnius nei 25000 25113 skaičius ir sukurs atsitiktinį šaltinio prievadą, pavyzdžiui, numerį XNUMX.
Tada sistema prie paketo pridės paskirties prievadą, šiuo atveju tai yra 21 prievadas, nes programa, kuri bando prisijungti prie šio FTP serverio, žino, kad ji turėtų siųsti FTP srautą.
Tada mūsų kompiuteris sako: „Gerai, mano IP adresas yra 10.1.1.10, ir man reikia susisiekti su IP adresu 30.1.1.10“. Abu šie adresai taip pat yra įtraukti į paketą, kad būtų sudaryta SYN užklausa, ir šis paketas nepasikeis iki ryšio pabaigos.
Noriu, kad iš šio vaizdo įrašo suprastumėte, kaip duomenys juda tinkle. Kai užklausą siunčiantis kompiuteris mato šaltinio IP adresą ir paskirties IP adresą, jis supranta, kad paskirties adresas nėra tame vietiniame tinkle. Pamiršau pasakyti, kad tai visi /24 IP adresai. Taigi, jei pažvelgsite į /24 IP adresus, suprasite, kad kompiuteriai 10.1.1.10 ir 30.1.1.10 nėra tame pačiame tinkle. Taigi užklausą siunčiantis kompiuteris supranta, kad norėdamas išeiti iš šio tinklo turi susisiekti su 10.1.1.1 šliuzu, kuris sukonfigūruotas vienoje iš maršrutizatoriaus sąsajų. Jis žino, kad turėtų pereiti prie 10.1.1.1, ir žino savo MAC adresą 1111, bet nežino šliuzo MAC adreso 10.1.1.1. Ką jis daro? Ji siunčia transliuojamą ARP užklausą, kurią gaus visi tinklo įrenginiai, tačiau į jį atsakys tik maršrutizatorius, kurio IP adresas 10.1.1.1.
Maršrutizatorius atsakys savo AAAA MAC adresu, o šaltinio ir paskirties MAC adresai taip pat bus įtraukti į šį rėmelį. Kai kadras bus paruoštas, prieš išeinant iš tinklo bus atlikta CRC duomenų vientisumo patikra, kuri yra algoritmas ieškant kontrolinės sumos, leidžiančios aptikti klaidas.
Ciklinio pertekliaus CRC reiškia, kad visas šis kadras, nuo SYN iki paskutinio MAC adreso, yra vykdomas naudojant maišos algoritmą, tarkime, MD5, todėl gaunama maišos reikšmė. Maišos reikšmė arba MD5 kontrolinė suma įdedama į kadro pradžią.
Pažymėjau jį FCS / CRC, nes FCS yra kadrų tikrinimo seka, keturių baitų CRC reikšmė. Kai kurie žmonės naudoja pavadinimą FCS, o kiti naudoja pavadinimą CRC, todėl aš tiesiog įtraukiau abu pavadinimus. Bet iš esmės tai tik maišos vertė. Būtina įsitikinti, kad visuose tinklu gautuose duomenyse nėra klaidų. Todėl, kai šis kadras pasiekia maršrutizatorių, pirmiausia maršrutizatorius apskaičiuos kontrolinę sumą ir palygins ją su FCS arba CRC reikšme, kuri yra gautame kadre. Taip jis gali patikrinti, ar per tinklą gautuose duomenyse nėra klaidų, po to jis pašalins kontrolinę sumą iš kadro.
Tada maršrutizatorius pažiūrės į MAC adresą ir pasakys: „Gerai, MAC adresas AAAA reiškia, kad kadras skirtas man“, ir ištrins kadro dalį, kurioje yra MAC adresai.
Žvelgdamas į paskirties IP adresą 30.1.1.10, jis supras, kad šis paketas nėra skirtas jam ir turi eiti toliau per maršrutizatorių.
Dabar maršrutizatorius "galvoja", kad jam reikia pamatyti, kur yra tinklas su adresu 30.1.1.10. Mes dar neaptarėme visos maršruto parinkimo koncepcijos, bet žinome, kad maršrutizatoriai turi maršruto parinkimo lentelę. Šioje lentelėje yra tinklo, kurio adresas yra 30.1.1.0, įrašas. Kaip prisimenate, tai nėra pagrindinio kompiuterio IP adresas, o tinklo identifikatorius. Maršrutizatorius „galvos“, kad jis gali pasiekti adresą 30.1.1.0/24, eidamas per maršrutizatorių 20.1.1.2.
Galite paklausti, iš kur jis tai žino? Tiesiog atminkite, kad ji tai žinos iš maršruto parinkimo protokolų arba iš jūsų nustatymų, jei kaip administratorius sukonfigūravote statinį maršrutą. Tačiau bet kuriuo atveju šio maršrutizatoriaus maršruto parinkimo lentelėje yra teisingas įrašas, todėl jis žino, kad turėtų siųsti šį paketą į 20.1.1.2. Darant prielaidą, kad maršrutizatorius jau žino paskirties MAC adresą, mes tiesiog tęsime paketo persiuntimą. Jei jis nežino šio adreso, jis vėl paleis ARP, gaus maršrutizatoriaus MAC adresą 20.1.1.2 ir kadro siuntimo procesas bus tęsiamas iš naujo.
Taigi darome prielaidą, kad ji jau žino MAC adresą, tada turėsime BBB šaltinio MAC adresą ir CCC paskirties MAC adresą. Maršrutizatorius vėl apskaičiuoja FCS/CRC ir įdeda jį kadro pradžioje.
Tada jis siunčia šį kadrą per tinklą, kadras pasiekia maršrutizatorių 20.1.12, patikrina kontrolinę sumą, įsitikina, kad duomenys nėra sugadinti, ir ištrina FCS/CRC. Tada „sutrumpina“ MAC adresus, žiūri į paskirties vietą ir mato, kad tai 30.1.1.10. Jis žino, kad šis adresas yra prijungtas prie jo sąsajos. Kartojamas tas pats kadrų formavimo procesas, maršrutizatorius prideda šaltinio ir paskirties MAC adresų reikšmes, atlieka maišą, prideda maišą prie kadro ir siunčia jį per tinklą.
Mūsų serveris, pagaliau gavęs jam skirtą SYN užklausą, patikrina maišos kontrolinę sumą, o jei pakete nėra klaidų, maišą ištrina. Tada jis pašalina MAC adresus, žiūri į IP adresą ir supranta, kad šis paketas skirtas jam.
Po to jis sutrumpina IP adresus, susijusius su trečiuoju OSI modelio sluoksniu, ir peržiūri prievadų numerius.
Jis mato 21 prievadą, o tai reiškia FTP srautą, mato SYN ir todėl supranta, kad kažkas bando su juo susisiekti.
Dabar, remiantis tuo, ką sužinojome apie rankos paspaudimą, serveris 30.1.1.10 sukurs SYN/ACK paketą ir išsiųs jį atgal į kompiuterį 10.1.1.10. Gavęs šį paketą, įrenginys 10.1.1.10 sukurs ACK, perduos jį per tinklą taip pat, kaip ir SYN paketą, o serveriui gavus ACK, bus užmegztas ryšys.
Vienas dalykas, kurį turėtumėte žinoti, yra tai, kad visa tai įvyksta greičiau nei per sekundę. Tai labai labai greitas procesas, kurį bandžiau sulėtinti, kad tau viskas būtų aišku.
Tikiuosi, kad tai, ko išmokote šioje mokymo programoje, jums bus naudinga. Jei turite klausimų, rašykite man adresu [apsaugotas el. paštu] arba palikite klausimus po šiuo vaizdo įrašu.
Pradedant nuo kitos pamokos, iš YouTube išrinksiu 3 įdomiausius klausimus, kuriuos peržiūrėsiu kiekvieno video pabaigoje. Nuo šiol turėsiu skyrių „Dažniausi klausimai“, todėl paskelbsiu klausimą kartu su jūsų vardu ir atsakysiu į jį tiesiogiai. Manau, kad tai bus naudinga.
Dėkojame, kad likote su mumis. Ar jums patinka mūsų straipsniai? Norite pamatyti įdomesnio turinio? Palaikykite mus pateikdami užsakymą ar rekomenduodami draugams, 30% nuolaida Habr vartotojams unikaliam pradinio lygio serverių analogui, kurį mes sugalvojome jums: (galima su RAID1 ir RAID10, iki 24 branduolių ir iki 40 GB DDR4).
VPS (KVM) E5-2650 v4 (6 branduoliai) 10 GB DDR4 240 GB SSD 1 Gbps nemokamai iki vasaros mokėdami už šešių mėnesių laikotarpį, galite užsisakyti .
Dell R730xd 2 kartus pigiau? Tik čia Olandijoje! „Dell R420“ – 2 x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB – nuo 99 USD! Skaityti apie
Šaltinis: www.habr.com