Skôr ako začneme s dnešným videonávodom, chcem poďakovať všetkým, ktorí prispeli k popularite môjho kurzu na YouTube. Keď som s tým asi pred 8 mesiacmi začínal, nečakal som taký úspech – dnes si moje lekcie pozrelo 312724 11208 ľudí, ja mám 7 6 odberateľov. Nikdy sa mi nesnívalo, že tento skromný začiatok dosiahne také výšky. Ale nestrácajme čas a poďme rovno k dnešnej lekcii. Dnes doplníme medzery, ktoré nastali v posledných 3 video lekciách. Hoci je dnes len 3. deň, XNUMX. deň bol rozdelený na XNUMX video lekcie, takže dnes si vlastne pozriete ôsmu video lekciu.
Dnes sa budeme venovať 3 dôležitým témam: DHCP, transport TCP a najbežnejšie čísla portov. O IP adresách sme už hovorili a jedným z najdôležitejších faktorov pri konfigurácii IP adresy je DHCP.
DHCP je skratka pre Dynamic Host Configuration Protocol a je to protokol, ktorý pomáha dynamicky konfigurovať IP adresy pre hostiteľov. Takže toto okno sme už všetci videli. Keď kliknete na možnosť „Získať adresu IP automaticky“, počítač vyhľadá server DHCP, ktorý je nakonfigurovaný v rovnakej podsieti a odošle rôzne pakety a požiadavky na adresu IP. Protokol DHCP má 6 správ, z ktorých 4 sú kritické pre pridelenie IP adresy.
Prvá správa je správa DHCP DISCOVERY. Správa o nájdení DHCP je podobná uvítacej správe. Keď sa nové zariadenie pripojí k sieti, spýta sa, či je v sieti DHCP server.
To, čo vidíte na snímke, vyzerá ako požiadavka na vysielanie, kde zariadenie kontaktuje všetky zariadenia v sieti a hľadá server DHCP. Ako som povedal, ide o požiadavku na vysielanie, takže ju môžu počuť všetky zariadenia v sieti.
Ak je v sieti DHCP server, odošle paket – ponuku DHCP PONUKA. Návrh znamená, že server DHCP v odpovedi na požiadavku na zistenie odošle klientovi konfiguráciu a požiada klienta, aby akceptoval konkrétnu IP adresu.
Server DHCP rezervuje IP adresu, v tomto prípade 192.168.1.2, neposkytuje ju, ale rezervuje túto adresu pre zariadenie. Ponukový balík zároveň obsahuje vlastnú IP adresu DHCP servera.
Ak je v tejto sieti viac ako jeden server DHCP, iný server DHCP by mu po prijatí požiadavky na vysielanie klienta tiež ponúkol svoju IP adresu, napríklad 192.168.1.50. Nie je bežné mať v tej istej sieti nakonfigurované dva rôzne servery DHCP, ale niekedy sa to stane. Keď sa teda klientovi odošle ponuka DHCP, dostane 2 ponuky DHCP a teraz sa musí rozhodnúť, ktorú ponuku DHCP chce prijať.
Predpokladajme, že klient prijme prvú aplikáciu. To znamená, že klient odošle požiadavku DHCP REQUEST, ktorá doslova hovorí: „Prijímam adresu IP 192.168.1.2, ktorú ponúka server DHCP 192.168.1.1.“
Po prijatí požiadavky server DHCP 192.168.1.1 odpovie „dobre, uznávam“, to znamená, že potvrdí požiadavku a odošle toto DHCP ACK klientovi. Pamätáme si však, že iný server DHCP rezervoval pre klienta IP adresu 1.50. Keď dostane požiadavku klienta na vysielanie, bude vedieť o zlyhaní a vráti túto IP adresu späť do oblasti, aby ju mohol priradiť inému klientovi, ak dostane ďalšiu požiadavku.
Toto sú 4 kritické správy, ktoré si DHCP vymieňa pri prideľovaní IP adries. Ďalej má DHCP ďalšie 2 informačné správy. Informačnú správu vyšle klient, ak vyžaduje viac informácií, ako prijal v klauzule DHCP PONUKA v druhom kroku. Ak server neposkytol dostatok informácií v ponuke DHCP alebo ak klient potrebuje viac informácií, než aké boli obsiahnuté v pakete ponuky, vyžiada si ďalšie informácie DHCP. Je tu ešte jedna správa, ktorú klient posiela na server – toto je DHCP RELEASE. Informuje vás, že klient chce uvoľniť svoju existujúcu IP adresu.
Najčastejšie sa však stáva, že sa používateľ odpojí od siete skôr, ako klient stihne poslať server DHCP RELEASE. To sa stane, keď vypnete počítač, čo robíme my. V tomto prípade sieťový klient alebo počítač jednoducho nemá čas informovať server o uvoľnení použitej adresy, takže UVOĽNENIE DHCP nie je požadovaným krokom. Požadované kroky na získanie adresy IP sú: zistenie DHCP, ponuka DHCP, požiadavka DHCP a nadviazanie spojenia DHCP.
V jednej z nasledujúcich lekcií vám poviem, ako konfigurujeme server DHCP pri vytváraní fondu DNCP. Združovaním máme na mysli, že poviete serveru, aby pridelil IP adresy v rozsahu 192.168.1.1 až 192.168.1.254. Server DHCP teda vytvorí fond, umiestni do neho 254 IP adries a bude môcť prideľovať adresy klientom v sieti iba z tohto fondu. Ide teda o niečo ako administratívne nastavenie, ktoré môže vykonať používateľ.
Teraz sa pozrime na prenos TCP. Neviem, či poznáte ten „telefón“ na obrázku, ale keď sme boli deti, používali sme tieto plechovky spojené šnúrkou, aby sme sa spolu rozprávali.
Žiaľ, dnešná generácia si takýto „luxus“ nemôže dovoliť. Myslím tým, že dnes sú deti pred televízorom od jedného roka, hrajú PSP a možno je to diskutabilné, ale myslím, že sme mali najkrajšie detstvo, vlastne sme chodili von a hrali hry a dnešné deti sa nedajú odtiahnuť od pohovky .
Môj syn má len rok a už vidím, že je závislý na iPade, teda ešte veľmi malý, ale myslím si, že dnešné deti sa už rodia, že vedia narábať s elektronickými prístrojmi. Chcel som teda povedať, že keď sme sa ako deti hrali, robili sme diery do plechoviek, a keď sme ich zviazali šnúrkou a povedali niečo do jednej plechovky, na druhom konci ten človek počul, čo sa hovorí. k nemu jednoducho priložením plechovky k uchu . Je to teda veľmi podobné sieťovému pripojeniu.
Dnes už aj prenosy TCP musia mať spojenie, ktoré musí byť nadviazané ešte pred začiatkom samotného prenosu dát. Ako sme diskutovali v predchádzajúcich lekciách, TCP je prenos orientovaný na spojenie, zatiaľ čo UDP je prenos orientovaný na spojenie. Dalo by sa povedať, že UDP je miesto, kde hodím loptu a je len na vás, či ju dokážete chytiť. Či si na to pripravený alebo nie, nie je môj problém, len ho opustím.
TCP je skôr tak, že sa rozprávate s chlapom a vopred ho varujete, že idete hádzať loptičku, tak si vytvoríte väzbu a potom hodíte loptičku, aby bol váš partner skôr pripravený ju chytiť. Takže TCP skutočne vytvorí spojenie a potom začne vykonávať skutočný prenos.
Pozrime sa, ako vytvára takéto spojenie. Tento protokol používa na vytvorenie spojenia trojcestný handshake. Toto nie je veľmi technický termín, ale už dlho sa používa na označenie TCP spojenia. Odosielajúce zariadenie iniciuje trojcestné nadviazanie spojenia, pričom klient pošle paket s príznakom SYN na server.
Povedzme, že dievča v popredí, ktorého tvár vidíme, je zariadenie A a dievča v pozadí, ktorého tvár nie je viditeľná, je zariadenie B. Dievča A pošle paket SYN dievčaťu B a povie: „Super, kto- potom chce so mnou komunikovať. Takže musím odpovedať, že som pripravený komunikovať!" Ako to spraviť? Dalo by sa jednoducho poslať späť ďalší paket SYN a potom ACK indikujúce prijatie pôvodného paketu SYN. Ale namiesto samostatného odosielania ACK, server vytvorí spoločný paket obsahujúci SYN a ACK a odošle ho cez sieť.
Takže v tomto bode zariadenie A poslalo paket SYN a prijalo späť paket SYN/ACK. Teraz musí zariadenie A poslať zariadeniu B ACK paket, to znamená potvrdiť, že dostalo súhlas od zariadenia B na nadviazanie komunikácie. Obidve zariadenia teda prijali pakety SYN a ACK a teraz môžeme povedať, že spojenie bolo nadviazané, teda bol ukončený 3-stupňový handshake pomocou protokolu TCP.
Ďalej sa pozrieme na technológiu TCP Windowing. Jednoducho povedané, je to metóda používaná v TCP/IP na vyjednávanie schopností odosielateľa a príjemcu.
Povedzme, že v systéme Windows sa pokúšame preniesť veľký súbor, povedzme s veľkosťou 2 GB, z jedného disku na druhý. Hneď na začiatku prenosu nám systém oznámi, že prenos súboru bude trvať približne 1 rok. Ale o niekoľko sekúnd neskôr sa systém opraví a povie: „Och, počkajte chvíľu, myslím, že to bude trvať asi 6 mesiacov, nie rok.“ Uplynie ešte trochu času a Windows povie: „Myslím, že by som mohol byť schopný preniesť súbor za 1 mesiac.“ Potom bude nasledovať správa „1 deň“, „6 hodín“, „3 hodiny“, „1 hodina“, „20 minút“, „10 minút“, „3 minúty“. V skutočnosti bude celý proces prenosu súborov trvať len 3 minúty. Ako sa to stalo? Na začiatku, keď sa vaše zariadenie pokúša komunikovať s iným zariadením, odošle jeden paket a čaká na potvrdenie. Ak zariadenie dlho čaká na potvrdenie, pomyslí si: „Ak mám preniesť 2 GB dát touto rýchlosťou, bude to trvať asi 2 roky.“ Po určitom čase vaše zariadenie dostane ACK a pomyslí si: „Dobre, poslal som jeden paket a dostal som ACK, takže príjemca môže prijať 1 paket. Teraz sa mu pokúsim poslať 10 balíčkov namiesto jedného." Odosielateľ odošle 10 paketov a po určitom čase dostane od prijímajúceho zariadenia potvrdenie ACK, čo znamená, že príjemca čaká na ďalší, 11. paket. Odosielateľ si myslí: „Super, keďže príjemca spracoval 10 paketov naraz, teraz mu skúsim poslať 100 paketov namiesto desiatich.“ Odošle 100 paketov a príjemca odpovie, že ich prijal a teraz čaká na 101 paketov. Postupom času sa teda počet prenášaných paketov zvyšuje.
To je dôvod, prečo vidíte rýchle skrátenie času kopírovania súboru v porovnaní s tým, čo bolo pôvodne uvedené - je to spôsobené zvýšenou schopnosťou prenášať veľké množstvo údajov. Príde však bod, kedy ďalšie zvyšovanie objemu prenosu nebude možné. Povedzme, že ste odoslali 10000 9000 paketov, ale vyrovnávacia pamäť zariadenia prijímača môže prijať iba 9000 9001. V tomto prípade prijímač odošle ACK so správou: "Prijal som 9000 9000 paketov a teraz som pripravený prijať 9000 3." Z toho odosielateľ usudzuje, že vyrovnávacia pamäť prijímacieho zariadenia má kapacitu len XNUMX, čo znamená, že odteraz nepošlem viac ako XNUMX paketov naraz. V tomto prípade odosielateľ rýchlo vypočíta čas, ktorý mu zaberie prenos zostávajúceho množstva dát po častiach XNUMX paketov, a poskytne XNUMX minúty. Tieto tri minúty sú skutočným časom prenosu. To je to, čo robí TCP Windowing.
Toto je jeden z tých mechanizmov obmedzovania prevádzky, kde odosielajúce zariadenie nakoniec pochopí, aká je skutočná kapacita siete. Možno sa pýtate, prečo sa nevedia vopred dohodnúť, akú kapacitu má prijímacie zariadenie? Faktom je, že je to technicky nemožné, pretože v sieti sú rôzne typy zariadení. Povedzme, že máte iPad a ten má inú rýchlosť prenosu/prijímania dát ako iPhone, môžete mať rôzne typy telefónov alebo možno máte veľmi starý počítač. Preto má každý inú šírku pásma siete.
Preto bola vyvinutá technológia TCP Windowing, kedy prenos dát začína nízkou rýchlosťou alebo s prenosom minimálneho počtu paketov, čím sa postupne zvyšuje prevádzkové „okno“. Pošlete jeden paket, 5 paketov, 10 paketov, 1000 paketov, 10000 XNUMX paketov a pomaly otvárate to okno viac a viac, až kým „otvorenie“ nedosiahne maximálny možný objem prevádzky odoslanej v určitom časovom období. Koncept Windowing je teda súčasťou fungovania protokolu TCP.
Ďalej sa pozrieme na najbežnejšie čísla portov. Klasická situácia je, keď máte 1 hlavný server, možno dátové centrum. Zahŕňa súborový server, webový server, poštový server a DHCP server. Ak teraz jeden z klientskych počítačov kontaktuje dátové centrum, ktoré sa nachádza v strede obrázku, začne odosielať návštevnosť súborového servera na klientske zariadenia. Táto prevádzka je zobrazená červenou farbou a bude prenášaná na konkrétnom porte pre konkrétnu aplikáciu z konkrétneho servera.
Ako server vedel, kam by mala smerovať určitá návštevnosť? Dozvie sa to z čísla cieľového portu. Ak sa pozriete na rámec, uvidíte, že v každom prenose dát je zmienka o čísle cieľového portu a čísle zdrojového portu. Môžete vidieť, že modrá a červená prevádzka a modrá prevádzka je prevádzka webového servera, obe smerujú na rovnaký fyzický server, ktorý má nainštalované rôzne servery. Ak ide o dátové centrum, potom používa virtuálne servery. Ako teda vedeli, že červená prevádzka sa mala vrátiť na ten ľavý notebook s touto IP adresou? Vedia to vďaka číslam portov. Ak sa pozriete na článok Wikipédie „Zoznam portov TCP a UDP“, uvidíte, že sú v ňom uvedené všetky štandardné čísla portov.
Ak rolujete na tejto stránke nadol, uvidíte, aký veľký je tento zoznam. Obsahuje približne 61 000 čísel. Čísla portov od 1 do 1024 sú známe ako najbežnejšie čísla portov. Napríklad port 21/TCP je na odosielanie ftp príkazov, port 22 je pre ssh, port 23 je pre Telnet, teda pre odosielanie nešifrovaných správ. Veľmi populárny port 80 prenáša dáta cez HTTP, zatiaľ čo port 443 prenáša šifrované dáta cez HTTPS, čo je obdoba bezpečnej verzie HTTP.
Niektoré porty sú vyhradené pre TCP aj UDP a niektoré vykonávajú rôzne úlohy v závislosti od toho, či je pripojenie TCP alebo UDP. Oficiálne sa teda pre HTTP používa TCP port 80 a pre HTTP sa neoficiálne používa UDP port 80, ale pod iným protokolom HTTP - QUIC.
Preto čísla portov v TCP nie sú vždy určené na to, aby robili to isté ako v UDP. Tento zoznam sa nemusíte učiť naspamäť, je nemožné si ho zapamätať, ale musíte poznať niektoré obľúbené a najbežnejšie čísla portov. Ako som povedal, niektoré z týchto portov majú oficiálny účel, ktorý je popísaný v štandardoch a niektoré majú neoficiálny účel, ako je to v prípade Chromia.
V tejto tabuľke sú uvedené všetky bežné čísla portov a tieto čísla sa používajú na odosielanie a prijímanie prenosu pri používaní konkrétnych aplikácií.
Teraz sa pozrime na to, ako sa údaje presúvajú v sieti na základe toho mála informácií, ktoré poznáme. Povedzme, že počítač 10.1.1.10 chce kontaktovať tento počítač alebo tento server, ktorý má adresu 30.1.1.10. Pod IP adresou každého zariadenia je jeho MAC adresa. Uvádzam príklad MAC adresy len s poslednými 4 znakmi, ale v praxi je to 48-bitové hexadecimálne číslo s 12 znakmi. Keďže každé z týchto čísel pozostáva zo 4 bitov, 12 hexadecimálnych číslic predstavuje 48-bitové číslo.
Ako vieme, ak chce toto zariadenie kontaktovať tento server, najprv musí byť vykonaný prvý krok 3-cestného handshake, teda odoslanie paketu SYN. Po zadaní tejto požiadavky počítač 10.1.1.10 určí číslo zdrojového portu, ktoré systém Windows dynamicky vytvorí. Windows náhodne vyberie číslo portu medzi 1 a 65,000 1. Ale keďže počiatočné čísla v rozsahu 1024 až 25000 sú všeobecne známe, v tomto prípade systém vezme do úvahy čísla väčšie ako 25113 XNUMX a vytvorí náhodný zdrojový port, napríklad číslo XNUMX.
Ďalej systém pridá do paketu cieľový port, v tomto prípade je to port 21, pretože aplikácia, ktorá sa pokúša pripojiť k tomuto FTP serveru vie, že má posielať FTP prenos.
Ďalej náš počítač hovorí: "Dobre, moja IP adresa je 10.1.1.10 a potrebujem kontaktovať IP adresu 30.1.1.10." Obe tieto adresy sú tiež zahrnuté v pakete, aby vytvorili požiadavku SYN a tento paket sa nezmení až do konca spojenia.
Chcem, aby ste z tohto videa pochopili, ako sa dáta presúvajú v sieti. Keď náš počítač odosielajúci požiadavku vidí zdrojovú IP adresu a cieľovú IP adresu, chápe, že cieľová adresa nie je v danej lokálnej sieti. Zabudol som povedať, že toto je všetko /24 IP adries. Ak sa teda pozriete na /24 IP adries, zistíte, že počítače 10.1.1.10 a 30.1.1.10 nie sú v rovnakej sieti. Počítač odosielajúci požiadavku teda chápe, že na opustenie tejto siete musí kontaktovať bránu 10.1.1.1, ktorá je nakonfigurovaná na jednom z rozhraní smerovača. Vie, že má ísť na 10.1.1.1 a pozná svoju MAC adresu 1111, ale nepozná MAC adresu brány 10.1.1.1. Čo robí? Odošle broadcast ARP požiadavku, ktorú dostanú všetky zariadenia v sieti, no odpovie na ňu iba router s IP adresou 10.1.1.1.
Smerovač odpovie svojou AAAA MAC adresou a do tohto rámca sa umiestnia aj zdrojová aj cieľová MAC adresa. Keď je rámec pripravený, pred opustením siete sa vykoná kontrola integrity dát CRC, čo je algoritmus na nájdenie kontrolného súčtu na zistenie chýb.
Cyklická redundancia CRC znamená, že celý tento rámec, od SYN po poslednú MAC adresu, je spustený cez hašovací algoritmus, povedzme MD5, výsledkom čoho je hašovacia hodnota. Hodnota hash alebo kontrolný súčet MD5 sa potom umiestni na začiatok rámca.
Označil som to FCS/CRC, pretože FCS je sekvencia kontroly snímok, štvorbajtová hodnota CRC. Niekto používa označenie FCS a niekto označenie CRC, preto som zahrnul obe označenia. Ale v podstate je to len hash hodnota. Je potrebné zabezpečiť, aby všetky dáta prijaté cez sieť neobsahovali chyby. Preto, keď sa tento rámec dostane k smerovaču, prvá vec, ktorú smerovač urobí, je, že vypočíta samotný kontrolný súčet a porovná ho s hodnotou FCS alebo CRC, ktorú obsahuje prijatý rámec. Takto môže skontrolovať, či dáta prijaté cez sieť neobsahujú chyby, po čom odstráni kontrolný súčet z rámca.
Potom sa smerovač pozrie na adresu MAC a povie: „Dobre, adresa MAC AAAA znamená, že rámec je adresovaný mne,“ a vymaže časť rámca, ktorá obsahuje adresy MAC.
Pri pohľade na cieľovú IP adresu 30.1.1.10 pochopí, že tento paket nie je adresovaný jemu a musí ísť ďalej cez router.
Teraz si router „myslí“, že potrebuje vidieť, kde sa nachádza sieť s adresou 30.1.1.10. Ešte sme neprebrali celý koncept smerovania, ale vieme, že smerovače majú smerovaciu tabuľku. Táto tabuľka obsahuje položku pre sieť s adresou 30.1.1.0. Ako si pamätáte, nejde o IP adresu hostiteľa, ale o sieťový identifikátor. Smerovač si bude „myslieť“, že môže dosiahnuť adresu 30.1.1.0/24 prechodom cez smerovač 20.1.1.2.
Môžete sa opýtať, ako to vie? Len majte na pamäti, že to bude vedieť buď zo smerovacích protokolov alebo z vašich nastavení, ak ste ako správca nakonfigurovali statickú cestu. Ale v každom prípade smerovacia tabuľka tohto smerovača obsahuje správnu položku, takže vie, že má poslať tento paket 20.1.1.2. Za predpokladu, že router už pozná cieľovú MAC adresu, budeme jednoducho pokračovať v preposielaní paketu. Ak túto adresu nepozná, znova spustí ARP, dostane MAC adresu smerovača 20.1.1.2 a proces odosielania rámca bude znova pokračovať.
Takže predpokladáme, že už pozná MAC adresu, potom budeme mať zdrojovú MAC adresu BBB a cieľovú MAC adresu CCC. Smerovač opäť vypočíta FCS/CRC a umiestni ho na začiatok rámca.
Potom odošle tento rámec cez sieť, rámec dosiahne smerovač 20.1.12, skontroluje kontrolný súčet, uistí sa, že dáta nie sú poškodené a vymaže FCS/CRC. Potom "skráti" MAC adresy, pozrie sa na cieľ a vidí, že je 30.1.1.10. Vie, že táto adresa je pripojená k jeho rozhraniu. Rovnaký proces vytvárania rámca sa opakuje, router pridá hodnoty zdrojovej a cieľovej MAC adresy, vykoná hashovanie, pripojí hash k rámcu a odošle ho cez sieť.
Náš server po prijatí žiadosti SYN, ktorá je mu adresovaná, skontroluje kontrolný súčet hash a ak paket neobsahuje chyby, hash vymaže. Potom odstráni MAC adresy, pozrie sa na IP adresu a uvedomí si, že tento paket je adresovaný jemu.
Potom skráti adresy IP súvisiace s treťou vrstvou modelu OSI a pozrie sa na čísla portov.
Vidí port 21, čo znamená FTP prevádzku, vidí SYN, a preto chápe, že sa s ním niekto pokúša komunikovať.
Teraz, na základe toho, čo sme sa dozvedeli o handshake, server 30.1.1.10 vytvorí paket SYN/ACK a odošle ho späť do počítača 10.1.1.10. Po prijatí tohto paketu zariadenie 10.1.1.10 vytvorí ACK, odošle ho cez sieť rovnakým spôsobom ako SYN paket a po prijatí ACK serverom sa vytvorí spojenie.
Jedna vec, ktorú by ste mali vedieť, je, že toto všetko sa deje za menej ako sekundu. Ide o veľmi, veľmi rýchly proces, ktorý som sa snažil spomaliť, aby vám bolo všetko jasné.
Dúfam, že to, čo ste sa naučili v tomto návode, bude pre vás užitočné. Ak máte nejaké otázky, napíšte mi na [chránené e-mailom] alebo zanechajte otázky pod týmto videom.
Počnúc ďalšou lekciou vyberiem 3 najzaujímavejšie otázky z YouTube, ktoré si zopakujem na konci každého videa. Odteraz budem mať sekciu „Najčastejšie otázky“, takže zverejním otázku spolu s vaším menom a odpoviem na ňu naživo. Myslím, že to bude prospešné.
Ďakujeme, že ste zostali s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavého obsahu? Podporte nás zadaním objednávky alebo odporučením priateľom, 30% zľava pre užívateľov Habr na unikátny analóg serverov základnej úrovne, ktorý sme pre vás vymysleli: (k dispozícii s RAID1 a RAID10, až 24 jadier a až 40 GB DDR4).
VPS (KVM) E5-2650 v4 (6 jadier) 10 GB DDR4 240 GB SSD 1 Gb/s zadarmo do leta pri platbe na obdobie šiestich mesiacov si môžete objednať .
Dell R730xd 2 krát lacnejší? Len tu v Holandsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 USD! Čítať o
Zdroj: hab.com