Než se pustíme do dnešního videonávodu, chci poděkovat všem, kteří přispěli k popularitě mého kurzu na YouTube. Když jsem to asi před 8 měsíci zakládal, nečekal jsem takový úspěch – dnes si mé lekce prohlédlo 312724 11208 lidí, já mám 7 6 odběratelů. Ani ve snu by mě nenapadlo, že tento skromný začátek dosáhne takových výšin. Ale neztrácejme čas a pojďme rovnou k dnešní lekci. Dnes doplníme mezery, které nastaly v posledních 3 video lekcích. Přestože je dnes teprve 3. den, XNUMX. den byl rozdělen do XNUMX videolekcí, takže dnes se vlastně podíváte na osmou videolekci.
Dnes se budeme věnovat 3 důležitým tématům: DHCP, transport TCP a nejběžnější čísla portů. O IP adresách jsme již mluvili a jedním z nejdůležitějších faktorů při konfiguraci IP adresy je DHCP.
DHCP je zkratka pro Dynamic Host Configuration Protocol a je to protokol, který pomáhá dynamicky konfigurovat IP adresy pro hostitele. Takže jsme všichni viděli toto okno. Když kliknete na možnost „Získat adresu IP automaticky“, počítač vyhledá server DHCP, který je nakonfigurován ve stejné podsíti, a odesílá různé pakety a požadavky na adresu IP. Protokol DHCP má 6 zpráv, z nichž 4 jsou kritické pro přidělení IP adresy.
První zpráva je zpráva DHCP DISCOVERY. Zpráva zjišťování DHCP je podobná uvítací zprávě. Když se nové zařízení připojí k síti, zeptá se, zda je v síti DHCP server.
To, co vidíte na snímku, vypadá jako požadavek na vysílání, kdy zařízení kontaktuje všechna zařízení v síti a hledá server DHCP. Jak jsem řekl, toto je požadavek na vysílání, takže ho slyší všechna zařízení v síti.
Pokud je v síti DHCP server, odešle paket - nabídka DHCP NABÍDKA. Návrh znamená, že server DHCP v reakci na požadavek zjišťování odešle klientovi konfiguraci a požádá klienta, aby přijal konkrétní IP adresu.
DHCP server rezervuje IP adresu, v tomto případě 192.168.1.2, neposkytne ji, ale rezervuje tuto adresu pro zařízení. Zároveň nabídkový balíček obsahuje vlastní IP adresu DHCP serveru.
Pokud je v této síti více než jeden server DHCP, jiný server DHCP mu po přijetí požadavku na vysílání klienta nabídne také svou IP adresu, například 192.168.1.50. Není obvyklé mít dva různé servery DHCP konfigurované ve stejné síti, ale někdy se to stane. Když je tedy klientovi zaslána nabídka DHCP, obdrží 2 nabídky DHCP a nyní se musí rozhodnout, kterou nabídku DHCP chce přijmout.
Předpokládejme, že klient přijme první aplikaci. To znamená, že klient odešle požadavek DHCP REQUEST, který doslova říká "Přijímám IP adresu 192.168.1.2 nabízenou serverem DHCP 192.168.1.1."
Po obdržení požadavku server DHCP 192.168.1.1 odpoví „dobře, uznávám“, to znamená, že potvrdí požadavek a odešle toto DHCP ACK klientovi. Pamatujeme si však, že jiný server DHCP rezervoval pro klienta IP adresu 1.50. Jakmile obdrží požadavek klienta na vysílání, bude vědět o selhání a vloží tuto IP adresu zpět do fondu, aby ji mohl přiřadit jinému klientovi, pokud obdrží další požadavek.
Toto jsou 4 kritické zprávy, které si DHCP vyměňuje při přidělování IP adres. Dále má DHCP 2 další informační zprávy. Informační zpráva je vydána klientem, pokud vyžaduje více informací, než které obdržel v klauzuli DHCP OFFER ve druhém kroku. Pokud server neposkytl dostatek informací v nabídce DHCP nebo pokud klient potřebuje více informací, než jaké byly obsaženy v paketu nabídky, vyžádá si další informace DHCP. Je zde ještě jedna zpráva, kterou klient posílá na server - toto je DHCP RELEASE. Informuje vás, že klient chce uvolnit svou stávající IP adresu.
Nejčastěji se však stává, že se uživatel odpojí od sítě dříve, než má klient čas odeslat serveru DHCP RELEASE. To se stane, když vypnete počítač, což děláme my. V tomto případě síťový klient nebo počítač jednoduše nemá čas informovat server, aby uvolnil použitou adresu, takže RELEASE DHCP není povinným krokem. Požadované kroky k získání IP adresy jsou: zjišťování DHCP, nabídka DHCP, požadavek DHCP a handshake DHCP.
V jedné z příštích lekcí vám řeknu, jak konfigurujeme server DHCP při vytváření fondu DNCP. Sdružováním rozumíme, že serveru sdělíte, aby přidělil IP adresy v rozsahu 192.168.1.1 až 192.168.1.254. Server DHCP tedy vytvoří fond, umístí do něj 254 IP adres a bude moci přidělovat adresy klientům v síti pouze z tohoto fondu. Jedná se tedy o něco jako administrativní nastavení, které může provést uživatel.
Nyní se podíváme na přenos TCP. Nevím, jestli znáte ten "telefon" na obrázku, ale když jsme byli malí, používali jsme ke vzájemné komunikaci tyto plechovky spojené provázkem.
Takový „luxus“ si dnešní generace bohužel nemůže dovolit. Myslím tím, že dnes jsou děti u televize od jednoho roku, hrají PSP a možná je to diskutabilní, ale myslím, že jsme měli nejlepší dětství, vlastně jsme chodili ven a hráli hry a dnešní děti se nedají odtáhnout od pohovky .
Synovi je teprve rok a už vidím, že je na iPadu závislý, tedy ještě hodně malý, ale myslím, že dnešní děti se už rodí s tím, že umí zacházet s elektronickými vychytávkami. Tak jsem chtěl říct, že když jsme si jako děti hráli, dělali jsme dírky do plechovek, a když jsme je svázali provázkem a řekli něco do jedné plechovky, tak na druhém konci ten člověk slyšel, co se říká k němu jednoduše přiložením plechovky k uchu . Je to tedy velmi podobné síťovému připojení.
Dnes i přenosy TCP musí mít spojení, které musí být navázáno před zahájením samotného přenosu dat. Jak jsme probrali v předchozích lekcích, TCP je spojově orientovaný přenos, zatímco UDP je spojově orientovaný přenos. Dalo by se říct, že UDP je místo, kam hodím míček a je jen na vás, jestli ho dokážete chytit. Ať už jste připraveni to udělat nebo ne, není můj problém, prostě ho opustím.
TCP je spíš tak, že mluvíte s chlapem a předem ho varujete, že budete házet míčem, takže si vytvoříte vazbu a pak hodíte míč tak, aby byl váš partner spíše připraven ho chytit. Takže TCP ve skutečnosti vytvoří spojení a poté začne provádět skutečný přenos.
Podívejme se, jak takové spojení vytváří. Tento protokol používá k vytvoření spojení třícestný handshake. Toto není příliš odborný termín, ale již dlouho se používá k popisu TCP spojení. Odesílající zařízení zahájí třícestný handshake, přičemž klient odešle na server paket s příznakem SYN.
Řekněme, že dívka v popředí, jejíž obličej vidíme, je zařízení A, a dívka v pozadí, jejíž obličej není vidět, je zařízení B. Dívka A pošle paket SYN dívce B a ona říká: "Skvělé, kdo- tak se mnou chce komunikovat." Takže musím odpovědět, že jsem připraven komunikovat!" Jak to udělat? Dalo by se jednoduše poslat zpět další paket SYN a pak ACK indikující přijetí původního paketu SYN. Namísto samostatného odesílání ACK vytvoří server společný paket obsahující SYN a ACK a přenese jej po síti.
V tomto okamžiku tedy zařízení A odeslalo paket SYN a přijalo zpět paket SYN/ACK. Nyní musí zařízení A odeslat zařízení B ACK paket, to znamená potvrdit, že obdrželo souhlas od zařízení B k navázání komunikace. Obě zařízení tedy přijala pakety SYN a ACK a nyní můžeme říci, že spojení bylo navázáno, to znamená, že byl dokončen 3-stupňový handshake pomocí protokolu TCP.
Dále se podíváme na technologii TCP Windowing. Jednoduše řečeno, je to metoda používaná v TCP/IP k vyjednávání schopností odesílatele a příjemce.
Řekněme, že se ve Windows pokoušíme přenést velký soubor, řekněme o velikosti 2 GB, z jednoho disku na druhý. Hned na začátku přenosu nás systém informuje, že přenos souboru bude trvat přibližně 1 rok. Ale o pár sekund později se systém sám opraví a řekne: "Oh, počkejte chvíli, myslím, že to bude trvat asi 6 měsíců, ne rok." Uplyne ještě trochu času a Windows řeknou: „Myslím, že bych mohl být schopen přenést soubor za 1 měsíc.“ Poté bude následovat zpráva „1 den“, „6 hodin“, „3 hodiny“, „1 hodina“, „20 minut“, „10 minut“, „3 minuty“. Ve skutečnosti bude celý proces přenosu souborů trvat pouze 3 minuty. Jak se to stalo? Zpočátku, když se vaše zařízení pokouší komunikovat s jiným zařízením, odešle jeden paket a čeká na potvrzení. Pokud zařízení čeká na potvrzení dlouho, myslí si: „Pokud budu muset přenést 2 GB dat touto rychlostí, bude to trvat asi 2 roky.“ Po nějaké době vaše zařízení obdrží ACK a myslí si: „Dobře, poslal jsem jeden paket a obdržel jsem ACK, takže příjemce může přijmout 1 paket. Teď mu zkusím poslat 10 balíčků místo jednoho." Odesílatel odešle 10 paketů a po nějaké době obdrží od přijímajícího zařízení potvrzení ACK, což znamená, že příjemce čeká na další, 11. paket. Odesílatel si myslí: „Super, protože příjemce zpracoval 10 paketů najednou, teď mu zkusím poslat 100 paketů místo deseti.“ Odešle 100 paketů a příjemce odpoví, že je přijal a nyní čeká na 101 paketů. Postupem času se tedy počet přenášených paketů zvyšuje.
To je důvod, proč vidíte rychlý pokles doby kopírování souboru ve srovnání s tím, co bylo původně uvedeno - je to způsobeno zvýšenou schopností přenášet velké množství dat. Nastává však bod, kdy další zvyšování objemu přenosu nebude možné. Řekněme, že jste odeslali 10000 9000 paketů, ale vyrovnávací paměť zařízení přijímače může přijmout pouze 9000 9001. V tomto případě příjemce odešle ACK se zprávou: „Přijal jsem 9000 9000 paketů a nyní jsem připraven přijmout 9000 3“. Odesílatel z toho usuzuje, že vyrovnávací paměť přijímacího zařízení má kapacitu pouze XNUMX, což znamená, že od této chvíle neposílám více než XNUMX paketů najednou. V tomto případě odesílatel rychle vypočítá čas, který mu zabere přenos zbývajícího množství dat po částech XNUMX paketů, a poskytne XNUMX minuty. Tyto tři minuty jsou skutečná doba přenosu. To je to, co TCP Windowing dělá.
Toto je jeden z těch mechanismů omezení provozu, kdy odesílající zařízení nakonec pochopí, jaká je skutečná kapacita sítě. Možná se ptáte, proč se nemohou předem dohodnout, jakou kapacitu má přijímací zařízení? Faktem je, že je to technicky nemožné, protože v síti jsou různé typy zařízení. Řekněme, že máte iPad a ten má jinou rychlost přenosu/přijímání dat než iPhone, můžete mít různé typy telefonů nebo možná máte hodně starý počítač. Proto má každý jinou šířku pásma sítě.
Proto byla vyvinuta technologie TCP Windowing, kdy přenos dat začíná nízkou rychlostí nebo s přenosem minimálního počtu paketů, postupně se zvětšuje provozní „okno“. Odešlete jeden paket, 5 paketů, 10 paketů, 1000 paketů, 10000 XNUMX paketů a pomalu to okno otevíráte víc a víc, dokud „otevření“ nedosáhne maximálního možného objemu provozu odeslaného v určitém časovém období. Koncept Windowing je tedy součástí fungování protokolu TCP.
Dále se podíváme na nejběžnější čísla portů. Klasická situace je, když máte 1 hlavní server, třeba datové centrum. Zahrnuje souborový server, webový server, poštovní server a DHCP server. Nyní, pokud jeden z klientských počítačů kontaktuje datové centrum, které se nachází uprostřed obrázku, začne odesílat provoz souborového serveru na klientská zařízení. Tento provoz je zobrazen červeně a bude přenášen na konkrétním portu pro konkrétní aplikaci z konkrétního serveru.
Jak server věděl, kam by měl jít určitý provoz? Dozví se to z čísla cílového portu. Pokud se podíváte na rámec, uvidíte, že v každém datovém přenosu je zmínka o čísle cílového portu a čísle zdrojového portu. Můžete vidět, že modrý a červený provoz a modrý provoz je provoz webového serveru, oba jdou na stejný fyzický server, který má nainstalované různé servery. Pokud se jedná o datové centrum, pak používá virtuální servery. Jak tedy věděli, že červený provoz se měl vrátit do toho levého notebooku s touto IP adresou? Vědí to díky číslům portů. Pokud se podíváte na článek Wikipedie „Seznam portů TCP a UDP“, uvidíte, že obsahuje všechna standardní čísla portů.
Pokud rolujete na této stránce dolů, můžete vidět, jak velký je tento seznam. Obsahuje přibližně 61 000 čísel. Čísla portů od 1 do 1024 jsou známá jako nejběžnější čísla portů. Například port 21/TCP je určen pro odesílání ftp příkazů, port 22 pro ssh, port 23 pro Telnet, tedy pro odesílání nešifrovaných zpráv. Velmi oblíbený port 80 slouží k přenosu dat pomocí protokolu HTTP, port 443 pak k přenosu šifrovaných dat pomocí protokolu HTTPS, což je obdoba zabezpečené verze HTTP.
Některé porty jsou vyhrazeny pro TCP i UDP a některé provádějí různé úkoly v závislosti na tom, zda je připojení TCP nebo UDP. Oficiálně se tedy pro HTTP používá TCP port 80 a pro HTTP se neoficiálně používá UDP port 80, ale pod jiným protokolem HTTP - QUIC.
Proto čísla portů v TCP nejsou vždy určena ke stejnému účelu jako v UDP. Tento seznam se nemusíte učit nazpaměť, je nemožné si ho zapamatovat, ale potřebujete znát některá oblíbená a nejběžnější čísla portů. Jak jsem řekl, některé z těchto portů mají oficiální účel, který je popsán ve standardech, a některé mají neoficiální účel, jako je tomu u Chromia.
V této tabulce jsou uvedena všechna běžná čísla portů a tato čísla se používají k odesílání a přijímání provozu při používání konkrétních aplikací.
Nyní se podívejme, jak se data přesouvají po síti na základě toho mála informací, které víme. Řekněme, že počítač 10.1.1.10 chce kontaktovat tento počítač nebo tento server, který má adresu 30.1.1.10. Pod IP adresou každého zařízení je jeho MAC adresa. Uvádím příklad MAC adresy pouze s posledními 4 znaky, ale v praxi se jedná o 48bitové hexadecimální číslo s 12 znaky. Protože každé z těchto čísel se skládá ze 4 bitů, 12 hexadecimálních číslic představuje 48bitové číslo.
Jak víme, pokud chce toto zařízení kontaktovat tento server, musí být nejprve proveden první krok 3-cestného handshake, tedy odeslání SYN paketu. Když je tento požadavek podán, počítač 10.1.1.10 určí číslo zdrojového portu, které systém Windows dynamicky vytvoří. Windows náhodně vybere číslo portu mezi 1 a 65,000 1. Ale protože počáteční čísla v rozsahu 1024 až 25000 jsou široce známá, v tomto případě systém vezme v úvahu čísla větší než 25113 XNUMX a vytvoří náhodný zdrojový port, například číslo XNUMX.
Dále systém do paketu přidá cílový port, v tomto případě je to port 21, protože aplikace, která se pokouší připojit k tomuto FTP serveru, ví, že by měla odesílat FTP provoz.
Dále náš počítač říká: "Dobře, moje IP adresa je 10.1.1.10 a potřebuji kontaktovat IP adresu 30.1.1.10." Obě tyto adresy jsou také zahrnuty v paketu pro vytvoření požadavku SYN a tento paket se nezmění až do konce spojení.
Chci, abyste z tohoto videa pochopili, jak se data přesouvají po síti. Když náš počítač odesílající požadavek uvidí zdrojovou IP adresu a cílovou IP adresu, pochopí, že cílová adresa není v této místní síti. Zapomněl jsem říct, že toto jsou všechny /24 IP adresy. Když se tedy podíváte na /24 IP adresy, uvědomíte si, že počítače 10.1.1.10 a 30.1.1.10 nejsou ve stejné síti. Počítač odesílající požadavek tedy chápe, že aby mohl opustit tuto síť, musí kontaktovat bránu 10.1.1.1, která je nakonfigurována na jednom z rozhraní routeru. Ví, že má přejít na 10.1.1.1 a zná její MAC adresu 1111, ale nezná MAC adresu brány 10.1.1.1. Co dělá? Odešle broadcast ARP požadavek, který obdrží všechna zařízení v síti, ale odpoví na něj pouze router s IP adresou 10.1.1.1.
Router odpoví svou MAC adresou AAAA a do tohoto rámce budou také umístěny zdrojové i cílové MAC adresy. Jakmile je rámec připraven, bude před opuštěním sítě provedena kontrola integrity dat CRC, což je algoritmus pro nalezení kontrolního součtu pro detekci chyb.
Cyklická redundance CRC znamená, že celý tento rámec, od SYN po poslední MAC adresu, prochází algoritmem hash, řekněme MD5, což má za následek hodnotu hash. Hodnota hash neboli kontrolní součet MD5 je pak umístěna na začátek rámce.
Označil jsem to FCS/CRC, protože FCS je sekvence kontroly snímků, čtyřbajtová hodnota CRC. Někdo používá označení FCS a někdo označení CRC, takže jsem zahrnul obě označení. Ale v podstatě je to jen hash hodnota. Je potřeba zajistit, aby všechna data přijatá přes síť neobsahovala chyby. Jakmile tedy tento rámec dorazí k routeru, první věc, kterou router udělá, je, že sám vypočítá kontrolní součet a porovná jej s hodnotou FCS nebo CRC, kterou přijatý rámec obsahuje. Takto může zkontrolovat, zda data přijatá přes síť neobsahují chyby, načež kontrolní součet z rámce odstraní.
Dále se router podívá na MAC adresu a řekne: „Dobře, MAC adresa AAAA znamená, že rámec je adresován mně,“ a odstraní část rámce obsahující MAC adresy.
Při pohledu na cílovou IP adresu 30.1.1.10 pochopí, že tento paket není adresován jemu a musí jít dále přes router.
Nyní si router „myslí“, že potřebuje vidět, kde se nachází síť s adresou 30.1.1.10. Ještě jsme nepokryli úplný koncept směrování, ale víme, že směrovače mají směrovací tabulku. Tato tabulka obsahuje položku pro síť s adresou 30.1.1.0. Jak si pamatujete, nejedná se o IP adresu hostitele, ale o síťový identifikátor. Router si „myslí“, že může dosáhnout adresy 30.1.1.0/24 tím, že projde routerem 20.1.1.2.
Můžete se ptát, jak to ví? Jen mějte na paměti, že to bude vědět buď ze směrovacích protokolů, nebo z vašeho nastavení, pokud jste jako správce nakonfigurovali statickou cestu. Ale v každém případě směrovací tabulka tohoto routeru obsahuje správnou položku, takže ví, že má poslat tento paket 20.1.1.2. Za předpokladu, že router již zná cílovou MAC adresu, budeme jednoduše pokračovat v přeposílání paketu. Pokud tuto adresu nezná, znovu spustí ARP, obdrží MAC adresu routeru 20.1.1.2 a proces odesílání rámce bude znovu pokračovat.
Předpokládáme tedy, že již zná MAC adresu, pak budeme mít zdrojovou MAC adresu BBB a cílovou MAC adresu CCC. Router opět vypočítá FCS/CRC a umístí jej na začátek rámce.
Poté odešle tento rámec přes síť, rámec dosáhne routeru 20.1.12, zkontroluje kontrolní součet, ujistí se, že data nejsou poškozena, a vymaže FCS/CRC. Poté "zkrátí" MAC adresy, podívá se na cíl a vidí, že je 30.1.1.10. Ví, že tato adresa je připojena k jeho rozhraní. Opakuje se stejný proces vytváření rámce, router přidá zdrojové a cílové hodnoty MAC adresy, provede hash, připojí hash k rámci a odešle ho po síti.
Náš server poté, co konečně obdrží požadavek SYN, který je mu adresován, zkontroluje kontrolní součet hash, a pokud paket neobsahuje chyby, hash smaže. Poté odstraní MAC adresy, podívá se na IP adresu a uvědomí si, že tento paket je adresován jemu.
Poté zkrátí IP adresy související s třetí vrstvou modelu OSI a podívá se na čísla portů.
Vidí port 21, což znamená provoz FTP, vidí SYN, a proto chápe, že se s ním někdo pokouší komunikovat.
Nyní, na základě toho, co jsme se dozvěděli o handshake, server 30.1.1.10 vytvoří paket SYN/ACK a odešle jej zpět do počítače 10.1.1.10. Po přijetí tohoto paketu zařízení 10.1.1.10 vytvoří ACK, předá jej sítí stejným způsobem jako SYN paket a poté, co server přijme ACK, dojde k navázání spojení.
Jedna věc, kterou byste měli vědět, je, že to vše se děje za méně než sekundu. Jedná se o velmi, velmi rychlý proces, který jsem se snažil zpomalit, aby vám bylo vše jasné.
Doufám, že to, co jste se naučili v tomto tutoriálu, bude pro vás užitečné. Pokud máte nějaké dotazy, napište mi prosím na [chráněno e-mailem] nebo zanechte otázky pod tímto videem.
Počínaje další lekcí vyberu 3 nejzajímavější otázky z YouTube, které si zopakuji na konci každého videa. Od nynějška budu mít sekci "Top Questions", takže zveřejním otázku spolu s vaším jménem a odpovím na ni živě. Myslím, že to bude přínosné.
Děkujeme, že s námi zůstáváte. Líbí se vám naše články? Chcete vidět více zajímavého obsahu? Podpořte nás objednávkou nebo doporučením přátelům, 30% sleva pro uživatele Habr na unikátní obdobu entry-level serverů, kterou jsme pro vás vymysleli: (k dispozici s RAID1 a RAID10, až 24 jader a až 40 GB DDR4).
VPS (KVM) E5-2650 v4 (6 jader) 10 GB DDR4 240 GB SSD 1 Gb/s zdarma do léta při platbě na dobu šesti měsíců si můžete objednat .
Dell R730xd 2x levnější? Pouze zde V Nizozemsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 $! Číst o
Zdroj: www.habr.com