Основи комп'ютерних мереж. Тема №3. Протоколи нижніх рівнів (транспортного, мережевого і канального)


Вітаю всіх читачів. Тепер настав час поговорити про протоколах, що знаходяться на нижніх рівнях. У цій статті будуть розібрані протоколи канального, мережного та транспортного рівнів. Сідайте зручніше і читайте на здоров'я.


Зміст1) Основні мережеві терміни, мережева модель OSI і стек протоколів TCP/IP.
2) Протоколи верхнього рівня.
3) Протоколи нижніх рівнів (транспортного, мережевого і канального).
4) Мережеві пристрої і види застосовуваних кабелів.
5) Поняття VLAN Trunk і протоколи VTP і DTP.
6) Протокол сполучного дерева: STP.
7) Протокол агрегування каналів: Etherchannel.
8) Поняття IP адресації, масок підмереж і їх розрахунок.
9) Маршрутизація: статична і динамічна на прикладі RIP, OSPF і EIGRP.
10) Трансляція мережевих адрес: NAT і PAT.
11) Протоколи резервування першого переходу: FHRP.
12) Безпека комп'ютерних мереж і віртуальні приватні мережі VPN.
13) Глобальні мережі і використовувані протоколи: PPP, HDLC, і Frame Relay.
14) Введення в IPv6, конфігурація і маршрутизація.
15) Мережеве управління і моніторинг мережі.

P. S. Можливо, з часом список доповниться.

Як ви пам'ятаєте, я вже казав про те, що в мережах важливо суворе дотримання всіх правил для коректної роботи. А саме процес інкапсуляції і деинкапсуляции. Тому, коли у попередній статті говорили про протоколи верхніх рівнів, я побіжно згадував про деякі протоколи нижніх рівнів, так як вони постійно вилазили і нагадували про себе. Поясню чому. Подивіться зараз на картинку вище. Тут наведена робота пошти. Погляньте на двох лисих дядьків угорі, які написали лист і світяться від щастя. Але користі не буде від листа, якщо його не побачить адресат. Для цього вони скористаються поштовою службою. Їхній лист прийме працівниця поштового відділення і покладе в конверт. Конверт вона підпише, щоб було зрозуміло від кого воно і кому. Далі цей лист забере кур'єр і віднесе в сортувальний центр. Нижче стоїть чоловік у кашкеті і фартуху, який жонглює листами. Він знає, куди покласти лист, щоб воно дійшло до адресата. І в самому низу поїзд, який є транспортним вузлом. Зауважте, що тут важлива роль кожного для вдалої відправки і доставки листа.
У мережах все теж саме. Вирішили ви залізти на сайт і почитати новини. Набираєте в рядку браузера адресу сайту. Далі ваш комп'ютер як то повинен ці сторінки запитати. І тут на допомогу прийдуть протоколи нижче, які є транспортним вузлом. Тут кожен рівень можна порівняти з вищеописаними особистостями на малюнку.

Підведу я всю цю тяганину до спільного знаменника і поділюся прикладом, який я для себе вивів. У вас є кінцеве мережеве пристрій. Не важливо який комп'ютер, ноутбук, планшет, смартфон або ще що. Кожне з цих пристроїв працює по стеку TCP/IP. А значить, воно дотримується його правила.
1) Прикладний рівень. Тут працює саме мережеве додаток. Тобто веб-браузер, який запускається, наприклад з комп'ютера.
2) Транспортний рівень. У програми або служби повинен бути порт, який він слухає і за яким з ним можна зв'язатися.
3) Рівень Інтернет. Тут присутній IP-адресу. Його ще називають логічним адресою пристрою в мережі. За допомогою нього можна зв'язатися з комп'ютером, на якому запущений цей самий браузер, а значить, і достукатися до самого додатка. Маючи даний адресу, він є учасником мережі і може зв'язуватися з іншими учасниками
4) Рівень доступу. Це сама мережева картка або антена. Тобто передавач і приймач. У нього є фізична адреса (MAC-адреса) для ідентифікації цієї мережевої карти. Кабелі, коннектори теж відносяться сюди. Це середовище, яка зв'яже комп'ютер з іншими учасниками.

Почнемо з самого нижнього рівня. Це канальний і фізичний рівень, якщо розглядати з точки зору моделі OSI і рівень доступу, якщо дивитися з висоти стека протоколів TCP/IP. Користуємося ми TCP/IP, тому я буду говорити з її точки зору. Рівень доступу, як ви зрозуміли, поєднує в собі фізичний і канальний рівень.

Фізичний рівень. Або як його люблять називати «електричний рівень». Задає параметри сигналу, а також який вид і форму має сигнал. Якщо, наприклад, використовується Ethernet (який передає дані за допомогою дроту), то яка модуляція, напруга, струм. Якщо це Wi-Fi, то які використовувати радіохвилі, частоту, амплітуду. До цього рівня можна віднести мережеві карти, Wi-Fi антени, коннектори. На цьому рівні вводиться таке поняття, як біти. Це одиниця вимірювання переданої інформації.

Канальний рівень. Цей рівень використовується для того, щоб передати не просто біти, а осмислені послідовності з цих біт. Використовується для передачі даних в одній канальної середовищі. Що це значить, я опишу трохи пізніше. На цьому рівні працюють MAC-адреси, які ще називають фізичні адреси.
Термін «фізичні адреси» ввели не просто так. Кожна мережева карта або антена має вшитий адресу, який їй надає виробник. В попередній статті я згадував термін «протоколи». Тільки там це були протоколи верхнього рівня, а якщо точніше, то прикладного. На канальному рівні працюють свої протоколи і кількість їх не маленьке. Найпопулярніші — це Ethernet (використовується в локальних мережах), PPP і HDLC (вони використовуються в глобальних мережах). Це звичайно далеко не всі, але Cisco у своїй сертифікації CCNA розглядає тільки їх.

Важко все це зрозуміти у вигляді суцільного сухого тексту, тому поясню на картинці.

