Преди да започнем днешния видео урок, искам да благодаря на всички, които допринесоха за популярността на моя курс в YouTube. Когато го започнах преди около 8 месеца, не очаквах такъв успех - днес 312724 души са гледали уроците ми, имам 11208 абонати. Никога не съм мечтал, че това скромно начинание ще достигне такива висоти. Но нека не губим време и веднага да преминем към днешния урок. Днес ще попълним пропуските, които се случиха в последните 7 видео урока. Въпреки че днес е само ден 6, ден 3 е разделен на 3 видео урока, така че всъщност ще гледате осмия видео урок днес.
Днес ще разгледаме 3 важни теми: DHCP, TCP пренасочване и най-често използваните номера на портове. Вече говорихме за IP адресите и един от най-важните фактори в конфигурацията на IP адресите е DHCP.
DHCP означава „Dynamic Host Configuration Protocol“ и е протокол, който помага за динамично конфигуриране на IP адреси за хостове. И така, всички видяхме този прозорец. Когато щракнете върху опцията „получаване на IP адрес автоматично“, компютърът търси DHCP сървър, конфигуриран в същата подмрежа, и изпраща различни пакети и заявки за IP адреса. DHCP протоколът има 6 съобщения, от които 4 са критични за присвояване на IP адрес.
Първото съобщение е DHCP DISCOVERY съобщение. Съобщението за откриване на DHCP е подобно на здравей. Когато ново устройство се присъедини към мрежата, то пита дали има DHCP сървър в мрежата.
Това, което виждате на слайда, изглежда като заявка за излъчване, когато устройството се свързва с всички устройства в мрежата в търсене на DHCP сървър. Както казах, това е заявка за излъчване, така че всички устройства в мрежата я чуват.
Ако в мрежата има DHCP сървър, той изпраща пакет - DHCP ОФЕРТА. Оферта означава, че DHCP сървърът, в отговор на заявка за откриване, изпраща конфигурация на клиента, подканвайки клиента да приеме конкретен IP адрес.
DHCP сървърът запазва IP адрес, в този случай 192.168.1.2, не предоставя, а по-скоро запазва този адрес за устройството. Освен това пакетът с оферта съдържа собствения IP адрес на DHCP сървъра.
Ако има повече от един DHCP сървър в тази мрежа, друг DHCP сървър, при получаване на заявката за излъчване на клиента, също ще предложи свой собствен IP адрес, например 192.168.1.50. Обикновено два различни DHCP сървъра не са конфигурирани в една и съща мрежа, но понякога това се случва. Така че, когато DHCP оферта е изпратена до клиент, той получава 2 DHCP оферти и сега трябва да реши коя DHCP оферта иска да приеме.
Да приемем, че клиентът приема първото приложение. Това означава, че клиентът изпраща DHCP REQUEST, което буквално казва „Приемам IP адреса 192.168.1.2, предложен от DHCP сървъра 192.168.1.1“.
При получаване на заявката DHCP сървърът 192.168.1.1 отговаря "OK, I'll admit it", т.е. потвърждава заявката и изпраща това DHCP ACK на клиента. Но помним, че друг DHCP сървър DHCP запази IP адрес 1.50 за клиента. При получаване на заявката за излъчване на клиента, той ще разбере за отхвърлянето и ще постави този IP адрес обратно в пула, така че да може да го присвои на друг клиент, ако получи друга заявка.
Това са 4-те критични съобщения, обменени от DHCP в началото на присвояването на IP адрес. Освен това DHCP има още 2 информационни съобщения. Информационно съобщение се издава от клиента, ако се нуждае от повече информация, отколкото е получила в DHCP ОФЕРТАТА във втората стъпка. Ако DHCP сървърът е предоставил недостатъчна информация в DHCP офертата или ако клиентът се нуждае от повече информация от тази, която се съдържа в пакета с оферта, той изисква допълнителна DHCP информация. Има още едно съобщение, което клиентът изпраща на сървъра - това е DHCP RELEASE. Пише, че клиентът иска да освободи IP адреса, който има.
Най-често обаче се случва потребителят да бъде изключен от мрежата, преди клиентът да има време да изпрати DHCP RELEASE на сървъра. Това се случва, когато изключите компютъра, което извършваме с вас. В този случай мрежовият клиент или компютърът просто няма време да каже на сървъра да освободи използвания адрес, така че DHCP RELEASE не е задължителна стъпка. Задължителните стъпки за получаване на IP адрес са: DHCP откриване, DHCP оферта, DHCP заявка и DHCP ръкостискане.
В един от следващите уроци ще обясня как конфигурираме DHCP сървъра, когато създаваме DNCP пул. Обединяването означава, че казвате на сървъра да присвои IP адреси в диапазона от 192.168.1.1 до 192.168.1.254. По този начин DHCP сървърът ще създаде пул, ще постави 254 IP адреса в него и ще може да присвоява адреси на мрежови клиенти само от този пул. Така че това е нещо като административна настройка, която потребителят може да направи.
Сега нека разгледаме TCP предаването. Не знам дали сте запознати с "телефона" на снимката, но когато бяхме деца, използвахме тези тенекии, свързани с канап, за да говорим помежду си.
За съжаление днешното поколение не може да си позволи подобен „лукс“. Искам да кажа, че днес децата са пред телевизора от една годинка, те играят на PSP и може би това е спорен въпрос, но мисля, че имахме най-хубавото детство, наистина излизахме и играехме игри, ъ-ъ, днешните деца не могат да бъдат откъснати дивана.
Синът ми е само на годинка и вече виждам, че е пристрастен към iPad, имам предвид, че е още много малък, но ми се струва, че днешните деца вече се раждат със знанието как да боравят с електронни джаджи. И така, исках да кажа, че в детството, когато играехме, правехме дупки в тенекии и когато ги завържехме с връв и казахме нещо в едната кутия, тогава от другия край човек можеше да чуе какво му казват него, просто като поставите кутията до ухото му. Така че е много подобно на мрежова връзка.
Днес, дори за TCP предаване, трябва да има връзка, която трябва да бъде установена, преди да започне действителното предаване на данни. Както обсъждахме в предишните уроци, TCP е предаване, ориентирано към мрежова връзка, докато UDP е предаване без връзка. Може да се каже, че UDP е, когато хвърлям топката и от вас зависи дали можете да я хванете. Независимо дали искаш да го направиш или не, това не е мой проблем, просто ще се откажа.
TCP е по-скоро като да говорите с човек и да му дадете предварително предупреждение, че ще хвърлите топката, което означава, че се свързвате, преди да хвърлите топката, така че партньорът ви е по-вероятно да е готов да я хване. Така че TCP всъщност изгражда връзката и след това започва действителното предаване.
Нека да видим как създава такава връзка. Този протокол използва 3-посочно ръкостискане за създаване на връзка. Това не е много технически термин, но отдавна се използва за описание на TCP връзка. 3-посочното ръкостискане се инициира от изпращащото устройство, като клиентът изпраща пакет с флага SYN към сървъра.
Да предположим, че момичето на преден план, чието лице можем да видим, е устройство A, а момичето на заден план, чието лице не се вижда, е устройство B. Момиче A изпраща SYN пакет на момиче B и тя казва: „добре , някой, с когото иска да общува с мен. Така че трябва да отговоря, че съм готов да общувам!“ Как да го направим? Човек може просто да изпрати обратно друг SYN пакет и след това ACK, показващ получаването на оригиналния SYN пакет. Но вместо да изпраща отделно ACK, сървърът формира общ пакет, който съдържа SYN и ACK и го изпраща по мрежата.
И така, в този момент устройство А е изпратило SYN пакет и е получило обратно SYN/ACK пакет. Сега устройство A трябва да изпрати ACK пакет до устройство B, тоест да потвърди, че е получило съгласието на устройство B за установяване на комуникация. Така и двете устройства получиха SYN и ACK пакети и сега можем да кажем, че връзката е установена, тоест извършено е 3-посочно ръкостискане с помощта на TCP протокола.
След това ще разгледаме технологията TCP Windowing. Просто казано, това е техника, използвана в TCP/IP за договаряне на възможностите на подател и получател.
Да кажем, че в Windows се опитваме да прехвърлим голям файл, например с размер 2 GB, от едно устройство на друго. В самото начало на прехвърлянето системата ще ни информира, че прехвърлянето на файла ще отнеме приблизително 1 година. Но няколко секунди по-късно системата ще се коригира и ще каже: "о, чакай малко, мисля, че няма да отнеме година, а около 6 месеца." Ще мине още малко време и Windows ще каже: "Мисля, че вероятно мога да прехвърля файла след 1 месец." След това ще последва съобщението "1 ден", "6 часа", "3 часа", "1 час", "20 минути", "10 минути", "3 минути". Всъщност целият процес на прехвърляне на файлове ще отнеме само 3 минути. Как се случи това? Първоначално, когато вашето устройство се опита да комуникира с друго устройство, то изпраща един пакет и чака потвърждение. Ако устройството чака потвърждение дълго време, то си мисли: "ако трябва да прехвърля 2 GB данни с тази скорост, тогава ще отнеме около 2 години." След известно време устройството ви получава ACK и си мисли: „Добре, изпратих един пакет и получих ACK, така че получателят може да получи 1 пакет. Сега ще се опитам да му изпратя 10 пакета вместо един.” Подателят изпраща 10 пакета и след известно време получава обратно ACK от приемащото устройство, което означава, че получателят чака следващия, 11-ти пакет. Подателят си мисли: „Страхотно, тъй като получателят се е справил с 10 пакета наведнъж, сега ще се опитам да му изпратя 100 пакета вместо десет.“ Изпраща 100 пакета и получателят отговаря, че ги е получил и сега чака 101 пакета. Така с течение на времето броят на предаваните пакети се увеличава.
Ето защо виждате драстично намаляване на времето за копиране на файлове в сравнение с първоначално заявеното - това се дължи на увеличаването на способността за прехвърляне на големи количества данни. Идва обаче момент, когато по-нататъшното увеличаване на обема на предаване става невъзможно. Да предположим, че сте изпратили 10000 9000 пакета, но буферът на устройството на приемника може да получи само 9000 9001. В този случай приемникът изпраща ACK със съобщението: „Получих 9000 пакета и вече е готов да получа 9000“. От това подателят заключава, че буферът на приемащото устройство има капацитет само 9000, което означава, че оттук нататък ще изпращам не повече от 3 пакета наведнъж. В същото време изпращачът бързо изчислява времето, което ще му отнеме да предаде оставащото количество данни на части от XNUMX пакета, и издава XNUMX минути. Тези три минути са действителното време за предаване. Това прави TCP Windowing.
Това е един от онези механизми за ограничаване на трафика, при които предавателното устройство научава с времето каква е действителната пропускателна способност на мрежата. Може би се чудите защо те не могат да се договорят предварително какъв е капацитетът на приемащото устройство? Факт е, че е технически невъзможно, тъй като в мрежата има различни видове устройства. Да приемем, че имате iPad и той има различна скорост на качване/изтегляне от iPhone, може да имате различни видове телефони или може би имате много стар компютър. Следователно всеки има различна честотна лента на мрежата.
Поради това е разработена технологията TCP Windowing, когато преносът на данни започва с ниска скорост или с прехвърляне на минимален брой пакети, постепенно увеличавайки „прозореца“ на трафика. Изпращате един пакет, 5 пакета, 10 пакета, 1000 пакета, 10000 XNUMX пакета и бавно отваряте този прозорец все повече и повече, докато „отварянето“ достигне максималното възможно количество трафик, изпратен за определен период от време. По този начин концепцията за Windowing е част от начина на работа на TCP протокола.
След това ще разгледаме най-често срещаните номера на портове. Класическата ситуация е, когато имате 1 основен сървър, може би център за данни. Той включва файлов сървър, уеб сървър, пощенски сървър и DHCP сървър. Сега, ако един от клиентските компютри се свърже с центъра за данни, който се намира в средата на картината, той ще започне да изпраща трафик на файловия сървър към клиентските устройства. Този трафик е показан в червено и ще използва конкретен порт за конкретно приложение от конкретен сървър.
Как сървърът знае къде трябва да отиде определен трафик? Той научава за това от номера на порта на дестинацията. Ако погледнете кадъра, ще видите, че във всяко прехвърляне на данни се споменава номера на порта на местоназначението и номера на порта на източника. Можете да видите, че синият и червеният трафик, а синият трафик е трафик на уеб сървър, и двата отиват към един и същ физически сървър, който има различни инсталирани сървъри. Ако е център за данни, тогава той използва виртуални сървъри. И така, как са разбрали, че червеният трафик е трябвало да се върне към този ляв лаптоп с този IP адрес? Те знаят това поради номерата на портовете. Ако се обърнете към статията в Уикипедия „Списък на TCP и UDP портове“, ще видите, че в нея са изброени всички стандартни номера на портове.
Ако превъртите тази страница, можете да видите колко голям е този списък. Съдържа приблизително 61 000 числа. Номерата на портове от 1 до 1024 са известни като най-често срещаните номера на портове. Например порт 21/TCP е за изпращане на ftp команди, порт 22 за ssh, порт 23 за Telnet, тоест за изпращане на некриптирани съобщения. Много популярният порт 80 е за HTTP комуникация, докато порт 443 е за криптирана комуникация с HTTPS, което е подобно на защитената версия на HTTP.
Някои портове са както за TCP, така и за UDP, а някои изпълняват различни задачи в зависимост от това дали връзката е TCP или UDP. И така, официално TCP порт 80 се използва за HTTP, а неофициално UDP порт 80 се използва за HTTP, но използвайки различен HTTP протокол - QUIC.
Следователно номерата на портове в TCP не винаги трябва да бъдат същите като тези в UDP. Не е необходимо да запомняте този списък, невъзможно е да го запомните, но трябва да знаете някои популярни и най-често срещани номера на портове. Както казах, някои от тези портове имат официално предназначение, което е описано в стандартите, а някои имат неофициално предназначение, какъвто е случаят с Chromium.
И така, тази таблица изброява всички общи номера на портове и тези номера се използват за изпращане и получаване на трафик при използване на конкретни приложения.
Сега нека да разгледаме как данните се движат в мрежата въз основа на малкото информация, която знаем. Да предположим, че компютър 10.1.1.10 иска да се свърже с този компютър или този сървър, който има адрес 30.1.1.10. Под IP адреса на всяко устройство е неговият MAC адрес. Давам примерен MAC адрес само с последните 4 цифри, но на практика това е 48-битово шестнадесетично число с 12 цифри. Тъй като всяко от тези числа се състои от 4 бита, 12 шестнадесетични цифри са 48-битово число.
Както знаем, ако това устройство иска да се свърже с този сървър, първо трябва да се направи първата стъпка от 3-посочното ръкостискане, тоест да се изпрати SYN пакет. Когато прави тази заявка, компютърът 10.1.1.10 ще посочи номера на порт източника, който Windows създава динамично. Windows произволно избира номер на порт от 1 до 65,000 1. Но тъй като началните числа в диапазона от 1024 до 25000 са широко известни, в този случай системата ще вземе предвид числа, по-големи от 25113 XNUMX, и ще генерира произволен порт на източника, например номер XNUMX.
След това системата ще добави целевия порт към пакета, в този случай порт 21, тъй като приложението, което се опитва да се свърже с този FTP сървър, знае, че трябва да изпраща FTP трафик.
След това нашият компютър казва: „Добре, моят IP адрес е 10.1.1.10 и трябва да се свържа с IP адрес 30.1.1.10.“ И двата адреса също са включени в пакета, образувайки SYN заявка и този пакет няма да се промени до края на връзката.
Искам да разберете от това видео как данните се движат по мрежата. Когато нашият искащ компютър види IP източника и IP адреса на местоназначението, той разбира, че адресът на местоназначение не е в тази локална мрежа. Забравих да кажа, че това са всички /24 IP адреси. Така че, ако погледнете /24 IP адресите, ще разберете, че компютрите 10.1.1.10 и 30.1.1.10 не са в една и съща мрежа. Така искащият компютър разбира, че за да напусне тази мрежа, той трябва да се свърже с шлюза 10.1.1.1, който е конфигуриран на един от интерфейсите на рутера. Той знае, че трябва да отиде на 10.1.1.1 и знае своя MAC адрес 1111, но не знае MAC адреса на шлюза 10.1.1.1. Какво прави той? Той изпраща ARP заявка за излъчване, която всички устройства в мрежата ще получат, но само рутерът с IP адрес 10.1.1.1 ще отговори на нея.
Рутерът ще отговори със своя AAAA MAC адрес и MAC адресите на източника и местоназначението също ще бъдат поставени в тази рамка. След като рамката е готова, ще бъде извършена проверка на целостта на CRC данните, която е алгоритъм за контролна сума за откриване на грешки, преди да напусне мрежата.
CRC означава, че целият този кадър, от SYN до последния MAC адрес, се изпълнява през алгоритъм за хеширане, да речем MD5, което води до хеш стойност. След това хеш-стойността или контролната сума MD5 се поставя в началото на рамката.
Нарекох го FCS/CRC, защото FCS е последователност за проверка на рамка, четири байтова CRC стойност. Някои хора използват обозначението FCS, а някои използват обозначението CRC, така че току-що изброих и двете обозначения. Но основно това е просто хеш стойност. Това е необходимо, за да се гарантира, че всички данни, идващи по мрежата, не съдържат грешки. Следователно, когато този кадър достигне до рутера, първото нещо, което рутерът ще направи, е да изчисли самата контролна сума и да я сравни с FCS или CRC стойността, която съдържа получения кадър. Така той ще може да провери дали получените по мрежата данни не съдържат грешки, след което ще премахне контролната сума от рамката.
След това рутерът ще погледне MAC адреса и ще каже „ОК, MAC адрес AAAA означава, че рамката е за мен“ и ще премахне MAC частта от рамката.
Поглеждайки IP адреса на местоназначението 30.1.1.10, той ще разбере, че този пакет не е адресиран до него и трябва да премине през рутера по-нататък.
Сега рутерът "мисли" как трябва да види къде се намира мрежата с адрес 30.1.1.10. Все още не сме разгледали пълната концепция за маршрутизиране, но знаем, че рутерите имат таблица за маршрутизиране. Тази таблица има запис за мрежата с адрес 30.1.1.0. Както си спомняте, това не е IP адрес на хост, а мрежов идентификатор. Рутерът ще „помисли“, че е възможно да достигне до адрес 30.1.1.0/24, като премине през рутера 20.1.1.2.
Откъде знае това, може да попитате? Само имайте предвид, че той ще знае за това или от протоколите за маршрутизиране, или от вашите настройки, ако сте конфигурирали статичен маршрут като администратор. Но както и да е, таблицата за маршрутизиране на този рутер съдържа правилния запис, така че знае, че трябва да изпрати този пакет до 20.1.1.2. Ако приемем, че рутерът вече знае MAC адреса на местоназначението, ние просто ще продължим да препращаме пакета. Ако той не знае този адрес, тогава той ще стартира отново ARP, ще получи MAC адреса на рутера 20.1.1.2 и процесът на изпращане на рамката ще продължи отново.
Така че приемаме, че той вече знае MAC адреса, тогава ще имаме MAC адреса на източника на BBB и MAC адреса на местоназначението на CCC. Рутерът изчислява отново FCS/CRC и го поставя в началото на рамката.
След това изпраща този кадър по мрежата, кадърът достига до рутера 20.1.12, който проверява контролната сума, уверява се, че данните не са повредени и премахва FCS/CRC. След това "отрязва" MAC адресите, разглежда дестинацията и вижда, че е 30.1.1.10. Той знае, че този адрес е свързан с неговия интерфейс. Същият процес на кадриране се повтаря, рутерът добавя стойностите на MAC адреса на източника и местоназначението, извършва хеширането, прикрепя хеша към рамката и го изпраща по мрежата.
Нашият сървър, след като най-накрая получи SYN заявка, адресирана до него, проверява контролната сума на хеша и ако пакетът не съдържа грешки, изтрива хеша. След това премахва MAC адресите, преглежда IP адреса и разбира, че този пакет е адресиран до него.
След това съкращава IP адресите, свързани с третото ниво на OSI модела, и преглежда номерата на портовете.
Той вижда порт 21, което означава FTP трафик, вижда SYN и следователно разбира, че някой се опитва да комуникира с него.
Сега, въз основа на това, което сме научили за ръкостискането, сървър 30.1.1.10 създава SYN/ACK пакет и го изпраща обратно на компютър 10.1.1.10. След като получи този пакет, устройството 10.1.1.10 ще създаде ACK, ще го предаде през мрежата по същия начин като SYN пакет и след получаване на ACK от сървъра, връзката ще бъде установена.
Едно нещо, което трябва да знаете е, че всичко се случва за по-малко от секунда. Това е много, много бърз процес, който се опитах да забавя, за да разберете всичко.
Надявам се да намерите полезно това, което сте научили от този урок. Ако имате въпроси, моля, пишете ми на [имейл защитен] или оставете въпроси под това видео.
Започвайки от следващия урок, ще избера 3 от най-интересните въпроси от YouTube, които ще разгледам в края на всяко видео. Отсега нататък ще имам раздел „Най-добри въпроси“, така че ще публикувам въпрос заедно с вашето име и ще отговоря на него на живо. Мисля, че ще е от полза.
Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, 30% отстъпка за потребителите на Habr за уникален аналог на сървъри от начално ниво, който беше измислен от нас за вас: (предлага се с RAID1 и RAID10, до 24 ядра и до 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 ядра) 10GB DDR4 240GB SSD 1Gbps безплатно до лятото при плащане за период от шест месеца можете да поръчате .
Dell R730xd 2 пъти по-евтин? Само тук в Холандия! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - от $99! Прочети за
Източник: www.habr.com