Ennen kuin aloitamme tämän päivän video-opetusohjelman, haluan kiittää kaikkia, jotka vaikuttivat kurssini suosioon YouTubessa. Kun aloitin sen noin 8 kuukautta sitten, en odottanut tällaista menestystä - tänään oppituntejani on katsonut 312724 11208 ihmistä, minulla on 7 6 tilaajaa. En koskaan uneksinut, että tämä nöyrä alku saavuttaisi niin korkeat. Mutta älkäämme hukkaako aikaa vaan siirtykäämme suoraan tämän päivän oppitunnille. Tänään täytämme viimeisten 3 videotunnin aikana ilmenneitä aukkoja. Vaikka tänään on vasta 3. päivä, päivä XNUMX jaettiin kolmeen videotuntiin, joten tänään katsot itse asiassa kahdeksannen videotunnin.
Tänään käsittelemme kolmea tärkeää aihetta: DHCP, TCP-kuljetus ja yleisimmät porttinumerot. Olemme jo puhuneet IP-osoitteista, ja yksi tärkeimmistä tekijöistä IP-osoitteiden määrittämisessä on DHCP.
DHCP on lyhenne sanoista Dynamic Host Configuration Protocol, ja se on protokolla, joka auttaa dynaamisesti määrittämään isäntien IP-osoitteita. Joten olemme kaikki nähneet tämän ikkunan. Kun napsautat "Hae IP-osoite automaattisesti" -vaihtoehtoa, tietokone etsii DHCP-palvelinta, joka on määritetty samaan aliverkkoon ja lähettää useita paketteja ja IP-osoitepyyntöjä. DHCP-protokollassa on 6 viestiä, joista 4 on kriittistä IP-osoitteen määrittämisessä.
Ensimmäinen viesti on DHCP DISCOVERY -viesti. DHCP-etsintäviesti on samanlainen kuin tervehdysviesti. Kun uusi laite liittyy verkkoon, se kysyy, onko verkossa DHCP-palvelinta.
Diassa näkemäsi näyttää lähetyspyynnöltä, jossa laite ottaa yhteyttä kaikkiin verkon laitteisiin DHCP-palvelinta etsiessään. Kuten sanoin, tämä on lähetyspyyntö, joten kaikki verkon laitteet voivat kuulla sen.
Jos verkossa on DHCP-palvelin, se lähettää paketin - DHCP TARJOUS -tarjouksen. Ehdotus tarkoittaa, että DHCP-palvelin lähettää etsintäpyyntöön vastauksena asiakkaalle kokoonpanon ja pyytää asiakasta hyväksymään tietyn IP-osoitteen.
DHCP-palvelin varaa IP-osoitteen, tässä tapauksessa 192.168.1.2, ei anna sitä, vaan varaa tämän osoitteen laitteelle. Samalla tarjouspaketti sisältää oman DHCP-palvelimen IP-osoitteen.
Jos tässä verkossa on useampi kuin yksi DHCP-palvelin, toinen DHCP-palvelin, vastaanottaessaan asiakkaan yleislähetyspyynnön, tarjoaisi sille myös IP-osoitteensa, esimerkiksi 192.168.1.50. Ei ole yleistä, että samaan verkkoon on määritetty kaksi erilaista DHCP-palvelinta, mutta joskus niin tapahtuu. Joten kun DHCP-tarjous lähetetään asiakkaalle, se vastaanottaa 2 DHCP-tarjousta ja sen on nyt päätettävä, minkä DHCP-tarjouksen se haluaa hyväksyä.
Oletetaan, että asiakas hyväksyy ensimmäisen hakemuksen. Tämä tarkoittaa, että asiakas lähettää DHCP REQUEST -pyynnön, jossa sanotaan kirjaimellisesti "Hyväksyn DHCP-palvelimen 192.168.1.2 tarjoaman IP-osoitteen 192.168.1.1."
Vastaanotettuaan pyynnön 192.168.1.1 DHCP-palvelin vastaa "okei, myönnän sen", eli se kuittaa pyynnön ja lähettää tämän DHCP ACK:n asiakkaalle. Mutta muistamme, että toinen DHCP-palvelin on varannut asiakkaalle IP-osoitteen 1.50. Kun se vastaanottaa asiakkaan lähetyspyynnön, se tietää epäonnistumisesta ja palauttaa IP-osoitteen pooliin, jotta se voi määrittää sen toiselle asiakkaalle, jos se vastaanottaa uuden pyynnön.
Nämä ovat 4 kriittistä viestiä, jotka DHCP vaihtaa IP-osoitteita määrittäessään. Seuraavaksi DHCP:llä on 2 lisätietosanomaa. Asiakas lähettää informaatiosanoman, jos se vaatii enemmän tietoa kuin se vastaanotti DHCP OFFER -lauseessa toisessa vaiheessa. Jos palvelin ei antanut tarpeeksi tietoa DHCP-tarjouksessa tai jos asiakas tarvitsee enemmän tietoa kuin mitä tarjouspaketti sisälsi, se pyytää DHCP-lisätietoja. On vielä yksi viesti, jonka asiakas lähettää palvelimelle - tämä on DHCP RELEASE. Se ilmoittaa, että asiakas haluaa vapauttaa nykyisen IP-osoitteensa.
Useimmiten kuitenkin tapahtuu, että käyttäjä katkaisee yhteyden verkkoon ennen kuin asiakas ehtii lähettää DHCP RELEASE -ilmoituksen palvelimelle. Tämä tapahtuu, kun sammutat tietokoneen, minkä me teemme. Tässä tapauksessa verkkoasiakkaalla tai tietokoneella ei yksinkertaisesti ole aikaa ilmoittaa palvelimelle, että se vapauttaa käytetyn osoitteen, joten DHCP RELEASE ei ole pakollinen vaihe. IP-osoitteen hankkimiseen vaadittavat vaiheet ovat: DHCP-etsintä, DHCP-tarjous, DHCP-pyyntö ja DHCP-kättely.
Yhdessä seuraavista oppituneista kerron sinulle, kuinka määritämme DHCP-palvelimen luotaessa DNCP-poolia. Poolituksella tarkoitamme, että käsket palvelinta määrittämään IP-osoitteet välillä 192.168.1.1 - 192.168.1.254. Näin ollen DHCP-palvelin luo poolin, sijoittaa siihen 254 IP-osoitetta ja voi määrittää osoitteita verkossa oleville asiakkaille vain tästä poolista. Tämä on siis jotain hallinnollista asetusta, jonka käyttäjä voi tehdä.
Katsotaan nyt TCP-siirtoa. En tiedä onko kuvan "puhelin" sinulle tuttu, mutta kun olimme lapsia, käytimme näitä narulla yhdistettyjä peltitölkkejä juttelemaan keskenään.
Valitettavasti nykypäivän sukupolvella ei ole varaa sellaiseen "ylellisyyteen". Tarkoitan, että nykyään lapset ovat television edessä XNUMX-vuotiaasta lähtien, he pelaavat PSP:tä ja ehkä tämä on kiistanalaista, mutta mielestäni meillä oli paras lapsuus, menimme ulkona leikkimään ja nykypäivän lapsia ei voi vetää pois sohvalta. .
Poikani on vasta vuoden ikäinen ja näen jo, että hän on riippuvainen iPadista, tarkoitan, että hän on vielä hyvin nuori, mutta luulen, että nykypäivän lapset ovat jo syntyneet osaavana käsitellä elektronisia laitteita. Halusin siis sanoa, että lapsena leikkiessämme teimme reikiä peltipurkkeihin, ja kun sidoimme ne narulla ja sanoimme jotain yhteen tölkkiin, niin toisessa päässä ihminen kuuli mitä sanottiin. hänelle yksinkertaisesti laittamalla tölkin hänen korvaansa. Joten se on hyvin samanlainen kuin verkkoyhteys.
Nykyään jopa TCP-siirroissa täytyy olla yhteys, joka on muodostettava ennen varsinaisen tiedonsiirron alkamista. Kuten aiemmilla oppitunneilla keskustelimme, TCP on yhteyssuuntautunut siirto, kun taas UDP on yhteyssuuntautunut siirto. Voisi sanoa, että UDP on paikka, jossa heitän pallon, ja sinun on katsottava, saatko sen kiinni. Ei ole minun ongelmani, oletko valmis tekemään sen tai et, aion vain jättää hänet.
TCP on enemmän kuin puhuisit kaverille ja varoitat häntä etukäteen, että aiot heittää pallon, joten muodostat siteen ja sitten heität pallon, jotta kumppanisi on todennäköisemmin valmis nappaamaan sen. Joten TCP itse asiassa rakentaa yhteyden ja alkaa sitten tehdä varsinaista lähetystä.
Katsotaanpa, kuinka se luo tällaisen yhteyden. Tämä protokolla käyttää kolmisuuntaista kättelyä yhteyden luomiseen. Tämä ei ole kovin tekninen termi, mutta sitä on pitkään käytetty kuvaamaan TCP-yhteyttä. Lähettävä laite aloittaa kolmisuuntaisen kättelyn, jolloin asiakas lähettää SYN-lipulla varustetun paketin palvelimelle.
Oletetaan, että etualalla oleva tyttö, jonka kasvot näemme, on laite A ja taustalla oleva tyttö, jonka kasvot eivät näy, on laite B. Tyttö A lähettää SYN-paketin tytölle B, ja hän sanoo: "Hienoa, kuka hän sitten haluaa kommunikoida kanssani. Joten minun on vastattava, että olen valmis kommunikoimaan!” Kuinka tehdä se? Voidaan yksinkertaisesti lähettää takaisin toinen SYN-paketti ja sitten ACK, joka osoittaa alkuperäisen SYN-paketin vastaanottamisen. Mutta sen sijaan, että lähettäisit ACK:t erikseen, palvelin muodostaa yhteisen paketin, joka sisältää SYN:n ja ACK:n, ja lähettää sen verkon yli.
Joten tässä vaiheessa laite A on lähettänyt SYN-paketin ja vastaanottanut takaisin SYN/ACK-paketin. Nyt laitteen A on lähetettävä laitteelle B ACK-paketti, eli vahvistettava, että se on vastaanottanut laitteelta B suostumuksen yhteyden muodostamiseen. Näin ollen molemmat laitteet vastaanottivat SYN- ja ACK-paketit, ja nyt voidaan sanoa, että yhteys on muodostettu, eli 3-vaiheinen kättely on suoritettu TCP-protokollalla.
Seuraavaksi tarkastellaan TCP-ikkunatekniikkaa. Yksinkertaisesti sanottuna se on menetelmä, jota käytetään TCP/IP:ssä neuvottelemaan lähettäjän ja vastaanottajan kyvyistä.
Oletetaan, että Windowsissa yritämme siirtää suuren, esimerkiksi 2 Gt:n tiedoston yhdeltä asemalta toiselle. Heti siirron alussa järjestelmä ilmoittaa meille, että tiedostojen siirto kestää noin 1 vuoden. Mutta muutaman sekunnin kuluttua järjestelmä korjaa itsensä ja sanoo: "Oh, odota hetki, mielestäni kestää noin 6 kuukautta, ei vuotta." Hieman enemmän aikaa kuluu ja Windows sanoo: "Luulen, että pystyn siirtämään tiedoston 1 kuukauden kuluttua." Tämän jälkeen tulee viesti "1 päivä", "6 tuntia", "3 tuntia", "1 tunti", "20 minuuttia", "10 minuuttia", "3 minuuttia". Itse asiassa koko tiedostonsiirtoprosessi kestää vain 3 minuuttia. Kuinka tämä tapahtui? Aluksi, kun laitteesi yrittää kommunikoida toisen laitteen kanssa, se lähettää yhden paketin ja odottaa vahvistusta. Jos laite odottaa pitkään vahvistusta, se ajattelee: "Jos minun on siirrettävä 2 Gt dataa tällä nopeudella, se kestää noin 2 vuotta." Jonkin ajan kuluttua laitteesi vastaanottaa ACK-ilmoituksen ja ajattelee: "Okei, lähetin yhden paketin ja sain ACK:n, joten vastaanottaja voi vastaanottaa yhden paketin. Nyt yritän lähettää hänelle 1 pakettia yhden sijaan." Lähettäjä lähettää 10 pakettia ja saa jonkin ajan kuluttua vastaanottavalta laitteelta ACK-vahvistuksen, mikä tarkoittaa, että vastaanottaja odottaa seuraavaa, 10. pakettia. Lähettäjä ajattelee: "Hienoa, koska vastaanottaja käsitteli 11 pakettia kerralla, yritän nyt lähettää hänelle 10 pakettia kymmenen sijaan." Hän lähettää 100 pakettia, ja vastaanottaja vastaa vastaanottaneensa ne ja odottaa nyt 100 pakettia. Siten ajan myötä lähetettyjen pakettien määrä kasvaa.
Tästä syystä näet tiedoston kopiointiajan nopean pienenevän alun perin ilmoitettuun verrattuna – tämä johtuu lisääntyneestä kyvystä siirtää suuria tietomääriä. Tulee kuitenkin hetki, jolloin lähetysmäärän lisääminen on mahdotonta. Oletetaan, että lähetit 10000 9000 pakettia, mutta vastaanottimen laitepuskuri voi hyväksyä vain 9000 9001. Tässä tapauksessa vastaanottaja lähettää ACK:n, jossa on viesti: "Olen vastaanottanut 9000 9000 pakettia ja olen nyt valmis vastaanottamaan 9000 3." Tästä lähettäjä päättelee, että vastaanottavan laitteen puskurin kapasiteetti on vain XNUMX, mikä tarkoittaa, että lähetän jatkossa enintään XNUMX pakettia kerrallaan. Tässä tapauksessa lähettäjä laskee nopeasti ajan, joka hänellä kuluu jäljellä olevan datamäärän siirtämiseen XNUMX paketin osissa, ja antaa XNUMX minuuttia. Nämä kolme minuuttia ovat todellinen lähetysaika. Sitä TCP Windowing tekee.
Tämä on yksi niistä liikenteen kuristusmekanismeista, joissa lähettävä laite lopulta ymmärtää, mikä verkon todellinen kapasiteetti on. Saatat ihmetellä, miksi he eivät voi sopia etukäteen vastaanottavan laitteen kapasiteetista? Tosiasia on, että tämä on teknisesti mahdotonta, koska verkossa on erilaisia laitteita. Oletetaan, että sinulla on iPad ja siinä on eri tiedonsiirto-/vastaanotinnopeus kuin iPhonessa, sinulla voi olla erityyppisiä puhelimia tai ehkä sinulla on hyvin vanha tietokone. Siksi kaikilla on erilainen verkon kaistanleveys.
Siksi kehitettiin TCP Windowing -tekniikkaa, kun tiedonsiirto alkaa alhaisella nopeudella tai vähimmäismäärän pakettien siirrolla, jolloin liikenteen "ikkuna" kasvaa vähitellen. Lähetät yhden paketin, 5 pakettia, 10 pakettia, 1000 pakettia, 10000 XNUMX pakettia ja avaat sitä ikkunaa hitaasti yhä enemmän, kunnes "avautuminen" saavuttaa suurimman mahdollisen liikenteen määrän tietyllä ajanjaksolla. Siten ikkunoinnin käsite on osa TCP-protokollan toimintaa.
Seuraavaksi tarkastellaan yleisimpiä porttinumeroita. Klassinen tilanne on, kun sinulla on yksi pääpalvelin, ehkä datakeskus. Se sisältää tiedostopalvelimen, web-palvelimen, sähköpostipalvelimen ja DHCP-palvelimen. Jos nyt yksi asiakastietokoneista ottaa yhteyttä kuvan keskellä sijaitsevaan datakeskukseen, se alkaa lähettää tiedostopalvelinliikennettä asiakaslaitteille. Tämä liikenne näkyy punaisella ja se lähetetään tietyssä portissa tietylle sovellukselle tietystä palvelimesta.
Mistä palvelin tiesi, minne tietyn liikenteen pitäisi mennä? Hän oppii tämän kohdeportin numerosta. Jos katsot kehystä, näet, että jokaisessa tiedonsiirrossa on maininta kohdeportin numerosta ja lähdeportin numerosta. Voit nähdä, että sininen ja punainen liikenne ja sininen liikenne on verkkopalvelinliikennettä, molemmat menevät samalle fyysiselle palvelimelle, johon on asennettu eri palvelimia. Jos tämä on datakeskus, se käyttää virtuaalisia palvelimia. Joten mistä he tiesivät, että punaisen liikenteen piti palata vasemmalle kannettavalle tietokoneelle, jolla oli IP-osoite? He tietävät tämän porttinumeroiden ansiosta. Jos viittaat Wikipedian artikkeliin "TCP- ja UDP-porttien luettelo", näet, että siinä luetellaan kaikki vakioporttinumerot.
Jos vierität tätä sivua alaspäin, näet kuinka suuri tämä luettelo on. Se sisältää noin 61 000 numeroa. Porttinumerot 1–1024 tunnetaan yleisimpinä porttinumeroina. Esimerkiksi portti 21/TCP on tarkoitettu ftp-komentojen lähettämiseen, portti 22 ssh:lle, portti 23 Telnetille, eli salaamattomien viestien lähettämiseen. Erittäin suosittu portti 80 kuljettaa dataa HTTP:n kautta, kun taas portti 443 kuljettaa salattua tietoa HTTPS:n kautta, joka on samanlainen kuin HTTP:n suojattu versio.
Jotkut portit on omistettu sekä TCP:lle että UDP:lle, ja jotkut suorittavat erilaisia tehtäviä riippuen siitä, onko yhteys TCP vai UDP. Joten virallisesti TCP-porttia 80 käytetään HTTP:lle ja epävirallisesti UDP-porttia 80 käytetään HTTP:lle, mutta eri HTTP-protokollan - QUIC - alla.
Siksi TCP:n porttinumeroiden ei ole aina tarkoitus tehdä samaa kuin UDP:ssä. Sinun ei tarvitse opetella tätä luetteloa ulkoa, se on mahdotonta muistaa, mutta sinun on tiedettävä joitain suosittuja ja yleisimpiä porttinumeroita. Kuten sanoin, joillakin näistä porteista on virallinen tarkoitus, joka on kuvattu standardeissa, ja joillakin on epävirallinen tarkoitus, kuten Chromiumin tapauksessa.
Joten tässä taulukossa luetellaan kaikki yleiset porttinumerot, ja näitä numeroita käytetään liikenteen lähettämiseen ja vastaanottamiseen tiettyjä sovelluksia käytettäessä.
Katsotaan nyt, kuinka tiedot liikkuvat verkossa sen vähän, mitä tiedämme. Oletetaan, että tietokone 10.1.1.10 haluaa ottaa yhteyttä tähän tietokoneeseen tai tähän palvelimeen, jonka osoite on 30.1.1.10. Jokaisen laitteen IP-osoitteen alla on sen MAC-osoite. Annan esimerkin MAC-osoitteesta, jossa on vain 4 viimeistä merkkiä, mutta käytännössä se on 48-bittinen heksadesimaaliluku, jossa on 12 merkkiä. Koska jokainen näistä luvuista koostuu 4 bitistä, 12 heksadesimaalinumeroa edustavat 48-bittistä lukua.
Kuten tiedämme, jos tämä laite haluaa ottaa yhteyttä tähän palvelimeen, on ensin suoritettava 3-suuntaisen kättelyn ensimmäinen vaihe, eli lähetettävä SYN-paketti. Kun tämä pyyntö tehdään, tietokone 10.1.1.10 määrittää lähdeportin numeron, jonka Windows luo dynaamisesti. Windows valitsee satunnaisesti portin numeron väliltä 1 - 65,000 1. Mutta koska aloitusluvut välillä 1024-25000 tunnetaan laajalti, järjestelmä ottaa tässä tapauksessa huomioon luvut, jotka ovat suurempia kuin 25113, ja luo satunnaisen lähdeportin, esimerkiksi numeron XNUMX.
Seuraavaksi järjestelmä lisää paketille kohdeportin, tässä tapauksessa portin 21, koska tähän FTP-palvelimeen yhteyttä yrittävä sovellus tietää, että sen pitäisi lähettää FTP-liikennettä.
Seuraavaksi tietokoneemme sanoo: "Okei, IP-osoitteeni on 10.1.1.10, ja minun on otettava yhteyttä IP-osoitteeseen 30.1.1.10." Molemmat osoitteet sisältyvät myös pakettiin muodostamaan SYN-pyynnön, eikä tämä paketti muutu ennen yhteyden päättymistä.
Haluan sinun ymmärtävän tästä videosta, kuinka data liikkuu verkossa. Kun pyynnön lähettävä tietokoneemme näkee lähde-IP-osoitteen ja kohde-IP-osoitteen, se ymmärtää, että kohdeosoite ei ole kyseisessä paikallisessa verkossa. Unohdin sanoa, että nämä ovat kaikki /24 IP-osoitteita. Joten jos katsot /24 IP-osoitteita, huomaat, että tietokoneet 10.1.1.10 ja 30.1.1.10 eivät ole samassa verkossa. Näin ollen pyynnön lähettävä tietokone ymmärtää, että poistuakseen tästä verkosta sen on otettava yhteyttä 10.1.1.1-yhdyskäytävään, joka on määritetty johonkin reitittimen liitännöistä. Se tietää, että sen pitäisi mennä 10.1.1.1:een ja tietää MAC-osoitteensa 1111, mutta ei tiedä yhdyskäytävän 10.1.1.1 MAC-osoitetta. Mitä hän tekee? Se lähettää yleislähetyksen ARP-pyynnön, jonka kaikki verkon laitteet vastaanottavat, mutta vain reititin, jonka IP-osoite on 10.1.1.1, vastaa siihen.
Reititin vastaa AAAA MAC-osoitteellaan, ja sekä lähde- että kohde-MAC-osoitteet sijoitetaan myös tähän kehykseen. Kun kehys on valmis, CRC-tietojen eheystarkistus, joka on algoritmi tarkistussumman löytämiseksi virheiden havaitsemiseksi, suoritetaan ennen poistumista verkosta.
Cyclic Redundancy CRC tarkoittaa, että tämä koko kehys SYN:stä viimeiseen MAC-osoitteeseen ajetaan hajautusalgoritmin, esimerkiksi MD5:n, läpi, mikä johtaa hajautusarvoon. Hajautusarvo eli MD5-tarkistussumma sijoitetaan sitten kehyksen alkuun.
Nimesin sen FCS/CRC:ksi, koska FCS on Frame Check Sequence, neljän tavun CRC-arvo. Jotkut ihmiset käyttävät nimitystä FCS ja jotkut käyttävät nimitystä CRC, joten sisällytin vain molemmat nimitykset. Mutta periaatteessa se on vain hash-arvo. Se on tarpeen varmistaa, että kaikki verkon kautta vastaanotettavat tiedot eivät sisällä virheitä. Siksi, kun tämä kehys saavuttaa reitittimen, reititin laskee ensimmäisenä itse tarkistussumman ja vertaa sitä FCS- tai CRC-arvoon, jonka vastaanotettu kehys sisältää. Näin hän voi tarkistaa, ettei verkon kautta vastaanotettu data sisällä virheitä, minkä jälkeen hän poistaa tarkistussumman kehyksestä.
Seuraavaksi reititin tarkastelee MAC-osoitetta ja sanoo: "Ok, MAC-osoite AAAA tarkoittaa, että kehys on osoitettu minulle" ja poistaa MAC-osoitteet sisältävän kehyksen osan.
Tarkasteltaessa kohde-IP-osoitetta 30.1.1.10, hän ymmärtää, että tätä pakettia ei ole osoitettu hänelle ja sen on mentävä pidemmälle reitittimen kautta.
Nyt reititin "ajattelee", että sen täytyy nähdä missä verkko osoitteella 30.1.1.10 sijaitsee. Emme ole vielä käsitelleet koko reitityksen käsitettä, mutta tiedämme, että reitittimillä on reititystaulukko. Tässä taulukossa on merkintä verkolle, jonka osoite on 30.1.1.0. Kuten muistat, tämä ei ole isännän IP-osoite, vaan verkon tunniste. Reititin "luulee" pääsevänsä osoitteeseen 30.1.1.0/24 käymällä reitittimen 20.1.1.2 kautta.
Saatat kysyä, mistä hän tietää tämän? Muista vain, että se tietää tämän joko reititysprotokollista tai asetuksistasi, jos olet järjestelmänvalvojana määrittänyt staattisen reitin. Mutta joka tapauksessa tämän reitittimen reititystaulukko sisältää oikean merkinnän, joten se tietää, että sen pitäisi lähettää tämä paketti 20.1.1.2:een. Olettaen, että reititin tietää jo MAC-kohteen osoitteen, jatkamme yksinkertaisesti paketin edelleenlähetystä. Jos hän ei tiedä tätä osoitetta, hän käynnistää ARP:n uudelleen, vastaanottaa reitittimen MAC-osoitteen 20.1.1.2 ja kehyksen lähettäminen jatkuu uudelleen.
Joten oletetaan, että se tietää jo MAC-osoitteen, niin meillä on BBB-lähde-MAC-osoite ja CCC-kohde-MAC-osoite. Reititin laskee jälleen FCS/CRC:n ja sijoittaa sen kehyksen alkuun.
Sitten se lähettää tämän kehyksen verkon yli, kehys saavuttaa reitittimen 20.1.12, se tarkistaa tarkistussumman, varmistaa, että tiedot eivät ole vioittuneet, ja poistaa FCS/CRC:n. Sitten se "katkaisee" MAC-osoitteet, katsoo määränpäätä ja huomaa, että se on 30.1.1.10. Hän tietää, että tämä osoite on yhdistetty hänen käyttöliittymäänsä. Sama kehyksen muodostusprosessi toistetaan, reititin lisää lähde- ja kohde-MAC-osoitteen arvot, tekee hajautusarvon, liittää tiivisteen kehykseen ja lähettää sen verkon yli.
Palvelimemme, saatuaan vihdoin sille osoitetun SYN-pyynnön, tarkistaa hash-tarkistussumman ja jos paketissa ei ole virheitä, se poistaa tiivisteen. Sitten hän poistaa MAC-osoitteet, katsoo IP-osoitetta ja huomaa, että tämä paketti on osoitettu hänelle.
Sen jälkeen se katkaisee OSI-mallin kolmanteen kerrokseen liittyvät IP-osoitteet ja tarkastelee porttinumeroita.
Hän näkee portin 21, mikä tarkoittaa FTP-liikennettä, näkee SYN:n ja ymmärtää siksi, että joku yrittää kommunikoida hänen kanssaan.
Nyt kättelystä opittujen tietojen perusteella palvelin 30.1.1.10 luo SYN/ACK-paketin ja lähettää sen takaisin tietokoneelle 10.1.1.10. Vastaanotettuaan tämän paketin laite 10.1.1.10 luo kuittauksen, välittää sen verkon läpi samalla tavalla kuin SYN-paketti, ja kun palvelin vastaanottaa ACK:n, yhteys muodostetaan.
Yksi asia, jonka sinun pitäisi tietää, on, että tämä kaikki tapahtuu alle sekunnissa. Tämä on erittäin, erittäin nopea prosessi, jota yritin hidastaa, jotta kaikki olisi sinulle selvää.
Toivottavasti tästä opetusohjelmasta oppimasi asiat ovat sinulle hyödyllisiä. Jos sinulla on kysyttävää, kirjoita minulle osoitteeseen [sähköposti suojattu] tai jätä kysymyksiä tämän videon alle.
Seuraavasta oppitunnista alkaen valitsen YouTubesta kolme mielenkiintoisinta kysymystä, jotka käyn läpi jokaisen videon lopussa. Tästä lähtien minulla on "Suosituimmat kysymykset" -osio, joten julkaisen kysymyksen nimesi kanssa ja vastaan siihen livenä. Uskon, että tästä on hyötyä.
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, 30 %:n alennus Habr-käyttäjille ainutlaatuisesta lähtötason palvelimien analogista, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
VPS (KVM) E5-2650 v4 (6 ydintä) 10 Gt DDR4 240 Gt SSD 1 Gbps ilmaiseksi kesään asti kun maksat kuuden kuukauden ajan, voit tilata .
Dell R730xd 2 kertaa halvempi? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com