Забудьте зараз про IP-адреси, модель OSI і стек протоколів TCP/IP. У вас є 4 комп'ютери і комутатор. На комутатор уваги не звертайте, так як це звичайна коробка для з'єднання комп'ютерів. У кожного комп'ютера є свій MAC-адресу, який ідентифікує його в мережі. Він обов'язково повинен бути унікальний. Хоч я і представив їх 3-х значними, це далеко не так. Зараз ця картинка тільки для логічного розуміння, а як це працює в реальному житті, напишу трохи нижче.
Отже. Якщо один з комп'ютерів захоче щось відправити іншого комп'ютера, то йому потрібно буде знати тільки MAC-адресу комп'ютера, на який він відправляє. Якщо верхньому лівому комп'ютера з MAC-адресою 111 захочеться щось відправити нижньому правому комп'ютера, то він без проблем відправить це, якщо буде знати, що в адресата MAC-адресу 222.
Ці 4 комп'ютера утворюють простеньку локальну мережу і одну канальну середу. Звідси і назва рівня. Але для коректної роботи вузлів у мережах TCP/IP, недостатньо адресації на канальному рівні. Важлива ще адресація на мережевому рівні, яка всім відома, як IP-адресація.
Тепер згадуємо про IP-адреси. І присвоїмо наших комп'ютерів.

Адреси я присвоїв символічно, щоб на базовому рівні зрозуміти, як вони працюють. Ось ці дві адресації (канальна і мережева) працюють у тісному зв'язку між собою і окремо працювати не зможуть. Зараз поясню чому. Ми в повсякденному житті працюємо тільки з IP-адресами або іменами, про яких була ціла глава в попередній статті. З MAC-адресами ми фактично не працюємо. З ними працюють самі комп'ютери. Зараз смоделирую ситуацію. Я сиджу за верхнім лівим комп'ютером IP: 1.1.1.1 і MAC: 111. Захотів я зв'язатися з нижнім правим компом і перевірити живий він чи ні. Я зможу зв'язатися з ним, якщо буду знати його IP-адресу. MAC-адресу мені його не цікавий. Я знаю, що IP-адреса у нього 1.1.1.4. І вирішую скористатися утилітою ping (утиліта перевірки доступності хоста). Тепер важлива річ. Комп'ютер розуміє, що він не знає MAC-адресу комп'ютера, доступність якого треба перевірити. Для того, щоб дізнатися MAC-адреси по IP-адресою, придумали протокол ARP. Я про нього напишу докладно пізніше. Зараз я хочу, щоб ви зрозуміли залежності MAC-адреси і IP-адреси. Отже, він на всю мережу починає кричати: «Хто такий 1.1.1.4». Цей крик почують всі учасники мережі і, якщо знайдеться той вузол, який має даний IP-адресу, він відгукнеться. У мене такий комп'ютер присутній і у відповідь на цей крик, він відповість: «1.1.1.4 — це я. Мій MAC — 444». Мій комп'ютер отримає це повідомлення і зможе продовжити те, що я йому сказав.
Далі потрібно навчитися відрізняти одну підмережа від іншої. І як комп'ютер розуміє, в одній підмережі перебуває він з іншим вузлом чи в різних. Для цього на допомогу приходить маска підмережі. Масок буває багато, і спочатку вона не здається страшною, але запевняю вас, що це тільки спочатку так здається. Їй присвячена ціла стаття і там ви пізнаєте всі її секрети. На даному ж етапі, я покажу, як це працює.
Якщо ви коли-небудь залазили в налаштування мережевих адаптерів або прописували статичний адресу, який вам повідомляв провайдер, то бачили поле «маска підмережі». Вона записується в тому ж форматі, що і IP-адреса, основний шлюз і DNS. Це чотири октету розділених між собою крапками. Якщо ви цього ніколи не бачили, то можете відкрити командний рядок і набрати в ній ipconfig. Ви побачите, щось схоже.

Скріншот з командного рядка мого ноутбука. Я сиджу за домашньою точкою доступу, у якій маска 255.255.255.0. Це, мабуть, найпростіша маска для пояснення і швидше за все у вас вона точно така ж. В чому суть. Перші 3 октету (вони фіксовані) показують адресу мережі, а 4 октет (він динамічний) показує адреса хоста. Іншими словами, дана маска показує, що потрібно перевіряти перші 3 октету повністю, а четвертий може бути вільним від 0 до 255. Взагалі це груба формулювання. Тому, що з такою маскою будуть вільні від 1 до 254, де 0 піде під адресу мережі, а 255 під широкомовна адреса. Але в будь-якому випадку це межа однієї канальної середовища. Тобто, коли вузла треба відправити іншому вузлу повідомлення, він бере його адресу і накладає на нього маску і якщо адреса мережі (фіксована частина) сходиться з його адресою, то значить вони в одній канальної середовищі. Пояснюю на прикладі тієї ж картинки.

Сиджу я за верхнім лівим компом і хочу відправити нижнього правого. Знаю я і IP-адресу та MAC-адресу. Мені треба зрозуміти, в одній канальної середовищі ми чи ні. Його адреса 1.1.1.4 і маска 255.255.255.0. Маска мені каже, що 3 октету фіксовані та не повинні змінюватися, а четвертий може бути будь-яким у межах від 1 до 254. Я накладаю маску на його адресу і на свою адресу і дивлюся збіги і відмінності.

Підсвічено червоним та область, яка відповідає за мережу. Як бачимо, у 2-х хостів вона однакова. Значить, вони знаходяться в одній підмережі.
Модернизирую мережу і покажу вам її трохи інакше.

Додалася круглий пристрій. Воно називається роутер або маршрутизатор. Слово всім знайоме. Основна його роль — це з'єднання мереж та вибір кращого маршруту, про що буде розказано більш докладно. І додався, праворуч, один комутатор, з яким з'єднані 2 комп'ютера. Маска для всіх пристроїв не змінилася (255.255.255.0). Подивіться уважно на адреси всіх пристроїв. Можна помітити, що у нових вузлів і старих відрізняється 3-ій октет. Давайте розберемося з цим. Я сиджу за компом з MAC:111 і IP:1.1.1.1. Хочу відправити інформацію одному з нових вузлів. Нехай це буде верхній правий комп'ютер MAC:555 і IP:1.1.2.1. Накладаю маску і дивлюся.

