Перш ніж ми розпочнемо сьогоднішній відеоурок, хочу подякувати всім, хто сприяв популярності мого курсу на YouTube. Коли я почав його близько 8 місяців тому, то не очікував такого успіху – на сьогодні мої уроки переглянули 312724 11208 особи, у мене 7 6 передплатників. Мені й не снилося, що цей скромний почин досягне таких висот. Але не втрачатимемо часу і відразу перейдемо до сьогоднішнього заняття. Сьогодні ми заповнимо прогалини, які мали місце в останніх 3 відеоуроках. Хоча сьогодні тільки 3 день, день XNUMX був розбитий на XNUMX відеоуроки, тому фактично сьогодні ви подивіться восьмий відеоурок.
Сьогодні ми займатимемося 3 важливими темами: DHCP, передача TCP та найбільш уживані номери портів. Ми вже говорили про IP-адреси, і одним із найважливіших факторів конфігурації IP-адреси є DHCP.
DHCP розшифровується як "протокол динамічного налаштування вузла", це протокол, який допомагає динамічно налаштовувати IP-адреси для хостів. Отже, всі ми бачили це вікно. При натисканні на параметр "отримати IP-адресу автоматично" комп'ютер шукає DHCP-сервер, налаштований в одній підмережі та відправляє різні пакети та запити для IP-адреси. Протокол DHCP має 6 повідомлень, з яких 4 мають вирішальне значення для призначення IP-адреси.
Перше повідомлення є повідомленням виявлення DHCP DISCOVERY. Повідомлення виявлення DHCP схоже на вітання. Коли новий пристрій входить у мережу, він запитує, чи є у мережі DHCP-сервер.
Те, що ви бачите на слайді, схоже на широкомовний запит, код пристрою звертається до всіх пристроїв в мережі в пошуках DHCP-сервера. Як я вже сказав, це широкомовний запит, тому його чують усі пристрої мережі.
Якщо в мережі є сервер DHCP, він відправляє пакет — пропозицію DHCP OFFER. Пропозиція означає, що DHCP-сервер у відповідь на запит виявлення надсилає клієнту конфігурацію, пропонуючи клієнту прийняти певну IP-адресу.
DHCP-сервер резервує IP-адресу, в даному випадку 192.168.1.2, не надає, а саме резервує за пристроєм цю адресу. Разом з цим у пакеті пропозиції міститься власна IP-адреса DHCP-сервера.
Якщо в цій мережі є більше одного DHCP-сервера, інший DHCP-сервер, отримавши широкомовний запит клієнта, також запропонував би йому свою IP-адресу, наприклад, 192.168.1.50. Зазвичай в одній і тій же мережі не налаштовуються два різні DHCP-сервери, але іноді таке все ж таки трапляється. Таким чином, коли пропозиція DHCP відправляється клієнту, він отримує дві пропозиції DHCP і тепер повинен вирішити, яку пропозицію DHCP він хоче прийняти.
Давайте припустимо, що клієнт приймає перший додаток. Це означає, що клієнт надсилає запит DHCP REQUEST, в якому буквально говориться: «я приймаю IP-адресу 192.168.1.2, яку пропонує DHCP-сервер 192.168.1.1».
Отримавши запит, DHCP-сервер 192.168.1.1 відповідає: «добре, я це визнаю», тобто підтверджує запит і надсилає це підтвердження DHCP ACK клієнту. Але ми пам'ятаємо, що інший DHCP-сервер DHCP зарезервував для клієнта IP-адресу 1.50. Отримавши широкомовний запит клієнта, він дізнається про відмову і помістить цю IP-адресу назад у пул, щоб він міг призначити його іншому клієнту, якщо отримає інший запит.
Такі 4 критичні повідомлення, якими обмінюється DHCP а початку призначення IP-адрес. Далі у DHCP є ще 2 інформаційні повідомлення. Інформаційне повідомлення видається клієнтом, якщо йому потрібно більше інформації, ніж він отримав на пропозицію DHCP OFFER на другому кроці. Якщо в пропозиції 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-прапором.
Припустимо, що дівчинка на передньому плані, чию особу ми можемо бачити - це пристрій А, а дівчинка на задньому плані, обличчя якої не видно - пристрій В. Дівчинка А посилає SYN-пакет дівчинці В, і та каже: «відмінно, хто- то хоче зі мною спілкуватися. Отже, мені треба відповісти, що я готова до спілкування! Як це зробити? Можна було б просто відправити ще один SYN-пакет і потім підтвердження ACK, що вказує на отримання вихідного пакета SYN. Але замість того, щоб відправляти ACK окремо, сервер формує загальний пакет, в якому міститься SYN та ACK, та передає його по мережі.
Отже, на даний момент пристрій відправив SYN-пакет і отримав назад пакет SYN/ACK. Тепер пристрій А повинен відправити пристрою пакет ACK, тобто підтвердити те, що він отримав згоду пристрою на встановлення зв'язку. Таким чином, обидва пристрої отримали пакети SYN і ACK, і тепер можна сказати, що з'єднання встановлено, тобто здійснено 3-х етапне рукостискання по протоколу TCP.
Далі ми розглянемо технологію TCP Windowing. Простіше кажучи, це метод, що використовується в TCP/IP для узгодження можливостей відправника та одержувача.
Припустимо, що у Windows намагаємося перенести великий файл, скажімо, розміром 2 ГБ, з одного диска в інший. На початку перенесення система повідомить нам, що перенесення файлу займе приблизно 1 рік. Але через кілька секунд система виправиться і скаже: «о, зачекайте хвилинку, я думаю, що це займе не рік, а близько 6 місяців». Мине ще трохи часу, і Windows повідомить: «я думаю, що можливо, зможу перенести файл за 1 місяць». Потім буде повідомлення "1 день", "6 годин", "3 години", "1 година", "20 хвилин", "10 хвилин", "3 хвилини". Насправді весь процес перенесення файлу триватиме лише 3 хвилини. Як же так вийшло? Спочатку, коли ваш пристрій спробував зв'язатися з іншим пристроєм, він відправляє один пакет і чекає на підтвердження. Якщо пристрій чекає підтвердження довгий час, він думає: «якщо я маю зробити передачу 2 ГБ даних на такій швидкості, то це займе близько 2 років». Через деякий час ваш пристрій отримує ACK і думає: «Добре, я послав один пакет і отримав ACK, отже, одержувач може прийняти 1 пакет. Тепер спробую відправити йому 10 пакетів замість одного». Відправник посилає 10 пакетів і через якийсь час отримує назад від пристрою, що приймає, підтвердження АСК, яке означає, що одержувач чекає наступний, 11-й пакет. Відправник думає: «відмінно, раз одержувач впорався відразу з 10 пакетами, тепер я спробую послати йому 100 пакетів замість десяти». Він посилає 100 пакетів, і одержувач відповідає, що отримав їх і зараз чекає на 101 пакет. Таким чином, з часом кількість пакетів, що передаються, збільшується.
Ось чому ви бачите стрімке зменшення часу копіювання файлу в порівнянні із заявленим спочатку це пов'язано зі збільшенням можливості передачі великого обсягу даних. Однак настає момент, коли подальше збільшення обсягу передачі стає неможливим. Припустимо, ви передали 10000 пакетів, але буфер пристрою одержувача здатний прийняти лише 9000. У цьому випадку одержувач відправляє ACK з повідомленням: "я прийняв 9000 пакетів і тепер готовий прийняти 9001". З цього відправник робить висновок, що буфер приймаючого пристрою має ємність всього 9000, значить, з цього моменту я посилатиму за раз не більше 9000 пакетів. При цьому відправник швидко підраховує час, який знадобиться йому на передачу обсягу даних, що залишився, порціями по 9000 пакетів, і видає 3 хвилини. Ці три хвилини є фактичним часом передачі. Ось що робить TCP Windowing.
Це один з тих механізмів регулювання трафіку, де пристрій, що передає, з часом розуміє, яка фактична пропускна здатність мережі. У вас може виникнути питання, чому вони не можуть домовитися заздалегідь про те, яка ємність пристрою, що приймає? Справа в тому, що технічно це неможливо, тому що в мережі є різні типи пристроїв. Припустимо, у вас є iPad, і у нього швидкість прийому/передачі даних відрізняється від iPhone, у вас можуть бути різні типи телефонів, або, можливо, у вас дуже старий комп'ютер. Тому у всіх різна пропускна спроможність мережі.
Тому і була розроблена технологія TCP Windowing, коли передача даних починається на невеликій швидкості або з передачі мінімальної кількості пакетів, поступово збільшуючи вікно трафіку. Ви відправляєте один пакет, 5 пакетів, 10 пакетів, 1000 пакетів, 10000 пакетів і повільно відкриваєте це вікно дедалі більше, поки «розкриття» досягне максимального можливого значення відправки обсягу трафіку в конкретний проміжок часу. Таким чином, концепція Windowing є частиною протоколу TCP.
Далі ми розглянемо найпоширеніші номери портів. Класичною є ситуація, коли ви маєте 1 головний сервер, можливо, це дата-центр. Він включає файловий сервер, веб-сервер, поштовий сервер і DHCP-сервер. Тепер, якщо один із клієнтських комп'ютерів зв'яжеться з дата-центром, розташованим у середині картинки, той почне розсилати клієнтським пристроям трафік файлового сервера. Цей трафік показано червоним кольором, і для його передачі буде використовуватись певний порт для певної програми від певного сервера.
Як сервер дізнався, куди повинен йти певний трафік? Він дізнається з номера порту призначення. Якщо ви подивитеся на кадр, побачите, що в кожній передачі даних є згадка номера порту призначення та порту джерела. Ви бачите, що синій та червоний трафік, а синій трафік – це трафік веб-сервера, обидва надходять на той самий фізичний сервер, в якому встановлені різні сервери. Якщо це дата-центр, він використовує віртуальні сервери. То як вони дізналися, що червоний трафік мав повернутися до цього лівого ноутбука з цією IP-адресою? Вони знають це завдяки номерам портів. Якщо ви звернетеся до статті Вікіпедії «Список портів TCP та UDP», побачите, що в ній перелічені всі стандартні номери портів.
Якщо прокрутити цю сторінку, то можна побачити, наскільки великий цей список. Він містить приблизно 61 номерів. Номери портів від 000 до 1 відомі як найпоширеніші номери портів. Наприклад, порт 1024/TCP призначений передачі команд ftp, порт 21 для ssh, порт 22 – для Telnet, тобто передачі незашифрованих повідомлень. Дуже популярний порт 23 служить передачі даних по протоколу HTTP, а порт 80 служить передачі зашифрованих даних з протоколу HTTPS, який нагадує безпечну версію HTTP.
Деякі порти призначені одночасно для TCP та UDP, а деякі виконують різні завдання залежно від того, яке з'єднання використовується – TCP чи UDP. Так, офіційно порт 80 TCP використовується для HTTP, а неофіційно порт 80 UDP використовується для HTTP, але з іншого протоколу HTTP - QUIC.
Тому номери портів TCP не завжди призначені для того ж, що і в UDP. Вам не потрібно вивчати цей список напам'ять, його неможливо запам'ятати, але деякі популярні і найбільш поширені номери портів потрібно знати. Як я сказав, деякі з цих портів мають офіційне призначення, яке описано у стандартах, а деякі – неофіційне призначення, як у випадку зі Сhromium.
Отже, у цій таблиці перелічені всі поширені номери портів, і ці номери служать для надсилання та отримання трафіку під час використання конкретних додатків.
Тепер давайте розглянемо, як дані переміщуються в мережі, ґрунтуючись на тій невеликій інформації, яку знаємо. Припустимо, що комп'ютер 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.
Далі система додасть до пакета порт призначення, в даному випадку це порт 21, тому що додаток, який намагається підключитися до цього FTP-серверу, знає, що він повинен відправити FTP-трафік.
Далі наш комп'ютер говорить: «Добре, моя IP-адреса 10.1.1.10, а мені потрібно зв'язатися з IP-адресою 30.1.1.10». Обидві ці адреси також включаються до пакету, формуючи SYN-запит, і цей пакет не буде змінюватися до кінця встановлення з'єднання.
Я хочу, щоб ви зрозуміли з цього відео, як дані переміщуються по мережі. Коли наш комп'ютер, що надсилає запит, бачить IP-адресу джерела та IP-адресу призначення, він розуміє, що адреса призначення не знаходиться у цій локальній мережі. Я забув сказати, що це все /24 IP-адреси. Отже, якщо ви подивитеся на IP-адреси /24, то зрозумієте, що комп'ютери 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.
Маршрутизатор відповість йому своєю 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% знижка для користувачів Хабра на унікальний аналог entry-level серверів, який був винайдений нами для Вас: (Доступні варіанти з RAID1 і RAID10, до 24 ядер і до 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps до літа безкоштовно при оплаті на строк від півроку, замовити можна .
Dell R730xd у 2 рази дешевше? Тільки в нас у Нідерландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – від $99! Читайте про те
Джерело: habr.com