Përpara se të fillojmë video-tutorialin e sotëm, dua të falënderoj të gjithë ata që kontribuan në popullaritetin e kursit tim në YouTube. Kur e nisa rreth 8 muaj më parë, nuk e prisja një sukses të tillë - sot mësimet e mia janë parë nga 312724 njerëz, kam 11208 abonentë. Nuk e kisha ëndërruar kurrë që ky fillim modest do të arrinte lartësi të tilla. Por le të mos humbim kohë dhe të kalojmë direkt në mësimin e sotëm. Sot do të plotësojmë boshllëqet që kanë ndodhur në 7 video mësimet e fundit. Edhe pse sot është vetëm dita e 6-të, dita 3 u nda në 3 mësime video, kështu që sot do të shikoni në të vërtetë mësimin e tetë video.
Sot do të trajtojmë 3 tema të rëndësishme: DHCP, transporti TCP dhe numrat më të zakonshëm të portave. Ne kemi folur tashmë për adresat IP, dhe një nga faktorët më të rëndësishëm në konfigurimin e adresës IP është DHCP.
DHCP qëndron për Protokollin e Konfigurimit Dynamic Host dhe është një protokoll që ndihmon në konfigurimin dinamik të adresave IP për hostet. Pra, të gjithë e kemi parë këtë dritare. Kur klikoni në opsionin "Merrni një adresë IP automatikisht", kompjuteri kërkon një server DHCP që është i konfiguruar në të njëjtin nënrrjet dhe dërgon pako dhe kërkesa të ndryshme për adresën IP. Protokolli DHCP ka 6 mesazhe, nga të cilat 4 janë kritike për caktimin e një adrese IP.
Mesazhi i parë është një mesazh DHCP DISCOVERY. Mesazhi i zbulimit të DHCP është i ngjashëm me një mesazh përshëndetjeje. Kur një pajisje e re bashkohet me rrjetin, pyet nëse ka një server DHCP në rrjet.
Ajo që shihni në rrëshqitje duket si një kërkesë transmetimi ku pajisja kontakton të gjitha pajisjet në rrjet duke kërkuar një server DHCP. Siç thashë, kjo është një kërkesë transmetimi, kështu që të gjitha pajisjet në rrjet mund ta dëgjojnë atë.
Nëse ka një server DHCP në rrjet, ai dërgon një paketë - një ofertë DHCP OFFER. Propozimi do të thotë që serveri DHCP, në përgjigje të një kërkese zbulimi, i dërgon një konfigurim klientit, duke i kërkuar klientit të pranojë një adresë IP specifike.
Serveri DHCP rezervon një adresë IP, në këtë rast 192.168.1.2, nuk e jep atë, por e rezervon këtë adresë për pajisjen. Në të njëjtën kohë, paketa e ofertës përmban adresën e vet IP të serverit DHCP.
Nëse ka më shumë se një server DHCP në këtë rrjet, një server tjetër DHCP, me marrjen e kërkesës për transmetim të klientit, do t'i ofronte atij gjithashtu adresën e tij IP, për shembull, 192.168.1.50. Nuk është e zakonshme të kesh dy serverë të ndryshëm DHCP të konfiguruar në të njëjtin rrjet, por ndonjëherë ndodh. Pra, kur një ofertë DHCP i dërgohet një klienti, ai merr 2 oferta DHCP dhe tani duhet të vendosë se cilën ofertë DHCP dëshiron të pranojë.
Le të supozojmë se klienti pranon aplikacionin e parë. Kjo do të thotë që klienti dërgon një kërkesë DHCP KËRKESË që fjalë për fjalë thotë "Unë pranoj adresën IP 192.168.1.2 të ofruar nga serveri DHCP 192.168.1.1."
Pas marrjes së kërkesës, serveri DHCP 192.168.1.1 përgjigjet "në rregull, e pranoj", domethënë, ai e pranon kërkesën dhe ia dërgon këtë DHCP ACK klientit. Por ne kujtojmë se një server tjetër DHCP ka rezervuar një adresë IP prej 1.50 për klientin. Pasi të marrë kërkesën e një klienti për transmetim, ai do të dijë për dështimin dhe do ta vendosë atë adresë IP përsëri në grup në mënyrë që të mund t'ia caktojë një klienti tjetër nëse merr një kërkesë tjetër.
Këto janë 4 mesazhet kritike që DHCP shkëmben kur cakton adresat IP. Më pas, DHCP ka 2 mesazhe të tjera informacioni. Një mesazh informacioni lëshohet nga klienti nëse kërkon më shumë informacion sesa ka marrë në klauzolën OFERTA DHCP në hapin e dytë. Nëse serveri nuk ka dhënë informacion të mjaftueshëm në ofertën DHCP, ose nëse klienti ka nevojë për më shumë informacion sesa ai që përmbahej në paketën e ofertës, ai kërkon informacion shtesë DHCP. Ekziston edhe një mesazh tjetër që klienti dërgon në server - ky është DHCP RELEASE. Ju informon se klienti dëshiron të lëshojë adresën e tij ekzistuese IP.
Megjithatë, ajo që ndodh më shpesh është që përdoruesi shkëputet nga rrjeti përpara se klienti të ketë kohë për të dërguar një DHCP RELEASE në server. Kjo ndodh kur ju fikni kompjuterin, gjë që ne e bëjmë. Në këtë rast, klienti i rrjetit, ose kompjuteri, thjesht nuk ka kohë të informojë serverin për të lëshuar adresën e përdorur, kështu që DHCP RELEASE nuk është një hap i kërkuar. Hapat e kërkuar për të marrë një adresë IP janë: zbulimi i DHCP, oferta DHCP, kërkesa DHCP dhe shtrëngimi i duarve DHCP.
Në një nga mësimet e ardhshme do t'ju tregoj se si konfigurojmë një server DHCP kur krijojmë një grup DNCP. Me bashkim nënkuptojmë që ju i thoni serverit të caktojë adresat IP në intervalin 192.168.1.1 deri në 192.168.1.254. Kështu, serveri DHCP do të krijojë një grup, do të vendosë 254 adresa IP në të dhe do të jetë në gjendje të caktojë adresa për klientët në rrjet vetëm nga ky grup. Pra, kjo është diçka si një cilësim administrativ që përdoruesi mund të bëjë.
Tani le të shohim transmetimin TCP. Nuk e di nëse e njihni "telefonin" e paraqitur në foto, por kur ishim fëmijë përdornim këto kanaçe të lidhura me një fije për të folur me njëri-tjetrin.
Fatkeqësisht, brezi i sotëm nuk mund ta përballojë një “luks” të tillë. Dua të them sot fëmijët janë para televizorit nga mosha një vjeç, ata luajnë PSP dhe ndoshta kjo është e diskutueshme, por mendoj se kemi pasur fëmijërinë më të mirë, ne në fakt dolëm jashtë dhe luanim lojëra dhe fëmijët e sotëm nuk mund të tërhiqen nga divani. .
Djali im është vetëm një vjeç dhe tashmë e shoh që është i varur nga iPad-i, dua të them se është ende shumë i vogël, por mendoj se fëmijët e sotëm tashmë kanë lindur duke ditur të trajtojnë pajisjet elektronike. Pra, doja të thoja se si fëmijë, kur luanim, bënim vrima në kanaçe, dhe kur i lidhnim me një fije dhe thoshim diçka në një kanaçe, atëherë në anën tjetër personi dëgjonte se çfarë thuhej. atij, thjesht duke i vendosur kanaçe në vesh. Pra, është shumë e ngjashme me një lidhje rrjeti.
Sot, edhe transferimet TCP duhet të kenë një lidhje që duhet të krijohet përpara se të fillojë transferimi aktual i të dhënave. Siç kemi diskutuar në mësimet e mëparshme, TCP është transmetim i orientuar drejt lidhjes ndërsa UDP është transmetim i orientuar drejt lidhjes. Mund të thuash që UDP është vendi ku unë e hedh topin dhe varet nga ju për të parë nëse mund ta kapni atë. Nëse je gati ta bësh apo jo nuk është problemi im, unë thjesht do ta lë atë.
TCP është më shumë si ju duke folur me një djalë dhe duke e paralajmëruar atë paraprakisht se do të hidhni një top, kështu që ju krijoni një lidhje dhe më pas e hidhni topin në mënyrë që partneri juaj të jetë më i gatshëm për ta kapur atë. Pra, TCP në fakt ndërton lidhjen dhe më pas fillon të bëjë transmetimin aktual.
Le të shohim se si krijon një lidhje të tillë. Ky protokoll përdor një shtrëngim duarsh në 3 drejtime për të krijuar një lidhje. Ky nuk është një term shumë teknik, por është përdorur prej kohësh për të përshkruar një lidhje TCP. Një shtrëngim duarsh në 3 drejtime inicohet nga pajisja dërguese, me klientin që dërgon një paketë me një flamur SYN në server.
Le të themi se vajza në plan të parë, fytyra e së cilës mund ta shohim, është pajisja A, dhe vajza në sfond, fytyra e së cilës nuk duket, është pajisja B. Vajza A i dërgon një pako SYN vajzës B dhe ajo thotë: “Shkëlqyeshëm, kush- atëherë ai dëshiron të komunikojë me mua. Pra, më duhet të përgjigjem se jam gati të komunikoj!” Si ta bëjmë atë? Dikush thjesht mund të dërgojë një paketë tjetër SYN dhe më pas një ACK që tregon marrjen e paketës origjinale SYN. Por në vend që të dërgojë ACK-të veçmas, serveri formon një paketë të përbashkët që përmban SYN dhe ACK dhe e transmeton atë përmes rrjetit.
Pra, në këtë pikë, pajisja A ka dërguar një paketë SYN dhe ka marrë përsëri një paketë SYN/ACK. Tani pajisja A duhet t'i dërgojë pajisjes B një paketë ACK, domethënë të konfirmojë që ka marrë pëlqimin nga pajisja B për të vendosur komunikimin. Kështu, të dy pajisjet morën pako SYN dhe ACK, dhe tani mund të themi se lidhja është krijuar, domethënë, një shtrëngim duarsh me 3 faza është përfunduar duke përdorur protokollin TCP.
Më pas do të shikojmë teknologjinë e dritareve TCP. E thënë thjesht, është një metodë e përdorur në TCP/IP për të negociuar aftësitë e dërguesit dhe marrësit.
Le të themi se në Windows ne po përpiqemi të transferojmë një skedar të madh, të themi 2 GB në madhësi, nga një disk në tjetrin. Që në fillim të transferimit, sistemi do të na informojë se transferimi i skedarit do të zgjasë afërsisht 1 vit. Por disa sekonda më vonë sistemi do të korrigjohet dhe do të thotë: "Oh, prit një minutë, mendoj se do të duhen rreth 6 muaj, jo një vit." Do të kalojë pak më shumë kohë dhe Windows do të thotë: "Mendoj se mund ta transferoj skedarin brenda 1 muaji." Kjo do të pasohet nga mesazhi "1 ditë", "6 orë", "3 orë", "1 orë", "20 minuta", "10 minuta", "3 minuta". Në fakt, i gjithë procesi i transferimit të skedarëve do të zgjasë vetëm 3 minuta. Si ndodhi kjo? Fillimisht, kur pajisja juaj përpiqet të komunikojë me një pajisje tjetër, ajo dërgon një paketë dhe pret për konfirmim. Nëse pajisja pret një kohë të gjatë për konfirmim, ajo mendon: "Nëse më duhet të transferoj 2 GB të dhëna me këtë shpejtësi, do të duhen rreth 2 vjet." Pas ca kohësh, pajisja juaj merr një ACK dhe mendon, “në rregull, dërgova një pako dhe mora një ACK, prandaj marrësi mund të marrë 1 pako. Tani do të përpiqem t'i dërgoj 10 pako në vend të një." Dërguesi dërgon 10 pako dhe pas njëfarë kohe merr një konfirmim ACK nga pajisja marrëse, që do të thotë se marrësi është duke pritur për paketën tjetër, të 11-të. Dërguesi mendon: "Shkëlqyeshëm, pasi marrësi trajtoi 10 pako menjëherë, tani do të përpiqem t'i dërgoj 100 pako në vend të dhjetë". Ai dërgon 100 pako, dhe marrësi përgjigjet se i ka marrë dhe tani pret 101 pako. Kështu, me kalimin e kohës, numri i paketave të transmetuara rritet.
Kjo është arsyeja pse ju shihni një rënie të shpejtë në kohën e kopjimit të skedarit në krahasim me atë që u tha fillimisht - kjo është për shkak të aftësisë së shtuar për të transferuar sasi të mëdha të dhënash. Sidoqoftë, vjen një moment kur rritja e mëtejshme e vëllimit të transmetimit bëhet e pamundur. Le të themi se keni dërguar 10000 pako, por buferi i pajisjes së marrësit mund të pranojë vetëm 9000. Në këtë rast, marrësi dërgon një ACK me mesazhin: "Kam marrë 9000 pako dhe tani jam gati të marr 9001." Nga kjo, dërguesi konkludon se buferi i pajisjes marrëse ka një kapacitet prej vetëm 9000, që do të thotë se tani e tutje unë do të dërgoj jo më shumë se 9000 pako në të njëjtën kohë. Në këtë rast, dërguesi llogarit shpejt kohën që do t'i duhet për të transferuar sasinë e mbetur të të dhënave në pjesë prej 9000 paketash dhe jep 3 minuta. Këto tre minuta janë koha aktuale e transmetimit. Kjo është ajo që bën TCP Windowing.
Ky është një nga mekanizmat e pengimit të trafikut ku pajisja dërguese përfundimisht kupton se cili është kapaciteti aktual i rrjetit. Ju mund të pyesni veten pse ata nuk mund të bien dakord paraprakisht se sa është kapaciteti i pajisjes marrëse? Fakti është se kjo është teknikisht e pamundur sepse ka lloje të ndryshme pajisjesh në rrjet. Le të themi se keni një iPad dhe ai ka një shpejtësi të ndryshme të transferimit/marrësit të të dhënave sesa një iPhone, mund të keni lloje të ndryshme telefonash ose ndoshta keni një kompjuter shumë të vjetër. Prandaj, të gjithë kanë gjerësi të ndryshme të brezit të rrjetit.
Kjo është arsyeja pse u zhvillua teknologjia TCP Windowing, kur transmetimi i të dhënave fillon me shpejtësi të ulët ose me transmetimin e një numri minimal paketash, duke rritur gradualisht "dritaren" e trafikut. Ju dërgoni një pako, 5 pako, 10 pako, 1000 pako, 10000 pako dhe ngadalë e hapni atë dritare gjithnjë e më shumë derisa "hapja" të arrijë vëllimin maksimal të mundshëm të trafikut të dërguar në një periudhë të caktuar kohore. Kështu, koncepti i Windowing është pjesë e funksionimit të protokollit TCP.
Më tej do të shohim numrat më të zakonshëm të portave. Situata klasike është kur keni 1 server kryesor, ndoshta një qendër të dhënash. Ai përfshin një server skedari, server në internet, server mail dhe server DHCP. Tani, nëse një nga kompjuterët e klientit kontakton qendrën e të dhënave, e cila ndodhet në mes të figurës, ajo do të fillojë të dërgojë trafikun e serverit të skedarëve te pajisjet e klientit. Ky trafik tregohet me të kuqe dhe do të transmetohet në një port specifik për një aplikacion specifik nga një server specifik.
Si e dinte serveri se ku duhet të shkonte një trafik i caktuar? Ai e mëson këtë nga numri i portit të destinacionit. Nëse shikoni kornizën, do të shihni se në çdo transferim të të dhënave përmendet numri i portit të destinacionit dhe numri i portit burimor. Ju mund të shihni se trafiku blu dhe i kuq, dhe trafiku blu është trafiku i serverit në internet, të dy shkojnë në të njëjtin server fizik, i cili ka serverë të ndryshëm të instaluar. Nëse kjo është një qendër e të dhënave, atëherë përdor serverë virtualë. Pra, si e dinin ata që trafiku i kuq duhej të kthehej në atë laptop të majtë me atë adresë IP? Ata e dinë këtë falë numrave të portit. Nëse i referoheni artikullit të Wikipedia-s "Lista e porteve TCP dhe UDP", do të shihni se ai rendit të gjithë numrat standardë të portave.
Nëse lëvizni poshtë në këtë faqe, mund të shihni se sa e madhe është kjo listë. Ai përmban rreth 61 numra. Numrat e portave nga 000 deri në 1 njihen si numrat më të zakonshëm të portave. Për shembull, porti 1024/TCP është për dërgimin e komandave ftp, porti 21 është për ssh, porti 22 është për Telnet, domethënë për dërgimin e mesazheve të pakriptuara. Porta shumë e njohur 23 bart të dhëna mbi HTTP, ndërsa porta 80 bart të dhëna të koduara mbi HTTPS, e cila është e ngjashme me versionin e sigurt të HTTP.
Disa porte janë të dedikuara si për TCP ashtu edhe për UDP, dhe disa kryejnë detyra të ndryshme në varësi të faktit nëse lidhja është TCP ose UDP. Pra, zyrtarisht porta TCP 80 përdoret për HTTP, dhe jozyrtarisht porta UDP 80 përdoret për HTTP, por nën një protokoll tjetër HTTP - QUIC.
Prandaj, numrat e portave në TCP nuk synojnë gjithmonë të bëjnë të njëjtën gjë si në UDP. Nuk keni nevojë ta mësoni përmendësh këtë listë, është e pamundur ta mbani mend, por duhet të dini disa numra portualë të njohur dhe më të zakonshëm. Siç thashë, disa nga këto porte kanë një qëllim zyrtar, i cili përshkruhet në standarde, dhe disa kanë një qëllim jozyrtar, siç është rasti me Chromium.
Pra, kjo tabelë liston të gjithë numrat e zakonshëm të portave dhe këta numra përdoren për të dërguar dhe marrë trafik kur përdorni aplikacione specifike.
Tani le të shohim se si lëvizin të dhënat nëpër rrjet bazuar në atë pak informacion që dimë. Le të themi se kompjuteri 10.1.1.10 dëshiron të kontaktojë këtë kompjuter, ose këtë server, i cili ka adresën 30.1.1.10. Nën adresën IP të secilës pajisje është adresa MAC e saj. Po jap shembullin e një adrese MAC me vetëm 4 karakteret e fundit, por në praktikë është një numër heksadecimal 48-bit me 12 karaktere. Meqenëse secili prej këtyre numrave përbëhet nga 4 bit, 12 shifra heksadecimal përfaqësojnë një numër 48-bitësh.
Siç e dimë, nëse kjo pajisje dëshiron të kontaktojë këtë server, fillimisht duhet të bëhet hapi i parë i shtrëngimit të duarve 3-kahëshe, domethënë dërgimi i një pakete SYN. Kur të bëhet kjo kërkesë, kompjuteri 10.1.1.10 do të specifikojë numrin e portit burimor, të cilin Windows e krijon në mënyrë dinamike. Windows zgjedh rastësisht një numër porti midis 1 dhe 65,000. Por duke qenë se numrat fillestarë në intervalin 1 deri në 1024 janë gjerësisht të njohur, në këtë rast sistemi do të marrë në konsideratë numrat më të mëdhenj se 25000 dhe do të krijojë një portë burimi të rastësishëm, për shembull, numrin 25113.
Më pas, sistemi do t'i shtojë paketës një port destinacion, në këtë rast është porti 21, sepse aplikacioni që po përpiqet të lidhet me këtë server FTP e di që duhet të dërgojë trafik FTP.
Më pas, kompjuteri ynë thotë: "Në rregull, adresa ime IP është 10.1.1.10 dhe më duhet të kontaktoj adresën IP 30.1.1.10." Të dyja këto adresa përfshihen gjithashtu në paketë për të formuar një kërkesë SYN dhe kjo paketë nuk do të ndryshojë deri në fund të lidhjes.
Unë dua që ju të kuptoni nga kjo video se si lëvizin të dhënat nëpër rrjet. Kur kompjuteri ynë që dërgon kërkesën sheh adresën IP të burimit dhe adresën IP të destinacionit, kupton që adresa e destinacionit nuk është në atë rrjet lokal. Kam harruar të them se këto janë të gjitha adresat IP / 24. Pra, nëse shikoni adresat IP /24, do të kuptoni se kompjuterët 10.1.1.10 dhe 30.1.1.10 nuk janë në të njëjtin rrjet. Kështu, kompjuteri që dërgon kërkesën kupton që për të dalë nga ky rrjet, duhet të kontaktojë portën 10.1.1.1, e cila është konfiguruar në një nga ndërfaqet e ruterit. Ai e di se duhet të shkojë në 10.1.1.1 dhe e di adresën e tij MAC të 1111, por nuk e di adresën MAC të portës 10.1.1.1. Çfarë po bën ai? Ai dërgon një kërkesë transmetuese ARP që do të marrin të gjitha pajisjet në rrjet, por vetëm ruteri me adresën IP 10.1.1.1 do t'i përgjigjet asaj.
Ruteri do të përgjigjet me adresën e tij MAC AAAA dhe adresat MAC të burimit dhe të destinacionit do të vendosen gjithashtu në këtë kornizë. Pasi korniza të jetë gati, do të kryhet një kontroll i integritetit të të dhënave CRC, i cili është një algoritëm për të gjetur një shumë kontrolli për të zbuluar gabimet, përpara se të largoheni nga rrjeti.
CRC Redundancy Ciclic do të thotë që i gjithë ky kuadër, nga SYN në adresën e fundit MAC, drejtohet përmes një algoritmi hashing, le të themi MD5, duke rezultuar në një vlerë hash. Vlera hash, ose MD5 checksum, vendoset më pas në fillim të kornizës.
E etiketova FCS/CRC sepse FCS është një Sekuencë e Kontrollit të Kornizave, një vlerë CRC me katër bajtë. Disa njerëz përdorin emërtimin FCS dhe disa përdorin përcaktimin CRC, kështu që unë sapo përfshiva të dy përcaktimet. Por në thelb është vetëm një vlerë hash. Është e nevojshme për t'u siguruar që të gjitha të dhënat e marra përmes rrjetit të mos përmbajnë gabime. Prandaj, kur kjo kornizë të arrijë në ruter, gjëja e parë që do të bëjë ruteri është të llogarisë vetë shumën e kontrollit dhe ta krahasojë atë me vlerën FCS ose CRC që përmban korniza e marrë. Në këtë mënyrë ai mund të kontrollojë që të dhënat e marra në rrjet të mos përmbajnë gabime, pas së cilës ai do të heqë kontrollin nga korniza.
Më pas, ruteri do të shikojë adresën MAC dhe do të thotë, "Mirë, adresa MAC AAAA do të thotë se korniza më është adresuar mua" dhe do të fshijë pjesën e kornizës që përmban adresat MAC.
Duke parë adresën IP të destinacionit 30.1.1.10, ai do të kuptojë se kjo paketë nuk i drejtohet atij dhe duhet të kalojë më tej përmes ruterit.
Tani ruteri "mendon" se duhet të shohë se ku ndodhet rrjeti me adresën 30.1.1.10. Ne nuk e kemi mbuluar ende konceptin e plotë të rrugëtimit, por e dimë se ruterat kanë një tabelë rutimi. Kjo tabelë ka një hyrje për rrjetin me adresën 30.1.1.0. Siç e mbani mend, kjo nuk është adresa IP e hostit, por identifikuesi i rrjetit. Ruteri do të "mendojë" se mund të arrijë adresën 30.1.1.0/24 duke kaluar përmes ruterit 20.1.1.2.
Ju mund të pyesni, nga e di ai këtë? Vetëm mbani në mend se do ta dijë këtë ose nga protokollet e rrugëzimit ose nga cilësimet tuaja nëse ju si administrator keni konfiguruar një rrugë statike. Por sido që të jetë, tabela e rrugëzimit të këtij ruteri përmban hyrjen e saktë, kështu që e di se duhet ta dërgojë këtë paketë në 20.1.1.2. Duke supozuar se ruteri tashmë e di adresën MAC të destinacionit, ne thjesht do të vazhdojmë të përcjellim paketën. Nëse ai nuk e di këtë adresë, ai do të nisë përsëri ARP, do të marrë adresën MAC të ruterit 20.1.1.2 dhe procesi i dërgimit të kornizës do të vazhdojë përsëri.
Pra, supozojmë se tashmë e di adresën MAC, atëherë do të kemi adresën MAC të burimit BBB dhe adresën MAC të destinacionit CCC. Ruteri përsëri llogarit FCS/CRC dhe e vendos atë në fillim të kornizës.
Më pas e dërgon këtë kornizë në rrjet, korniza arrin në ruterin 20.1.12, kontrollon kontrollin, sigurohet që të dhënat të mos jenë të korruptuara dhe fshin FCS/CRC. Më pas “shkurt” adresat MAC, shikon destinacionin dhe sheh që është 30.1.1.10. Ai e di që kjo adresë është e lidhur me ndërfaqen e tij. I njëjti proces i formimit të kornizës përsëritet, ruteri shton vlerat e adresës MAC të burimit dhe destinacionit, bën hashimin, bashkon hash-in në kornizë dhe e dërgon atë nëpër rrjet.
Serveri ynë, pasi ka marrë më në fund kërkesën SYN drejtuar tij, kontrollon shumën e kontrollit të hash-it dhe nëse paketa nuk përmban gabime, ai fshin hash-in. Pastaj ai heq adresat MAC, shikon adresën IP dhe kupton që kjo paketë i drejtohet atij.
Pas kësaj, ai shkurton adresat IP që lidhen me shtresën e tretë të modelit OSI dhe shikon numrat e portit.
Ai sheh portin 21, që do të thotë trafik FTP, sheh SYN dhe për këtë arsye kupton që dikush po përpiqet të komunikojë me të.
Tani, bazuar në atë që mësuam për shtrëngimin e duarve, serveri 30.1.1.10 do të krijojë një paketë SYN/ACK dhe do ta dërgojë përsëri në kompjuterin 10.1.1.10. Me marrjen e kësaj pakete, pajisja 10.1.1.10 do të krijojë një ACK, do ta kalojë atë përmes rrjetit në të njëjtën mënyrë si një paketë SYN dhe pasi serveri të marrë ACK, lidhja do të vendoset.
Një gjë që duhet të dini është se e gjithë kjo ndodh në më pak se një sekondë. Ky është një proces shumë, shumë i shpejtë, të cilin jam përpjekur ta ngadalësoj në mënyrë që gjithçka të jetë e qartë për ju.
Shpresoj që t'ju duket e dobishme ajo që keni mësuar në këtë tutorial. Nëse keni ndonjë pyetje, ju lutem më shkruani në [email mbrojtur] ose lini pyetje nën këtë video.
Duke filluar nga mësimi tjetër, do të zgjedh 3 pyetjet më interesante nga YouTube, të cilat do t'i shqyrtoj në fund të çdo videoje. Tani e tutje do të kem një seksion "Pyetjet kryesore", kështu që do të postoj një pyetje së bashku me emrin tuaj dhe do t'i përgjigjem drejtpërdrejt. Unë mendoj se kjo do të jetë e dobishme.
Faleminderit që qëndruat me ne. A ju pëlqejnë artikujt tanë? Dëshironi të shihni përmbajtje më interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar miqve, 30% zbritje për përdoruesit e Habr në një analog unik të serverëve të nivelit të hyrjes, i cili u shpik nga ne për ju: (e disponueshme me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40 GB DDR4).
VPS (KVM) E5-2650 v4 (6 bërthama) 10 GB DDR4 240 GB SSD 1 Gbps falas deri në verë kur paguani për një periudhë gjashtëmujore, mund të porosisni .
Dell R730xd 2 herë më lirë? Vetëm këtu në Holandë! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - nga 99 dollarë! Lexoni rreth
Burimi: www.habr.com