І тут вже інша картина. 3-ие октеты різняться, а отже, вузли знаходяться в різних мережах (правильніше підмереж). Для вирішення таких ситуації, в налаштуваннях кожної операційної системи є основний шлюз. Його ще називають «шлюз останньої надії». Використовується він, як раз, в тому випадку, коли потрібно надіслати інформацію вузла, що знаходиться в іншій канальної середовищі. Для мого компа адресу шлюзу — 1.1.1.254. А для комп'ютера, якому я відправляю дані 1.1.2.254. Логіка роботи тут проста. Якщо вузлу, який знаходився в одній канальної середовищі, інформація доходила напряму, то для вузла знаходиться в іншій канальної середовищі, шлях буде через маршрутизатор.
Мій комп знає, що адреса шлюзу 1.1.1.254. Він крикне на всю мережу: «1.1.1.254 озовися». Це повідомлення отримають всі учасники канальної середовища, але відповість тільки той, хто сидить за цією адресою. Тобто маршрутизатор. Він відправить відповідь, і тільки після цього мій комп відішле дані до адреси 1.1.2.254. Причому зверніть увагу. На канальному рівні дані будуть відправлені на MAC:777, а на мережевому, на IP:1.1.2.1. Це означає, що MAC-адресу передається тільки у своїй канальної середовищі, а мережевий адресу не змінюється на всьому своєму шляху. Коли маршрутизатор отримає інфу, він зрозуміє, що на канальному рівні вона призначалася йому, але коли побачить IP-адресу, то зрозуміє, що він проміжну ланку і передати треба в іншу канальну середу. Його другий порт дивиться в потрібну підмережа. Значить, йому все прийшло вірно. Але він не знає MAC-адресу одержувача. Він починає так само кричати на всю мережу: «Хто такий 1.1.2.1?». І комп з MAC-адресою 555 відповідає йому. Думаю, що логіка роботи зрозуміла.
Протягом двох попередніх статей та поточної, багато разів згадувався термін «MAC-адреса». Давайте розберемо, що це таке.
Як я вже говорив, це унікальний ідентифікатор мережевого пристрою. Він унікальний і не має ніде повторюватися. Складається він з 48 біт, з яких перші 24 біта — це унікальний ідентифікатор організації, який присвоюється комітетом IEEE(Інститут інженерів з електротехніки та електроніки). А другі 24 біта призначаються виробником обладнання. Виглядає це так.

Записують його по-різному. Наприклад:
1) 00-50-56-C0-00-08
2) 00:50:56:C0:00:08
3) 0050.56С0.0008
Як бачите, один і той ж адресу можна записати різними способами. Ще, звичайно, його не розділяють, а записують разом. Головне знати, що MAC-адресу завжди складається з 48 біт і складається з 12 букв і/або цифр. Подивитися його можна різними способами. Наприклад, в ОС Windows, відкрийте командний рядок, ввести ipconfig /all. Багато виробників ще записують його на коробці або на зворотній стороні корпуса пристрою.

Так що можете подивитися на свою Wi-Fi точку доступу і побачити схожу запис.
На самому початку я показав MAC-адреси 3-х значними цифрами, що не правда. В тому контексті я їх вживав тільки для простоти пояснення, щоб не плутати вас довгими незрозумілими записами. Трохи нижче, коли мова дійде до практики, ви побачите їх такими, які вони насправді.

Раз ми розібрали адресу на канальному рівні, прийшов час розібрати протокол, який працює на даному рівні. Найпопулярніший на сьогоднішній момент протокол, який використовується в локальних мережах — це Ethernet. IEEE описала його стандартом 802.3. Так що, всі версії, які починаються з 802.3, відносяться саме до нього. Наприклад, 802.3 z — це GigabitEthernet через волоконно-оптичний кабель; 1 Гбіт/с, а 802.3 af — це живлення через Ethernet (PoE — Power over Ethernet).
До речі, я не сказав про організації IEEE (англ. Institute of Electrical and Electronics Engineers). Ця організація розробляє стандарти до всього, що відноситься до радіоелектроніки й електротехніки. На їхньому сайті можна знайти багато документації за існуючими технологіями. Ось, що вони видають за запитом «Ethernet»

Давайте розберемо, з чого він складається. Так як сам протокол старий (придуманий в 1973 році), то він багато разів модернізувався і змінював свій формат. В Інтернеті можна знайти все його варіанти, але я наведу той, який призводила Cisco, коли я навчався.

1) Преамбула. Поле для зазначення початку кадру. Тобто, щоб приймач зміг зрозуміти, де початок нового кадру. Раніше, коли використовувалася топологія з загальною шиною і були колізії, преамбула допомагала запобігати колізії.
2) MAC-адресу одержувача. Поле, куди записується адреса одержувача.
3) MAC-адреса відправника. Відповідно сюди записується адреса відправника.
4) Тип (довжина). Раніше в цьому полі вказувалося, яким вищестоящому протоколу передається даний кадр, але надалі від цього відмовилися і ввели полі «Довжина». Воно вказує довжину поля даних, яке варіюється від 46-1500 байт.
5) Поле SNAP/LLC + дані. якраз SNAP/LLC вказує якого вищестоящому протоколу передати кадр. Це може бути IP, IPX і інші протоколи мережного рівня. Також це поле містить дані, отримані з вищих рівнів.
6) FCS (від англ. Frame Check Sequence — контроль послідовності кадрів). Поле в якому підрахована чек-сума. По ній одержувач розуміє, побився кадр чи ні.

По ходу написання цієї статті і наступних, будуть порушені й інші протоколи канального рівня. Поки що вищеописаного вистачає для розуміння його роботи.

Переходимо до мережевого рівня, і тут нас зустрічає гучний протокол IP. Раз ми говоримо про мережевому рівні, то значить протокол, який працює на цьому рівні, має якимось чином вміти передавати дані з однієї канальної середовища в іншу. Але для початку подивимося, що це за протокол і з чого він складається.
IP (від англ. Internet Protocol). Протокол сімейства TCP/IP, який був розроблений в 80-х роках. Як я говорив раніше, використовується для об'єднання окремих комп'ютерних мереж між собою. Також важливою його особливістю є адресація, яку називають IP-адреса. На поточний момент існує 2 версії протоколу: IPv4 і IPv6. Пару слів про них:
1) IPv4. Використовує 32-бітові адреси, які записуються у форматі чотирьох десяткових чисел (від 0 до 255), розділених крапками. Наприклад, адреса 192.168.0.4. Кожне число розділене точками називають октетом. Це найпопулярніша версія на сьогоднішній день.
2) IPv6. Використовує 128-бітові адреси, які записуються у форматі восьми чотиризначних шістнадцяткових чисел (від 0 до F). Наприклад, адреса 2001:0 db8:11a3:09d7:1f34:8a2e:07a0:765d. Кожне число розділене точками називають хекстетом. На зорі загальної комп'ютеризації з'явилася проблема. Стали закінчуватися IP-адреси і потрібен був новий протокол, який зміг би забезпечити більше адрес. Так і з'явився в 1996 році протокол IPv6. Але завдяки технології NAT, яка буде розглянута пізніше, була часткова вирішена проблема браку адрес, і в зв'язку з цим, впровадження IPv6 затягнулося по сьогоднішній день.

Думаю зрозуміло, що обидві версії призначені для одних і тих же цілей. У цій статті буде розібраний протокол IPv4. Про IPv6 буде написана окрема стаття.
Отже, протокол IP працює з блоком інформації, який прийнято називати IP-пакет. Розглянемо його структуру.

1) Версія. Протокол IPv4 або IPv6.
2) IHL (від англ. Internet Header Length — розмір заголовка). Так як багато хто з зображених на картинці полів не фіксовані, то це поле вважає розмір заголовка.
3) Тип обслуговування. Обслуговує розмір черг QoS (Quality of Service — якість обслуговування). Робить він це за допомогою байта, який вказує на певний набір критеріїв (вимога до часу затримки, пропускної спроможності, надійності і т. д.)
4) Довжина пакета. Розмір пакету. Якщо IHL відповідає тільки за розмір полів у заголовку (заголовок є всі поля на картинці, крім поля даних), то довжина пакету відповідає за весь пакет в цілому, включаючи користувацькі дані.
5) Час життя (TTL — Time To Live). Поле для запобігання циклічного шляху пакета. При проходженні через маршрутизатор, значення зменшується на одиницю, і коли досягає нуля, пакет відкидається.
6) Протокол. Для якогось вищого протоколу призначається даний пакет (TCP, UDP).
7) Контрольна сума заголовка. Тут вважається цілісність полів заголовка. Не даних! Дані перевіряються відповідним полем на канальному рівні.
8) Опції. Це поле використовується для розширення стандартного заголовка IP. Використовується в звичних мережах рідко. Сюди записуються дані для якого-небудь специфічного обладнання, яке читає це поле. Наприклад, система управління дверними замками (де йде спілкування з контролером), технологія розумного будинку, інтернет-речі і так далі. Звичні мережеві пристрої, як роутери і комутатори, будуть ігнорувати це поле.
9) Зміщення. Вказує, яким місцем належить фрагмент в оригінальному IP. Це значення завжди кратно восьми байтам.
10) Дані. Тут містяться дані, отримані з вищестоящих рівнів. Трохи вище я показав, що в Ethernet-кадрі теж є поле даних. І в його поле даних буде включений даний IP-пакет. Важливо пам'ятати, що максимальний розмір Ethernet-кадру дорівнює 1500 байт, а ось розмір IP-пакета може бути 20 Кбайт. Відповідно весь пакет не вміститься в поле даних Ethernet-кадри. Тому пакет ділять і відправляють частинами. І ось для цього використовуються 3 поля нижче.
11) Ідентифікатор. Це 4-х байтове число, яке показує, що всі частини розділеного пакету одне єдине ціле.
12) Прапори. Вказує, що це не єдиний, а фрагментований пакет.
13) Зсув фрагмента. Зрушення щодо першого фрагменту. Тобто це нумерація, яка допоможе зібрати IP-пакет воєдино.
14) IP-адреса відправника та IP-адресу одержувача. Відповідно ці 2 поля вказують від кого і для кого пакет.

Ось так виглядає IP-пакет. Звичайно, для новачків значення багатьох полів здадуться не зовсім зрозумілими, але надалі це вкладеться в голові. Наприклад: поле «Час життя (TTL)». Його робота стане зрозумілою, коли зрозумієте, як працює маршрутизація. Можу дати пораду, який я сам застосовую. Якщо бачите незрозумілий термін, випишіть окремо і, при наявності вільного часу, спробуйте розібрати. Якщо ніяк не лізе в голову, то відкладіть і поверніться до його вивчення трохи пізніше. Головне не закидати і в кінцевому підсумку все таки добити.

Залишився останній рівень з стека TCP/IP. Це транспортний рівень. Пару слів про нього. Він призначений для доставки даних визначеним додатком, яке він визначає за номером порту. В залежності від протоколу, він виконує різні завдання. Наприклад, фрагментація файлів, контроль доставки, мультиплексування потоками даних і управління ними. 2 найвідоміших протоколу транспортного рівня — це UDP і TCP. Поговоримо про кожну з них детальніше і почну з UDP, в силу його простоти. Ну і за традицією показую, з чого він складається.

1) Порт джерела. Порт, який використовується клієнтом або сервером для ідентифікації служби. На цей порт, при необхідності, буде посилати відповідь.
2) Порт призначення. Тут вказується порт, який буде адресатом. Наприклад, якщо клієнт запитує сторінку сайту, то порт призначення, за замовчуванням 80-ий (протокол HTTP).
3) Довжина UDP. Довжина заголовка UDP. Розмір варіюється від 8 до 65535 байт.
4) Контрольна сума UDP. Перевірка цілісності. Якщо порушено, то просто відкидає без запиту про повторної відправки.
5) Дані. Тут упаковані дані з верхнього рівня. Наприклад, коли веб-сервер відповідає на запит клієнта і відправляє веб-сторінку, то вона буде лежати в цьому полі.

Як бачите, у нього не так багато полів. Його завдання — це нумерація портів і перевіряти побився кадр чи ні. Протокол простий і не вимогливий до ресурсів. Однак він не може забезпечувати контроль доставки та повторно запитувати побиті шматки інформації. З відомих сервісів, які працюють з цим протоколом — це DHCP, TFTP. Вони розглядалися в попередній статті, коли розбиралися протоколи верхнього рівня.

Переходимо до складнішого протоколу. Зустрічаємо протокол TCP. Дивимося, з чого складається, і пробігаємо по кожному полю.

1) Порт джерела і порт призначення. Виконують ті ж ролі, що і UDP, а саме нумерація портів.
2) Порядковий номер. Номер, який використовується для того, щоб на іншій стороні було зрозуміло який цей сегмент за рахунком.
3) Номер підтвердження. Це поле використовується, коли очікується доставка або підтверджується доставка. Для цього використовується параметр ACK.
4) Довжина заголовка. Використовується для того, щоб зрозуміти який розмір в TCP-заголовку (це всі поля представлені на картинці вище, крім поля даних), а який у даних.
5) Зарезервований прапор. Значення цього поля повинна встановлюватися на нуль. Воно зарезервоване під спеціальні потреби. Наприклад, щоб повідомити про перевантаження в мережі.
6) Прапори. В це поле встановлюються спеціальні біти для встановлення або розриву сесії.
7) Розмір вікна. Поле, яке вказує, на скільки сегментів вимагати підтвердження. Напевно, кожен з вас спостерігав таку картину. Ви завантажуєте якийсь файл і бачите швидкість і час завантаження. І тут спочатку він показує, що залишилося 30 хвилин, а через 2-3 секунди вже 20 хвилин. Ще через 5 секунд, показує 10 хвилин і так далі. Це і є розмір вікна. Спочатку розмір вікна встановлюється таким чином, щоб отримувати більше підтверджень про кожному надісланому сегменті. Далі все йде добре і мережа не дає збої. Розмір вікна змінюється і більше сегментів і, відповідно, вимагаючи менше звітів про доставку. Таким чином, завантаження виконується швидше. Як тільки мережа дасть короткий збій, і якийсь сегмент прийде побитим, то розмір знову зміниться та буде потрібно більше звітів про доставку. В цьому суть даного поля.
8) Контрольна сума TCP. Перевірка цілісності TCP сегменту.
9) Покажчик важливості. Число, яке вказує на важливість того чи іншого пакету.
10) Опції. Використовується для якихось додаткових або додаткових параметрів. Наприклад, для параметра timestamp, який є своєрідною міткою, що показує час події.
11) Дані. Практично теж саме, що і в протоколі UDP. Тут інкапсульовані дані з вищого рівня.

Побачили ми будова протоколу TCP і разом з цим закінчили розмову про транспортному рівні. Вийшла така коротка теорія протоколів, що працюють на нижніх рівнях. Намагався пояснити як можна простіше. Зараз ще все це справа випробуємо на практиці і доб'ємо пару питань.

Я відкриваю CPT і зберу схему, аналогічну одному з малюнків вище.

Тут спостерігаємо першу мережу, що складається з 4-х комп'ютерів і комутатора, який об'єднує ці комп'ютери. І 2-ий мережу, що складається з двох комп'ютерів і комутатора. Об'єднує ці 2 мережі маршрутизатор. Перейдемо до налаштування пристроїв і після змоделюємо ту ситуацію, яку ми розглядали на самому початку на картинці.
Відкриваю комп'ютер PC1 і пропишу мережеві настройки.

Не став я мудрувати з адресою і скористався самим простим, який постійно на очах:
1) IP-адресу 192.168.1.1
2) Маска підмережі — 255.255.255.0. Цю маску ми розглядали вище. Нагадаю, що адреса мережі у інших хостів в тій же локальній мережі, повинен бути 192.168.1, а адреса хоста може бути від 1 до 254.
3) Основний шлюз — 192.168.1.254. Це адреса маршрутизатора, на який будуть відправлятися дані для хостів іншої локальної мережі.

Щоб не було багато однотипних картинок, я не буду приводити скріншоти інших 3-х комп'ютерів, а лише наведу їх налаштування.
PC2:
1) IP-адреса — 192.168.1.2
2) Маска підмережі — 255.255.255.0.
3) Основний шлюз — 192.168.1.254.

PC3:
1) IP-адреса — 192.168.1.3
2) Маска підмережі — 255.255.255.0.
3) Основний шлюз — 192.168.1.254.

PC4:
1) IP-адреса — 192.168.1.4
2) Маска підмережі — 255.255.255.0.
3) Основний шлюз — 192.168.1.254.

На даній настройці поки зупинимося і подивимося, як працює наша локальна мережа. Перекладаю CPT в режим симуляції. Припустимо, я сиджу за комп'ютером PC1, і потрібно перевірити доступність PC4 командою ping. Відкриваю командний рядок на PC1.

Як тільки натискаю клавішу ENTER на схемі з'являються 2 конверта.

Один з них ICMP, з яким працює сама команда ping. Відразу відкриваю його і дивлюся.

Бачу дані IP і ICMP. Тут немає нічого цікавого, за винятком декількох полів. А саме, цифра 4 у верхньому лівому куті даних IP, яка говорить про те, що використовується протокол IPv4. І 2 поля з IP-адреси джерела і призначення (SRC:192.168.1.1 і DST:192.168.1.4).
Але тут ping стикається з проблемою. Він не знає MAC-адресу одержувача. Тобто, адреса канального рівня. Для цього він використовує протокол ARP, який зможе опитати учасників мережі і дізнатися MAC-адресу. Ми про нього мимохіть говорили в попередній статті. Давайте поговоримо про нього докладніше. Не буду змінювати традиції. Картинку в студію!



1) Тип протоколу канального рівня (Hardware type). Думаю зрозуміло з назви, що тут вказується тип канального рівня. Ми поки розглядали тільки Ethernet. Його позначення в цьому полі — 0x0001.
2) Тип протоколу мережевого рівня (Protocol type). Тут, аналогічно, вказується тип мережного рівня. Код IPv4 — 0x0800.
3) Довжина фізичної адреси в байтах (Hardware length). Якщо це MAC-адресу, то розмір буде 6 байт (або 48 бітів).
4) Довжина логічного адреси в байтах (Protocol length). Якщо це IPv4-адресу, то розмір буде 4 байти або 32 біта).
5) Код операції (Operation). Код операції відправника. Якщо це запит, то код 0001. У разі відповіді — 0002.
6) Фізичну адресу відправника (Sender hardware address). MAC-адреса відправника.
7) Логічний адресу відправника (Sender protocol address). IP-адреса відправника.
8) Фізичний адресу одержувача (Target hardware address). MAC-адресу одержувача. Якщо це запит, то, як правило, адреса невідомий і це поле залишається порожнім.
9) Логічний адресу одержувача (Target protocol address). IP-адреса відправника.

Тепер, коли ми знаємо, з чого він складається, можна подивитися на його роботу в CPT. Клікаю по другому конверту і спостерігаю наступну картину.

І ось протокол ARP у всій красі. На 2-му рівні працює протокол Ethernet. Зупинимося і подивимося на його поля.
1) Преамбула — тут бітова послідовність, яка говорить про початок кадру.
2) Далі йде MAC-адресу джерела і одержувача. В адресі джерела записаний MAC-адресу комп'ютера, який є ініціатором, а в адресі одержувача записаний широкомовна адреса FF-FF-FF-FF-FF-FF (тобто для всіх вузлів в канальної середовищі).
3) Тип — тут вказаний вищестоящий протокол. Код 0x806 означає, що вище стоїть ARP. Я, якщо чесно, не можу точно сказати, на якому рівні він працює. У різних джерелах вказано по-різному. Хтось каже, що на 2-му рівні OSI, а хтось каже, що на 3-му. Я вважаю, що він між ними працює. Так як тут є адреси, властиві кожному з рівнів.
Про дані і чек-суму багато говорити не буду. Дані тут ніяк не вказані, а чек-сума нульова.

Піднімаємося трохи вище і тут протокол ARP.
1) Hardware Type — код канального рівня. CPT прибрала зайві нулі і вставила 0x1 (теж, що і 0x0001). Це Ethernet.
2) Protocol Type — код мережевого рівня. 0x800 — це IPv4.
3) HLEN — довжина фізичної адреси. 0x6 означає 6 байт. Все вірно (MAC-адресу займає 6 байт).
4) PLEN — довжина мережевого адреси. 0x4 означає 4 байти (IP-адреса займає 4 байти).
5) OPCODE — код операції. 0x1 означає, що це запит.
6) Source Mac — тут MAC-адреса відправника. Можна порівняти її з адресою в полі протоколу Ethernet і переконатися в правильності.
7) Source IP — IP-адреса відправника.
8) Target MAC — так як це запит і канальний адресу не відомий, то він порожній. CPT показала його нулями, що рівносильно.
9) Target IP — IP-адресу одержувача. Як раз той адреса, який пингуем.

Подивимося, що буде відбуватися далі в мережі.

Протокол ARP опитує всі хости у локальній мережі і тільки один відповідає на цей запит. Це PC4. Подивимося, чим він відповість.

Ось він випльовує щось на комутатор. Відкриваю його і бачу деякі зміни, а саме:
1) В поле джерела протоколу Ethernet тепер записаний MAC-адресу PC4, а в полі призначення MAC-адреса ініціатора, тобто PC1.
2) В поле OPCODE тепер значення 0x2, тобто відповідь.
3) Помінялися поля логічних і фізичних адрес в протоколі ARP. Source MAC і Destination MAC аналогічні тим, що в протоколі Ethernet. У полі Source IP — адреса 192.168.1.4 (PC4), а в полі Destination IP — адресу 192.168.1.1 (PC1).

Як тільки ця інформація досягне PC1, він відразу формує ICMP-повідомлення, тобто ping.

Відкриваю його і дивлюся. Це блок даних, що складається з 3-х протоколів: Ethernet, IP і Ping.
1) В Ethernet протоколі нічого нового, а саме MAC-адреса відправника — PC1, MAC-адресу одержувача — PC4, а в полі Type — 0x800 (протокол IPv4)
2) В IP-протоколі, в полі Версія — 4, що означає протокол IPv4. IP-адреса відправника — PC1, а IP-адреса одержувача — PC4.
3) У ICMP протоколі, в полі Type — код 0x8 (ехо-запит).

Посилає він луна-запит, а я дивлюся, чим відповість PC4.

Перекосила у мене CPT, і довелося перезапустити його. Тільки тепер ICMP конверт не світло-зеленового кольору, а суміш зеленого і синього. Але це без різниці. Це одні і ті ж дані.
Ну що ж, дивлюся, ніж відповів PC4. Поля джерела і призначення в протоколах Ethernet і IP помінялися місцями. А в полі Type протоколу ICMP змінилося значення 0x8 на 0x0 (означає ехо-відповідь).
Судячи за логікою, як тільки ця відповідь досягне PC1, в консолі PC1 повинна з'явитися запис. Давайте перевіримо.

І дійсно. З'явився запис про доступність PC4, розмір даних (32 байти), затримка за часом (8 мс) і TTL або час життя (128). TTL показує, скільки маршрутизаторів подолав пакет. У мене пакет гуляв в межах локальної мережі, тому дане поле не змінилося.
За замовчуванням пінг відправляє 4 запиту. Отже, PC1 сформує ще 3 аналогічних ICMP. Показувати шлях кожного пакета я не буду, а наведу фінальний висновок консолі на PC1.

І як бачите, дійсно 4 відповіді. Зауважте, що перший прийшов із затримкою в 8 мс, а 3 останніх 4 мс. Це пов'язано з роботою протоколу ARP, так як спочатку PC1 не знав MAC-адресу PC4 і чекав, коли йому повідомлять. Хоча в CPT зустрічається ситуація, що у режимі реального часу, перший пакет взагалі втрачається. Особливо часто це проявляється, коли перевіряється доступність хоста, що знаходиться в іншій канальної середовищі.

Побачили ми, як працює передача даних в одній канальної середовищі. Тепер подивимося, що станеться, якщо хости опиняться в різних канальних середовищах або підмереж. Нагадаю, що мережа налаштована не до кінця. А саме, потрібно налаштувати маршрутизатор і другу підмережа. Чим зараз і займемося.
Відкриваю я комп'ютер з ім'ям PC5 і пропишу мережеві настройки.

Зауважте, що мережева адресація в першій канальної середовищі, була 192.168.1.X, а в 2-ій 192.168.2.X. При маски 255.255.255.0, це означає, що перші 3 октету фіксовані, а 4-ий октет в межах від 1 до 254. І так як у нас 3-ие октеты різняться, то це різні канальні середовища.

Наводжу налаштування PC6:
1) IP-адреса — 192.168.2.2
2) Маска підмережі — 255.255.255.0
3) Основний шлюз — 192.168.2.254

Хости у 2-ій канальної середовищі налаштовані і чудово працюють. Для того, щоб вони змогли спілкуватися з хостами з 1-ої канальної, потрібно налаштувати маршрутизатор, який з'єднує ці середовища. Маршрутизатор налаштовується через CLI (тобто в консольному вигляді) і простіше буде приводити сюди не скріншоти, а команди.

1) Router>enable — перехід в привілейований режим
2) Router#configure terminal перехід в режим глобальної конфігурації
3) Router(config)#interface fastEthernet 0/0 — переходимо до налаштування порту 0/0, який дивиться на першу канальну середу
4) Router(config-if)#ip address 192.168.1.254 255.255.255.0 — вішаємо на цей порт IP-адресу. Так як цей порт буде основним шлюзом для 1-ої канальної середовища, то вказуємо йому той IP, який прописали хостів
5) Router(config-if)#no shutdown — включаємо цей інтерфейс. За замовчуванням усі порти на цисковских маршрутизаторах вимкнені
6) Router(config-if)#exit — виходимо з режиму налаштування fastEthernet 0/0
7) Router(config)#interface fastEthernet 0/1 — переходимо до налаштування порту 0/1, який дивиться на другу канальну середу
8) Router(config-if)#ip address 192.168.2.254 255.255.255.0 — вішаємо сюди адресу, який буде основним шлюзом для хостів у 2-ій канальної середовищі
9) Router(config-if)#no shutdown — аналогічно включаємо його
10) Router(config-if)#end пишемо команду, яка відкине в привілейований режим
11) Router#copy running-config startup-config — зберігаємо налаштування в пам'яті маршрутизатора

На цьому етапі налаштування маршрутизатора закінчена. Трохи забіжу вперед і покажу корисну команду «show ip route». Вона показує всі відомі маршрутизатора мережі і маршрут до них.



Виходячи з цієї таблиці, можна впевнитися, що він знає і про 1-шу канальну середу, і про 2-шу. Відмінно. Залишилася справа за малим — перевірити доступність PC5 з PC1. Пробую. Перемикаю CPT в режим симуляції. Відкриваю командний рядок і пингую 192.168.2.1.

Як тільки натискаю ENTER, відразу з'являється 2 конверта: ICMP і ARP. Зупинимося і подивимося на них докладніше. Зараз може здатися, що передача між різними канальними середовищами нічим не відрізняється від передачі в одній канальної середовищі, але це не так. І зараз ви це побачите.
Спочатку подивимося на ICMP.

Тут поки що в принципі нічого цікавого. У полі джерела — IP-адреса PC1, а в полі призначення — IP-адреса PC5.
Що ж відбуватиметься далі. PC1 бачить, що перевіряється доступність хоста, що знаходиться в іншій канальної середовищі (шляхом накладення маски на свій IP-адресу і IP-адреса одержувача). І крім IP-адреси він не знає про одержувача нічого. Відповідно в такому вигляді надсилати пакет ICMP не можна. Зате він знає, що у нього є основний шлюз, який, швидше за все, знає щось про канальну середовище, в якому перебуває PC5. Але виникає ще одна складність. Він знає IP-адреса шлюзу (який я йому прописав в налаштуваннях), але не знає його MAC-адреси. Тут йому приходить на допомогу протокол ARP, який опитає всіх учасників канальної середовища і знайде його MAC-адресу. Подивимося, як заповнені поля.

На канальному рівні (протокол Ethernet): Поле джерела — MAC-адресу PC1, а в полі призначення — широкомовна адреса (тобто всім учасникам).
І трохи вище (протокол ARP):
1) SOURCE MAC — той же PC1, а DESTINATION MAC порожній (його повинен заповнити той, для кого цей запит призначений).
2) SOURCE IP — адреса PC1, а ось DESTINATION IP — адресу основного шлюзу.

Дивимося, що буде відбуватися далі.

3 комп'ютера відкинули пакет, і тільки маршрутизатор зрозумів, що це для нього. Дивимося, чим відповість.

Ethernet:
1) Source MAC — сюди він вставляє свій MAC-адресу (а саме MAC-адресу fastEthernet0/0).
2) Destination MAC — сюди записує MAC-адресу PC1 (тобто того, хто запросив).
ARP:
1) Source MAC і Destination MAC аналогічно записів у протоколі Ethernet.
2) Source IP — свій IP-адресу.
3) Target IP — IP-адреса PC1.

Йдемо далі.

Як тільки ARP доходить від маршрутизатора до PC1, то відразу PC1 відсилає ICMP повідомлення на маршрутизатор (або основний шлюз). І ось тут прошу звернути особливу увагу. А саме, на поля джерела і призначення (і в протоколі Ethernet, і в протоколі IP).
1) SRC MAC: тут вказано MAC-адресу PC1.
2) DEST MAC: MAC-адресу маршрутизатора.
3) SRC IP: IP-адреса PC1.
4) DST IP: IP-адреса PC5.
Що це значить. Адреси на мережевому рівні (тобто IP-адреси не міняються, щоб знати від кого й кому призначається інформація. А адреси на канальному рівні (MAC-адреси) можуть спокійно змінюватися, переходячи з однієї канальної середовища в іншу. Це дуже важливо зрозуміти і запам'ятати!

Дивимося, що відбувається. Пакет доходить до маршрутизатора і відразу перекреслюється. А все із-за того, що він не знає MAC-адресу PC5. Тепер він формує ARP-запит і намагається його дізнатися. Наводжу скріншот цього запиту.


Далі PC5 отримає його і сформує відповідь.


Як тільки ця відповідь дійде до маршрутизатора, він буде знати канальний адреса PC5. Але ось що сталося. Поки тривала тяганина з ARP у маршрутизатора і PC5, у PC1 спливає час очікування відповіді відправленого ICMP. Показую картинку.

Після закінчення часу очікування, він формує друге ICMP, відповідь якого вже дійде без проблем, так як MAC-адреси відомі. Слідом він сформує 3-тє і 4-е ICMP. Наводжу кінцевий підсумок.

І якщо уважно придивитися, то можна помітити, що TTL знизився на одиницю і тепер дорівнює 127. Це сталося через те, що пакет подолав один транзитний ділянку (маршрутизатор).

Ось таким чином працює передача даних з однієї канальної середовища в іншу або з однієї мережі в іншу). Тут, до речі, не важливо, скільки канальних середовищ вам треба буде подолати, щоб потрапити до одержувача. Принцип все одно буде такою.

В попередній статті, коли розглядалися протоколи верхнього рівня, ми трохи стосувалися транспортного рівня. Пропоную згадати цей рівень та міцно закріпити. Почну, як завжди, з простого. І це протокол UDP. Як я вже говорив вище, він використовується для того, щоб передати дані певного протоколу вищого рівня. Робить він це за допомогою портів. Один із протоколів, що працюють з UDP — це TFTP(Trivial File Transfer Protocol). Протокол цього ми розглядали в попередній статті. Тому труднощів виникнути не повинно. Для демонстрації потрібно додати в мережу сервер з включеною службою TFTP.

Налаштування сервера наступні:
1) IP-адреса — 192.168.1.5
2) Маска підмережі — 255.255.255.0
3) Основний шлюз — 192.168.1.254

TFTP Служба включена за замовчуванням, але краще перевірити.
Далі перемикаю CPT в режим симуляції і спробую зберегти конфігурацію маршрутизатора на TFTP-сервер:
1) Router>enable — перехід в привілейований режим.
2) Router#copy startup-config tftp: пишу команду copy (тобто скопіювати), далі startup-config (що саме скопіювати) і tftp: (куди скопіювати).
3) Address or name of remote host []? 192.168.1.5 виходить повідомлення із запитом адреси або імені сервера, де я пишу його адресу.
4) Destination filename [Router-confg]? — слідом він запитує, під яким ім'ям його зберегти на сервері і пропонує стандартне ім'я. Мене це влаштовує, і я тисну ENTER.

Відразу маршрутизатор формує 2 конверта. Один з них — це перекреслений TFTP, а другий ARP. Думаю, здогадалися, що перекреслений він із-за того, що не знає MAC-адресу сервера. Пропущу я момент роботи ARP, так як ми вдосталь на нього надивилися.

Давайте детальніше розберемо, що маршрутизатор відправляє на сервер.
Ethernet:
1) Source MAC — адресу маршрутизатора.
2) Destination MAC — адресу сервера.
3) Type — 0x800 (означає, що вище працює протокол IP).
IP:
1) Protocol — 0x11 (означає, що вище працює протокол UDP).
2) Source IP — адресу маршрутизатора.
3) Destination IP — адресу сервера.
UDP:
1) Source Port — динамічно створений порт (1025).
2) Destination Port — порт, який слухає TFTP-сервер (зарезервований 69 порт).
TFTP:
Тут знаходяться самі дані.

Так і працює протокол UDP. Він не встановлює сесії, не вимагає підтвердження доставки, а якщо щось загубиться, він не запитує повторно. Його робота — це вказати номер порту і відправити. Що там буде відбуватися далі, його не цікавить. Але виникають випадки, коли це не влаштовує і всі ці параметри критично важливі. Тоді на допомогу приходить протокол TCP. Розглянемо його на прикладі використання веб-сервера і веб-клієнта. Веб-сервером у нас буде той же TFTP-сервер. Включаємо службу HTTP і запитаємо сторінку з комп'ютера PC1. Не забуваємо переключити CPT в режим симуляції!

Набираю адреса веб-сервера і натискаю клавішу ENTER.

Перед тим як продовжити, я розповім про встановлення TCP-сесії. Постараюся викласти цей процес максимально просто. Цей процес називають «тристороннє рукостискання» або «handshake». В чому суть. Клієнт відправляє TCP-сегмент з прапором «SYN». Отримавши сегмент, сервер приймає рішення. Якщо він згоден встановити з'єднання, то він надсилає відповідний сегмент з прапором «SYN+ACK». Якщо не згоден, то відправляє сегмент з прапором «RST». Далі клієнт дивимося на відповідний сегмент. Якщо там стоїть прапор «SYN+ACK», то він у відповідь надсилає сегмент з прапором «ACK» і встановлюється з'єднання. Якщо ж там стоїть прапор «RST», то він припиняє спроби з'єднання. Після того, як потрібно розірвати стале з'єднання, клієнт формує і посилає TCP-сегмент з прапором «FIN+ACK». Сервер на цей сегмент відповідає аналогічним прапором «SYN+ACK». І нарешті, клієнт відправляє останній TCP-сегмент з прапором «ACK». Зараз ви побачите, як це працює на практиці.

Перемикаю увагу на мережу і бачу, як PC1 формує TCP-сегмент.

Поля протоколів Ethernet і IP я розглядати не буду, так як тут нічого нового, за винятком поля Protocol у протоколі IP. Там стоїть значення — 0x6. Це говорить про те, що вище використовується протокол TCP.
А ось в TCP вже цікавіше.
1) Source Port — 1025 (це динамічно згенерований порт веб-клієнта).
2) Destination Port — 80 (це зарезервований порт протоколу HTTP).
3) Flag — SYN (запит на встановлення сесії)

Дивимося, чим відповість веб-сервер.

Змінює він номери портів місцями і відправляє сегмент з прапором «SYN+ACK»

Як тільки клієнт отримує цей сегмент, він відразу формує 2 повідомлення. Один з них TCP-сегмент, представлений нижче, який відправляється з прапором «ACK»


А другий — HTTP, де вказана версія протоколу, яка сторінка і адресу сервера.

Його робота була представлена в попередній статті. Тому не буду повторюватися. Покажу тепер закриття сесії.

Як тільки клієнт отримує бажану сторінку, йому більше немає сенсу підтримувати з'єднання і він ініціює розрив. Відправляє сегмент з прапором «FIN+ACK». Дивимося далі.

Сервер згоден розірвати з'єднання і у відповідь надсилає сегмент з аналогічним прапором «FIN+ACK».

І нарешті, клієнт формує останній TCP-сегмент з прапором «ACK» і закриває з'єднання.

Ми розглянули, як працює протокол TCP, а разом з ним закінчили розглядати протоколи нижніх рівнів. Наводжу посилання на скачування даної лаби. Спочатку була у мене ідея піти стандартно прокладеним шляхом, і писати під кожен рівень окрему статтю, але потім зрозумів, що робити це безглуздо. Так як до моменту написання наступної статті, більша частина попередньої забувається.
Ну що ж, стаття підходить до кінця. Хочу висловити подяку користувачу під ніком remzalp за надану картинку і іншим користувачам, які залишають корисні коментарі до статей. Дуже приємно бачити, як люди цікавляться, запитують, ведуть об'єктивні і конструктивні суперечки. Хочеться, щоб російськомовне IT-співтовариство все більше розвивалося і матеріалів для вивчення у вільному доступі ставало все більше. Спасибі за прочитання і до зустрічі на наступному.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.