Первая страница
Наша команда
Контакты
О нас

    Головна сторінка



Пояснювальна записка до навчальної дисципліни 6 Тематичний план на поточний навчальний рік

Пояснювальна записка до навчальної дисципліни 6 Тематичний план на поточний навчальний рік




Сторінка8/16
Дата конвертації10.03.2017
Розмір3.64 Mb.
ТипПояснювальна записка
1   ...   4   5   6   7   8   9   10   11   ...   16
ТЕМА №4. Мережі TCP/IP

З навчальної дисципліни: “Комп’ютерні мережі та телекомунікаційні технології”

Категорія слухачів: курсанти

Навчальна мета: надати знання щодо загальної характеристики стека протоколів TCP/IP, методів адресації в мережах TCP/IP, протоколу міжмережної взаємодії та базових протоколів мереж TCP/IP

Виховна мета: вивчити коректність поведінки при роботі з комп’ютерними та програмними засобами, використання в практичній діяльності законообгрунтованої термінології, пов’язаної з інформаційними відносинами в суспільстві

Розвивальна мета: підвищити інтелектуальний рівень курсанта, розширити світогляд щодо можливостей, напрямів та законності використання досягнень інформаційних технологій в правоохоронній діяльності

Навчальний час: 2 години

Навчальне обладнання, ТЗН: персональний комп’ютер (ноутбук), мультимедійний проектор

Наочні засоби: спеціальна презентація за темою лекції

Міжпредметні та міждисциплінарні зв’язки: забезпечуючі дисципліни – «Інформатика»;

забезпечувані дисципліни – «Комп’ютерна розвідка», «Інформаційна безпека», «Захист інформації в інформаційно телекомунікаційних системах»

План лекції (навчальні питання):

1. Загальна характеристика стека протоколів TCP/IP.

2. Адресація в мережах TCP/IP.

3. Протокол міжмережної взаємодії.

4. Базові протоколи мереж TCP/IP.
Література:

  1. Фред Халсалл. Передача данных, сети компьютеров и взаимосвязь открытых систем. — М.: Радио и связь, 1995.

  2. Столлиигс В. Передача данных. — 4-е изд. СПб.: Питер, 2004.

  3. Столлиигс В. Современные компьютерные сети, 2-е изд. — СПб.: Питер, 2003.

  4. Куроуз Дж.у Росс К. Компьютерные сети, 4-е изд. — СПб.: Питер, 2004.

  5. Таиеибаум Э. Компьютерные сети, 4-е изд. — СПб.: Питер, 2002.

  6. Фейт Сидни. ТСР/ІР. Архитектура, протоколы, реализация. — М.: Лори, 2000.

  7. Стивен Браун. Виртуальные частные сети. — М.: Лори, 2001.

  8. Шринивас Вегешиа. Качество обслуживания в сетях ІР. — М.:Вильямс, 2003.

  9. Дуглас Э. Камер. Сети ТСР/ІР. Том 1. Принципы, протоколы и структура. — М.:Вильяме, 2003.

  10. Блэк Ю. Сети ЭВМ: протоколы стандарты, интерфейсы/Перев. с англ. - М.: Мир, 1990.

  11. Ричард Стивене. Протоколы ТСР/ІР. Практическое руководство. — Спб.: БХВ, 2003.

  12. Слепов Н.Я . Синхронные цифровые сети SDN. М.: Эко-Трендз, 1998.

  13. Уолрэпд Дж. Телекоммуникационные и компьютерные сети. Вводный курс. — М.: Постмаркет, 2001.

  14. Гольдштейи Б. С., Пинчук А. В., Суховицкий А. Л. ІР-телефония. — Радио и связь, 2001.

  15. Олифер В. Г., Олифер Н. А. Новые технологии и оборудование ІР-сетей. — СПб.: БХВ-Санкт-Петербург, 2000.

  16. Олифер В. Г., Олифер Н. А. Сетевые операционные системы. 2-е изд. СПб.: Питер, 2008.

  17. Олифер В. Г., Олифер Н. А. Компьютерные сети. Принципы, технологии, протоколы: Учебник для ВУЗов. 4-е изд.- СПб.: Питер, 2011.

  18. Телекомунікаційні та інформаційні мережі: Підручник для вищіх навчальних закладів./ П.П.Воробієнко, Л.А.Нікітюк, П.І.Резніченко. – К.: САММІТ-КНИГА, 2010.

  19. Бройдо В.Л., Ильина О.П. Вычислительные системы, сети и телекоммуникации: Учебник для вузов. 4-е изд. – СПб.: Питер, 2011.


КОНСПЕКТ ЛЕКЦІЇ
Питання 1. Сьогодні стек TCP/IP широко використовується як в глобальних, так і в локальних мережах.

Цей стек має ієрархічну структуру, в якій визначено 4 рівні (рис. 4.1).



Прикладний рівень

FTP, Telnet, HTTP, SMTP, SNMP, TFTP

Транспортний рівень

TCP, UDP

Мережевий рівень

IP, ICMP, RIP, OSPF

Рівень мережевих інтерфейсів

He регламентується

Рис. 4.1. Ієрархічна структура стека TCP/IP



Прикладний рівень стека TCP/IP відповідає трьом верхнім рівням моделі OSI: прикладному, представлення і сеансовому. Він об'єднує сервіси, що надаються системою призначеним для користувача застосованням. За довгі роки застосовання в мережах різних країн і організацій стек TCP/IP накопив велику кількість протоколів і служб прикладного рівня. До них відносяться такі поширені протоколи, як протокол передачі файлів (File Transfer Protocol, FTP), протокол емуляції терміналу telnet, простий протокол передачі пошти (Simple Mail Transfer Protocol, SMTP), протокол передачі гіпертексту (Hypertext Transfer Protocol, HTTP) і багато інших. Протоколи прикладного рівня розгортаються на хостах.

Транспортний рівень стека TCP/IP може надавати вищерозміщеному рівню два типи сервісу :

  • гарантовану доставку забезпечує протокол управління передачею (Transmission Control Protocol, TCP);

  • доставку по можливості, або з максимальними зусиллями, забезпечує протокол призначених для користувача дейтаграмм (User Datagram Protocol, UDP).

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

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

У функції протоколів TCP і UDP входить також виконання ролі сполучної ланки між прилеглими до транспортного рівня прикладним і мережевим рівнями. Від прикладного протоколу транспортний рівень приймає завдання на передачу даних з тією або іншою якістю прикладному рівню - одержувачеві. Мережевий рівень, що пролягає нижче, протоколи TCP і UDP розглядають як свого роду інструмент, не дуже надійний, але здатний переміщати пакет у вільній і ризикованій подорожі по складеній мережі.

Програмні модулі, що реалізовують протоколи TCP і UDP, подібно до модулів протоколів прикладного рівня, встановлюються на хостах.



Мережевий рівень, що називається також рівнем Інтернету, є стержнем усієї архітектури TCP/IP. Саме цей рівень, функції якого відповідають мережевому рівню моделі OSI, забезпечує переміщення пакетів в межах складеної мережі, утвореної об'єднанням декількох підмереж. Протоколи мережевого рівня підтримують інтерфейс з вищерозміщеним транспортним рівнем, отримуючи від нього запити на передачу даних по складеній мережі, а також з рівнем мережевих інтерфейсів, що пролягає нижче, про функції якого ми розповімо далі.

Основним протоколом мережевого рівня є міжмережевий протокол (Internet Protocol, IP). У його завдання входить просування пакету між мережами — від одного маршрутизатора до іншого до тих пір, поки пакет не потрапить в мережу призначення. На відміну від протоколів прикладного і транспортного рівнів, протокол IP розгортається не лише на хостах, але і на усіх маршрутизаторах (шлюзах). Протокол IP — це дейтаграммный протокол, працюючий без встановлення з'єднань за принципом доставки з максимальними зусиллями. Такий тип мережевого сервісу називають також «ненадійним».

До мережевого рівня TCP/IP часто відносять протоколи, що виконують допоміжні функції по відношенню до IP. Це, передусім, протоколи маршрутизації RIP і OSPF, призначені для вивчення топології мережі, визначення маршрутів і складання таблиць маршрутизації, на підставі яких протокол IP переміщає пакети в потрібному напрямі. З цієї ж причини до мережевого рівня можуть бути віднесені управлінський протокол міжмережевих повідомлень (Internet Control Message Protocol, ICMP) призначений для передачі маршрутизатором джерелу відомостей про помилки, що виникли при передачі пакету, і деякі інші протоколи.

Ідеологічною відмінністю архітектури стека TCP/IP від багаторівневої архітектури інших стеків є інтерпретація функцій самого нижнього рівня — рівня мережевих інтерфейсів.

Нагадаємо, що нижні рівні моделі OSI (канальний і фізичний) реалізують безліч функцій доступу до середовища передачі, формування кадрів, узгодження величин електричних сигналів, кодування і синхронізації, а також деякі інші. Усі ці дуже конкретні функції складають суть таких протоколів обміну даними, як Ethernet, РРР і багатьох інших.

У нижнього рівня стека TCP/IP завдання істотно простіше. Він відповідає тільки за організацію взаємодії з підмережами різних технологій, що входять в складену мережу. TCP/IP розглядає будь-яку підмережу, що входить в складену мережу, як засіб транспортування пакетів між двома сусідніми маршрутизаторами.

Завдання організації інтерфейсу між технологією TCP/IP і будь-якою іншою технологією проміжної мережі спрощено можна звести до двох завдань:


  • упаковка (інкапсуляція) IP -пакета в одиницю передаваних даних проміжної мережі;

  • перетворення мережевих адрес в адреси технології цієї проміжної мережі.

Такий гнучкий підхід спрощує вирішення проблеми розширення набору підтримуваних технологій. При появі нової популярної технології вона швидко включається в стек TCP/IP шляхом розробки відповідного стандарту, що визначає метод інкапсуляції IP -пакетів в її кадри (наприклад, специфікація RFC 1577, що визначає роботу протоколу IP через мережі ATM, з'явилася в 1994 році незабаром після прийняття основних стандартів ATM). Оскільки для кожної нової технології, що створюється, розробляються власні інтерфейсні засоби, функції цього рівня не можна визначити раз і назавжди, і саме тому нижній рівень стека TCP/IP не регламентується.

Кожен комунікаційний протокол оперує деякою одиницею передаваних даних. Назви цих одиниць іноді закріплюються стандартом, а частіше просто визначаються традицією.



Потоком даних, інформаційним потоком, або просто потоком, називають дані, що поступають від застосовань на вхід протоколів транспортного рівня — TCP і UDP.

Протокол TCP «нарізує» з потоку даних сегменти.

Одиницю даних протоколу UDP часто називають дейтаграмою, або датаграмою. Дейтаграма — ця загальна назва для одиниць даних, якими оперують протоколи без встановлення з'єднань. До таких протоколів відноситься і протокол IP, тому його одиницю даних іноді теж називають дейтаграмою, хоча досить часто використовується і інший термін — пакет.

У стеку TCP/IP одиниці даних будь-яких технологій, в які упаковуються IP -пакети для їх подальшої передачі через мережі складеної мережі, прийнято називати також кадрами, або фреймами. При цьому не має значення, яка назва використовується для цієї одиниці даних в технології підмережі. Для TCP/IP фреймом є і кадр Ethernet, і комірка ATM, і пакет Х.25 в тих випадках, коли вони виступають контейнером, в якому IP -пакет переноситься через складену мережу.


Питання 2. Для ідентифікації мережевих інтерфейсів використовуються три типи адрес:

локальні (апаратні) адреси;

мережеві адреси (IP-адреси);

символьні (доменні) імена.



Локальні адреси

Слово «локальний» в контексті TCP/IP означає те, що «діє не у всій складеній мережі, а лише в межах підмережі». Саме у такому сенсі розуміються тут терміни: «локальна технологія» (технологія, на основі якої побудована підмережа), «локальна адреса» (адреса, яка використовується деякою локальною технологією для адресації вузлів в межах підмережі). Нагадаємо, що як підмережа («локальна мережа») може виступати мережа, побудована як на основі локальної технології, наприклад Eternet; FDDI, так і на основі глобальної технології, наприклад Х.25, Frame Relay. Отже, кажучи про підмережу, ми використовуємо слово «локальна» не як характеристику технології, на якій побудована ця підмережа, а як вказівку на роль, яку грає ця підмережа в архітектурі складеної мережі.

Складнощі можуть виникнути і при інтерпретації визначення «апаратний». В даному випадку термін «апаратний» підкреслює концептуальне уявлення розробників стека TCP/IP про підмережу як про деякий допоміжний апаратний засіб, єдиною функцією якого є переміщення IР-пакета через підмережу до найближчого шлюзу (маршрутизатора). І не важливо, що реально локальна технологія, яка пролягає нижче, може бути достатнє складною, всі її складнощі ігноруються технологією TCP/IP.

Мережеві IР-адреси

Щоб технологія TCP/IP могла вирішувати свою задачу об'єднання мереж, їй необхідна власна глобальна система адресації, не залежна від способів адресації вузлів в окремих мережах. Ця система адресації повинна дозволяти універсальним і однозначним способом ідентифікувати будь-який інтерфейс складеної мережі. Очевидним рішенням є унікальна нумерація всіх мереж складеної мережі, а потім нумерація всіх вузлів в межах кожної з цих мереж. Пара, що складається з номера мережі і номера вузла, відповідає поставленим умовам і може служити як мережева адреса.

У технології TCP/IP мережеву адресу називають IР-адресою.

Основною аксиомою ІР-адресації є необхідність дотримання унікальності ІР-адрес у всьому просторі мережі, оскільки, перш за все, цим забезпечується коректність доставки даних і маршрутизації. Закріплюють ІР-адресу комп’ютера або вручну (статична адреса), або комп’ютер отримує її автоматично з серверу (динамічна адреса).

Перш ніж відправити пакет до наступної мережі, маршрутизатор повинен визначити на підставі знайденої IР-адреси наступного маршрутизатора його локальну адресу. Для цієї мети протокол IР звертається до протоколу розв’язання адрес (АRР).

Розглянемо IР-мережу. Маршрутизатор за визначенням входить відразу в декілька мереж, отже, кожен його інтерфейс має власну IР-адресу. Кінцевий вузол також може входити в декілька IР-мереж. В цьому випадку комп'ютер повинен мати декілька IР-адрес, по числу мережевих зв'язків. Таким чином, IР-адреса ідентифікує не окремий комп'ютер або маршрутизатор, а одне мережеве з'єднання.



Формат IР-адреси

У заголовку IР-пакету для зберігання IР-адрес відправника і одержувача відводяться два поля, кожне має фіксовану довжину 4 байти (32 біта). IР-адреса складається з двох логічних частин — номера мережі і номера вузла в мережі.

Найбільш поширеною формою представлення IР-адреси є запис у вигляді чотирьох чисел, що представляють значення кожного байта в десятковій формі і розділених крапками, наприклад:

128.10.2.30

Ця ж адреса може бути представленою в двійковому форматі: 10000000 00001010 00000010 00011110 і в шістнадцятиричному форматі:80.0А.02.1D.

Відмітимо, що запис адреси не передбачає спеціального розмежувального знаку між номером мережі і номером вузла. Разом з тим при передачі пакету по мережі часто виникає необхідність розділити адресу на ці дві частини. Наприклад, маршрутизація, як правило, здійснюється на підставі номера мережі, тому кожен маршрутизатор, отримуючи пакет, повинен прочитати з відповідного поля заголовка адресу призначення і виділити з нього номер мережі. Яким чином маршрутизатори визначають, яка частина з 32 біт, відведених під IР- адресу, відноситься до номера мережі, а яка — до номера вузла?

Існує декілька варіантів вирішення цієї проблеми.

Простіший з них полягає у використанні фіксованої межі. При цьому все 32-бітове поле адреси заздалегідь ділиться на дві частини не обов'язково рівної, але фіксованої довжини, в одній з яких завжди розміщуватиметься номер мережі, а в іншій — номер вузла. Рішення дуже просте, але чи хороше? Оскільки поле, яке відводиться для зберігання номера вузла, має фіксовану довжину, всі мережі матимуть однакове максимальне число вузлів. Якщо, наприклад, під номер мережі відвести один перший байт, то весь адресний простір розпадеться на порівняно невелике (28) число мереж величезного розміру (224 вузлів). Якщо межу пересунути далі управо, то мереж стане більше, але все одно всі вони будуть однакового розміру. Очевидно, що такий жорсткий підхід не дозволяє диференційовано задовольняти потреби окремих підприємств і організацій. Саме тому він не знайшов широкого застосування, хоча і використовувався на початковому етапі існування технології TCP/IP (RFC 760).

Другий підхід (RFC 950, RFC 1518) заснований на використанні маски, яка дозволяє максимально гнучко встановлювати межу між номером мережі і номером вузла. При такому підході адресний простір можна використовувати для створення безлічі мереж різного розміру.

Маска це число, вживане в парі з IР-адресою, причому двійковий запис маски містить безперервну послідовність одиниць в тих розрядах, які повинні в IР-адресі інтерпретуватися як номер мережі. Межа між послідовностями одиниць і нулів в масці відповідає межі між номером мережі і номером вузла в IР-адресі.

І, нарешті, найбільш поширений до недавнього часу спосіб вирішення даної проблеми полягає у використанні класів адрес (RFC 791). Цей спосіб представляє собою компроміс по відношенню до двох попередніх: розміри мереж хоч і не можуть бути довільними, як при використанні масок, але і не повинні бути однаковими, як при встановленні фіксованих границь. Вводяться п’ять класів адрес: A, B, C, D, E. Три з них – A, B, C – призначені для адресації мереж, а два – D, E – мають спеціальне призначення. Для кожного классу мережних адрес визначене власне розміщення границі між номером мережі та номером вузла.




Таблиця 4.1. Класи IР-адрес

Клас

Перші біти

Найменший номер мережі

Найбільший номер мережі

Максимальне число вузлів в мережі

А

0

1.0.0.0(0 — не використовується)

126.0.0.0(127—зарезервований)

224, поле 3 байти

B

10

128.0.0.0

191.255.0.0

216, поле 2 байти

C

110

192.0.0.0

223.255.255.0

28, поле 1 байт

D

1110

224.0.0.0

239.255.255.255

Групові адреси

E

11110

240.0.0.0

247.255.255.255

Зарезервовано




Ознакою, на підставі якої IР-адрес відноситься до того або іншого класу, є значення декількох перших бітів адреси. Таблиця 4.1 ілюструє структуру IР-адрес різних класів.

До класу А відноситься адреса, в якій старший біт має значення 0. У адресах класу А під ідентифікатор мережі відводиться 1 байт, а останні 3 байти інтерпретуються як номер вузла в мережі. Мережі, всі IР-адреси яких мають значення першого байта в діапазоні від 1 (00000001) до 126 (01111110), називаються мережами класу А. Значенння 0 (00000000) першого байта не використовується, а значення 127 (01111111) зарезервовано для спеціальних цілей, про що буде розказано далі. Мереж класу А порівняно небагато, зате кількість вузлів в них може досягати 224, тобто 16 777 216 вузлів.

До класу В відносяться всі адреси, старші два бiта яких мають значення 10. У адресах класу В під номер мережі і під номер вузла відводиться по два байти. Мережі, значення перших двох байтів адрес яких знаходяться в діапазоні від 128.0. (10000000 00000000) до 191.255 (10111111 11111111), називаються мережами класу B. Ясно, що мереж класу В більше, ніж мереж класу А, а розміри їх менше. Максимальна кількість вузлів в мережах класу В складає 216 (65 536).

До класу C відносяться всі адреси, старші три бiта яких мають значення 110. У адресах класу C під номер мережі відводиться 3 байти, а під номер вузла — 1 байт. Мережі, старші три байти яких знаходяться в діапазоні від 192.0.0 (11000000 00000000 00000000) до 223.255 (11011111 11111111 11111111), називаються мережами класу С. Мережі класу C найбільш поширені і мають найменше максимальне число вузлів — 28 (256).

Якщо адреса починається з послідовності 1110, то він є адресою класу D і позначає особливу, групову адресу (multicast adress). Тоді як адреси класів А, В і C використовуються для ідентифікації окремих мережевих інтерфейсів, тобто є індивідуальними адресами (unicast adress), групова адреса ідентифікує групу мережевих інтерфейсів, які в загальному випадку можуть належати різним мережам. Інтерфейс, що входить до групи, отримує разом із звичайною індивідуальною IР -адресою ще одну групову адресу. Якщо при відправці пакету як адреса призначення вказана адреса класу D, то такий пакет повинен бути доставлений всім вузлам, які входять до групи.

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

Щоб отримати з IР-адреси номер мережі і номер вузла, потрібно не тільки розділити адресу на дві відповідні частини, але і доповнити кожну з них нулями до повних 4 байт. Візьмемо, наприклад, адресу класу В 129.64.134.5. Перші два байти ідентифікують мережу, а подальші два — вузол. Таким чином, номером мережі є адреса 129.64.0.0, а номером вузла — адреса 0.0.134.5.

У TCP/IP існують обмеження при призначенні IР-адрес, а саме номери мереж і номера вузлів не можуть складатися з одних двійкових нулів або одиниць. Звідси витікає, що максимальна кількість вузлів, приведена в табл. 4.1 для мереж кожного класу, повинна бути зменшеною на 2. Наприклад, в адресах класу С під номер вузла відводиться 8 біт, які дозволяють задавати 256 номерів: від 0 до 255. Проте насправді максимальне число вузлів в мережі класу С не може перевищувати 254, оскільки адреси 0 і 255 заборонені для адресації мережевих інтерфейсів. З цих же міркувань виходить, що кінцевий вузол не може мати адреси типу 98.255.255.255, оскільки номер вузла в цій адресі класу А складається з одних двійкових одиниць.

Отже, деякі IР-адреси інтерпретуються особливим чином.

Якщо IР -адреса складається тільки з двійкових нулів, то він називається невизначеною адресою і позначає адресу того вузла, який згенерував цей пакет. Адреса такого вигляду в особливих випадках поміщається в заголовок IР-пакету в полі адреси відправника.

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

Якщо всі двійкові розряди IР-адреси дорівнюють 1, то пакет з такою адресою призначення повинен розсилатися всім вузлам, що знаходяться в тій же мережі, що і джерело цього пакету. Така адреса називається обмеженою широкомовною (limited broadcast). Обмеженість в даному випадку означає, що пакет не вийде за межі даної мережі ні за яких умов.

Якщо в полі адреси призначення в розрядах, відповідних номеру вузла, стоять тільки одиниці, то пакет, що має таку адресу, розсилається всім вузлам мережі, номер якої вказаний в адресі призначення. Наприклад, пакет з адресою 192.190.21.255 буде направлений всім вузлам мережі 192.190.21.0. Такий тип адреси називається широкомовним (broadcast). У протоколі IР немає поняття широкомовлення в тому сенсі, в якому воно використовується в протоколах канального рівня локальних мереж, коли дані повинні бути доставлені абсолютно всім вузлам мережі. Як обмежений, так і звичайний варіанти широкомовної розсилки мають межі розповсюдження в складеній мережі — вони обмежені або мережею, якій належить джерело пакету, або мережею, номер якої вказаний в адресі призначення. Тому ділення мережі за допомогою маршрутизаторів на частини локалізує широкомовний шторм межами однієї з підмереж просто тому, що немає способу адресувати пакет одночасно всім вузлам всіх мереж складеної мережі.

Особливий сенс має IР -адреса, перший октет якої дорівнює 127. Ця адреса є внутрішньою адресою стека протоколів комп'ютера (або маршрутизатора). Він використовується для тестування програм, а також для організації роботи клієнтської і серверної частин додатку, встановлених на одному комп'ютері. Обидві програмні частини даного додатку спроектовано з розрахунку на те, що вони обмінюватимуться повідомленнями по мережі. Але яку ж IР-адресу вони повинні використовувати для цього? Адресу мережевого інтерфейсу комп'ютера, на якому вони встановлені? Але це приводить до надмірних передач пакетів в мережу. Економічним рішенням є застосування внутрішньої адреси 127.0.0.0. У IР-мережі забороняється привласнювати мережевим інтерфейсам IР- адреси, що починаються з 127. Коли програма посилає дані на IР-адресу 127.х.х.х, то дані не передаються в мережу, а повертаються модулям верхнього рівня того ж комп'ютера як тільки що прийняті. Маршрут переміщення даних утворює «петлю», тому ця адреса називається адресою зворотної петлі (loopback).

Групові адреси, що відносяться до класу D, призначені для економічного розповсюдження в Інтернеті або великій корпоративній мережі аудио-або відеопрограм, адресованих відразу великій аудиторії слухачів або глядачів. Якщо групова адреса поміщена в поле адреси призначення IР-пакета, то даний пакет повинен бути доставлений відразу декільком вузлам, які утворюють групу з номером, вказаним в полі адреси. Один і той же вузол може входити в декілька груп. У загальному випадку члени групи можуть розподілятися по різних мережах, що знаходяться один від одного на довільно великій відстані.

Групова адреса не ділиться на номери мережі і вузла і обробляється маршрутизатором особливим чином. Основне призначення групових адрес — розповсюдження інформації по схемі «один до багатьох». Від того, знайдуть групові адреси широке застосування (зараз їх використовують в основному невеликі експериментальні «острівці» в Інтернеті), залежить, чи зможе Інтернет створити серйозну конкуренцію радіо і телебаченню.

Забезпечуючи кожну IР-адресу маскою, можна відмовитися від понять класів адрес і зробити гнучкішою систему адресації.

Хай, наприклад, для IР-адреси 129.64.134.5 вказана маска 255.255.128.0, тобто в двійковому вигляді ІР-адреса 129.64.134.5 — це:

10000001.01000000.10000110.00000101,

а маска 255.255.128.0 - це:

11111111.11111111.10000000.00000000. Якщо ігнорувати маску і інтерпретувати адресу 129.64.134.5 на основі класів, то номером мережі є 129.64.0.0, а номером вузла — 0.0.134.5 (оскільки адреса відноситься до класу В).

Якщо ж використовувати маску, то 17 послідовних двійкових одиниць в масці 255.255.128.0, «накладені» на IР-адресу 129.64.134.5, ділять його на дві частини:

номер мережі: 10000001.01000000.1;

номер вузла: 0000110.00000101.

У десятковій формі запису номери мережі і вузла, доповнені нулями до 32 біт, виглядають, відповідно, як 129.64.128.0 і 0.0.6.5.

Для запису масок використовуються і інші формати. Наприклад, зручно інтерпретувати значення маски, записаної в шістнадцятиричному коді: FF.FF.00.00 — маска для адрес класу В. Ще частіше зустрічається і таке позначення 185.23.44.206/16 — цей запис говорить про те, що маска для цієї адреси містить 16 одиниць або що у вказаній IР-адресі під номер мережі відведено 16 двійкових розрядів.



Доменні імена

Для ідентифікації комп'ютерів апаратне і програмне забезпечення в мережах TCP/IP покладається на IР-адреси. Наприклад, команда ftp://192.45.66.17 встановлюватиме сеанс зв'язку з потрібним ftp-сервером, а команда http://203.23.106.33 відкриє початкову сторінку на корпоративному веб-сервері. Проте користувачі зазвичай вважають за краще працювати із зручнішими символьними іменами комп'ютерів.

Символьні ідентифікатори мережевих інтерфейсів в межах складеної мережі будуються за ієрархічною ознакою. Складові повного символьного (або доменного) імені в IР -мережах розділяються крапкою і перераховуються в наступному порядку: спочатку просте ім'я хоста, потім ім'я групи хостов (наприклад, ім'я організації), потім ім'я крупнішої групи (домена) і так до імені домена самого високого рівня (наприклад, домена, об'єднуючого організації за географічним принципом: RU — Росія, UK — Великобританія, US — США). Прикладом доменного імені може служити ім'я base2.sales.zil.ru.

Між доменним ім'ям і IР-адресою вузла немає ніякої функціональної залежності, тому єдиний спосіб встановлення відповідності — це таблиця. У мережах TCP/IP використовується спеціальна система доменних імен (Domian Name System,DNS), яка встановлює цю відповідність на підставі створюваних адміністраторами мережі таблиць відповідності. Тому доменні імена називають також DNS-именами.

У загальному випадку мережевий інтерфейс може мати декілька локальних адрес, мережевих адрес, доменних імен.

Схема роботи DNS

Широкомовний спосіб встановлення відповідності між символьними іменами і локальними адресами, подібний до протоколу ARP, добре працює тільки в невеликій локальній мережі, не розділеній на підмережі. У крупних мережах, де можливість загальної широкомовної розсилки не підтримується, потрібний інший спосіб дозволу символьних імен. Хорошою альтернативою широкомовній розсилці є застосування централізованої служби, що підтримує відповідність між різними типами адрес всіх комп'ютерів мережі. Наприклад, компанія Microsoft для своєї корпоративної операційної системи WindowsNT розробила централізовану службу WINS, яка підтримувала базу даних NetBIOS-імен і відповідних ним IР-адрес.

У мережах TCP/IP відповідність між доменними іменами і IР-адресами може встановлюватися засобами як локального хоста, так і централізованої служби.

На ранньому етапі розвитку Інтернету на кожному хості уручну створювався текстовий файл з відомим ім'ям hosts.txt. Цей файл складався з деякої кількості рядків, кожен з яких містив одну пару «доменне ім'я — IР-адреса», наприклад:

rhino.acme.com — 102.54.94.97.

По мірі зростання Інтернету файли hosts.txt також збільшувалися в об'ємі, і створення масштабованого рішення для дозволу імен стало необхідністю.

Таким рішенням стала централізована служба (Domian Name System — система доменних імен), заснована на розподіленій базі відображень «доменне ім'я — IР-адреса».

До́менна систе́ма іме́н (англ. Domain Name System, DNS) - ієрархічна розподілена система перетворення імені хоста (комп'ютера або іншого мережевого пристрою) в IP-адресу.
Служба DNS використовує в своїй роботі DNS-сервери і DNS-клієнти. DNS-сервери підтримують розподілену базу відображень, а DNS-клієнти звертаються до серверів із запитами про перетворення доменного імені в IР-адресу.

Служба DNS використовує текстові файли майже такого формату, як і файл hosts, і ці файли адміністратор також готує уручну. Проте служба DNS спирається на ієрархію доменів, і кожен сервер служби DNS зберігає тільки частину імен мережі, а не всі імена, як це відбувається при використанні файлів hosts. При зростанні кількості вузлів в мережі проблема масштабування вирішується створенням нових доменів і піддоменів імен і додаванням в службу DNS нових серверів.

Для кожного домена імен створюється свій DNS-сервер. Є два розподіли імен на серверах. У першому випадку сервер може зберігати відображення «доменне ім'я — IР-адреса» для всього домена, включаючи всі його піддомени. Проте таке рішення виявляється погано масштабованим, оскільки при додаванні нових піддоменів навантаження на цей сервер може перевищити його можливості. Частіше використовується інший підхід, коли сервер домена зберігає тільки імена, які закінчуються на наступному нижче рівні ієрархії в порівнянні з ім'ям домена. (Аналогічно каталогу файлової системи, який містить записи про файли і підкаталоги, що безпосередньо в нього «входять».) Саме при такій організації служби DNS навантаження по розв’язанню імен розподіляється более- менш рівномірно між всіма DNS-серверами мережі. Наприклад, в першому випадку DNS-сервер домена mmt.ru зберігатиме відображення для всіх імен, що закінчуються на mmt.ru (www.zil.mmt.ru, ftp.zil.mmt.ru, mail.mmt.ru і т. д.). У другому випадку цей сервер зберігає відображення тільки імен типу mail.mmt.ru, www.mmt.ru, а решта всіх відображень повинна зберігатися на DNS-сервере піддомена zil.

Кожен DNS-сервер окрім таблиці відображень імен містить посилання на DNS-сервери своїх піддоменів. Ці посилання зв'язують окремі DNS-сервери в єдину службу DNS. Посиланнями є IР-адреса відповідних серверів. Для обслуговування кореневого домена виділено декілька дублюючих один одного DNS-серверів, IР-адреса яких є широко відомою (її можна дізнатися, наприклад, в InterNIC).

Процедура розв’язання DNS-імені багато в чому аналогічна процедурі пошуку файловою системою адреси файлу по його символьному імені. Дійсно, в обох випадках складене ім'я відображає ієрархічну структуру організації відповідних довідників — каталогів файлів або DNS-таблиць. Тут домен і доменний DNS-сервер є аналогом каталога файлової системи. Для доменних імен, так само як і для символьних імен файлів, характерна незалежність іменування від фізичного місцеположення.

Процедура пошуку адреси файлу по символьному імені полягає в послідовному перегляді каталогів, починаючи з кореневого. При цьому заздалегідь перевіряються кеш і поточний каталог. Для визначення IР-адреси по доменному імені також необхідно проглянути всі DNS-сервери, обслуговуючі ланцюжок піддоменів, що входять в ім'я хоста, починаючи з кореневого домена.

Істотною відмінністю файлової системи від служби DNS є те, що перша розташована на одному комп'ютері, а друга за своєю природою є розподіленою.

Існує дві основні схеми розв’язання DNS-імен. У першому варіанті роботу по пошуку IР-адреси координує DNS-клієнт.

DNS-клієнт звертається до кореневого DNS-серверу з вказівкою повного доменного імені.

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

Доме́н верхнього рівня - домен найвищого рівня у ієрархічній доменній системі імен. Для всіх інших доменів є останньою частиною доменного імені. Наприклад, для домену www.example.com доменом верхнього рівня є домен .com.

DNS-клиент робить запит наступного DNS-сервера, який посилає його до DNS-серверу потрібного піддомена і т. д., поки не буде знайдений DNS-сервер, в якому зберігається відповідність запитаного імені IР-адресі. Цей сервер дає остаточну відповідь клієнтові.

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

У другому варіанті реалізується рекурсивна процедура.

DNS-клієнт запрошує локальний DNS-сервер, тобто той сервер, що обслуговуює піддомен, якому належить ім'я клієнта.

Далі можливі два варіанти дій.

- якщо локальний DNS-сервер знає відповідь, то він відразу ж повертає його клієнтові (це може відбутися, коли запитане ім'я входить в той же піддомен, що і ім'я клієнта, або коли сервер вже дізнавався про дану відповідність для іншого клієнта і зберіг його в своєму кеші);

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

У цій схемі клієнт передоручає роботу своєму серверу, тому схема називається непрямою, або рекурсивною. Практично всі DNS-клієнти використовують рекурсивну процедуру.

Для прискорення пошуку IР-адрес DNS-сервери широко застосовують кешування відповідей, що проходять через них. Щоб служба DNS могла оперативно відпрацьовувати зміни, що відбуваються в мережі, відповіді кэшуються на відносно короткий час — зазвичай від декількох годин до декількох днів.

Зворотна зона

Служба DNS призначена не тільки для знаходження IР-адреси по імені хоста, але і для вирішення зворотного завдання — знаходження DNS-імені по відомій IР-адресі.

Багато програм і утиліт, що користуються службою DNS, намагаються знайти ім'я вузла за його адресою у тому випадку, коли користувачем задана тільки адреса (або цю адресу програма дізналася з пакету, що прийшов). Зворотний запис не завжди існує навіть для тих адрес, для яких є прямі записи. Його могли просто забути створити або ж його створення вимагає додаткової оплати. Зворотне завдання вирішується в Інтернеті шляхом організації так званих зворотних зон.

Зворотна зона — це система таблиць, яка зберігає відповідність між IР-адресами і DNS-іменами хостів деякої мережі. Для організації розподіленої служби і використання для пошуку імен того ж програмного забезпечення, що і для пошуку адрес, застосовується оригінальний підхід, пов'язаний з представленням IР-адреси у вигляді DNS-імені.

Перший етап перетворення полягає в тому, що складові IР-адреси інтерпретуються як складові DNS-імені. Наприклад, адреса 192.31.106.0 розглядається як така, що складається із старшої частини, відповідної домену 192, потім йде домен 31, в який входить домен 106.

Далі, враховуючи, що при записі IР-адреси старша частина є найлівішою частиною адреси, а при записі DNS-імені — найправішою, то складові в перетвореній адресі указуються в зворотному порядку, тобто для даного прикладу - 106.31.192.

Для зберігання відповідності всіх адрес, що починаються, наприклад, з числа 192, заводиться зона 192 зі своїми серверами імен. Для записів про сервери, що підтримують старші в ієрархії зворотні зони, створена спеціальна зона in-addr.arpa, тому повний запис для використаної в прикладі адреси виглядає так:

106.31.192.in-addr.arpa.

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

Питання 3. IР-пакет складається із заголовка і поля даних. Нижче перераховані поля заголовка (рис. 4.3).


4 біта Номер версії

4 біта Довжина заголовка

8 біт

Тип сервісу

Рr D T R|


16 біт

Загальна довжина



16 біт

Ідентифікатор пакету



3 біта Прапори

|D| M


13 біт

Зсув фрагмента



8 біт

Час життя



8 біт

Протокол верхнього рівня



16 біт

Контрольна сума



32 біта

ІР-адреса джерела



32 біта

ІР-адреса призначення



Параметри і вирівнювання


Рис. 4.3. Структура заголовка IР-пакету


Поле номера версії займає 4 біта і ідентифікує версію протоколу IР. Зараз повсюдно використовується версія 4 (IРv4), хоча все частіше зустрічається і нова версія (IРv6).

Значення довжини заголовка IР-пакета також займає 4 біта і вимірюється в 32- бітових словах. Зазвичай заголовок має довжину в 20 байт (п'ять 32-бітових слів), але при додаванні деякої службовій інформації це значення може бути збільшене за рахунок додаткових байтів в полі параметрів. Найбільша довжина заголовка складає 60 байт.

Поле типу сервісу (Турі of Service, ТOS) має і іншу, сучаснішу назву — байт диференційованого обслуговування, або DS-байт. Цим двом назвам відповідають два варіанти інтерпретації цього поля. У обох випадках дане поле служить одній меті — зберіганню ознак, які відображають вимоги до якості обслуговування пакету. У колишньому варіанті перші три біта містять значення пріоритету пакету: від найнижчого — 0 до найвищого — 7. Маршрутизатори і комп'ютери можуть брати до уваги пріоритет пакету і обробляти важливіші пакети насамперед. Наступні три біта поля TOS визначають критерій вибору маршруту. Якщо біт D (Delau — затримка) встановлений в 1, то маршрут повинен вибиратися для мінімізації затримки доставки даного пакету, біт Т (Thhroughput — пропускна спроможність) — для максимізації пропускної спроможності, а біт R (Reliabilti — надійність) — для максимізації надійності доставки. Два біта, що залишилися, мають нульове значення.

Стандарти диференційованого обслуговування, прийняті в кінці 90-х років, дали нову назву цьому полю і перевизначили призначення його бітів. У DS-байті також використовуються тільки старші 6 біт, а два молодших біта залишаються як резерв.

Поле загальної довжини займає 2 байти і характеризує загальну довжину пакету з урахуванням заголовка і поля даних. Максимальна довжина пакету обмежена розрядністю поля, що визначає цю величину, і складає 65 535 байт, проте в більшості комп'ютерів і мереж такі великі пакети не використовуються. При передачі по мережах різного типу довжина пакету вибирається з урахуванням максимальної довжини пакету протоколу нижнього рівня, що несе IР-пакети. Якщо це кадри Eternet, то вибираються пакети з максимальною довжиною 1500 байт, що уміщаються в полі даних кадру Eternet. У стандартах ТСР/ІР передбачається, що всі хости повинні бути готові приймати пакети аж до 576 байт завдовжки (незалежно від того, чи приходять вони цілком або фрагментами).



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

Прапори займають 3 біта і містять ознаки, пов'язані з фрагментацією. Встановлений в 1 біт DF (Do not Fragment — не фрагментувати) забороняє маршрутизатору фрагментувати даний пакет, а встановлений в 1 біт MF (More Fragment — більше фрагментів) говорить про те, що даний пакет є проміжним (не останнім) фрагментом. Біт, що залишився, зарезервований.

Поле зсуву фрагмента займає 13 біт і задає зсув в байтах поля даних цього фрагмента відносно початку поля даних початкового нефрагментованого пакету. Використовується при збірці/розбиранні фрагментів пакетів. Зсув повинен бути кратним 8 байт.

Поле часу життя (Time To Live, TTL) займає один байт і використовується для завдання граничного терміну, протягом якого пакет може переміщатися по мережі. Час життя пакету вимірюється в секундах і задається джерелом. Після закінчення кожної секунди перебування на кожному з маршрутизаторів, через які проходить пакет під час своєї «подорожі» по мережі, з його поточного часу життя віднімається одиниця; одиниця віднімається і в тому випадку, якщо час перебування був менше секунди. Оскільки сучасні маршрутизатори рідко обробляють пакет довше, ніж за одну секунду, той час життя можна інтерпретувати як максимальне число транзитних вузлів, які дозволено пройти пакету. Якщо значення поля часу життя стає нульовим до того, як пакет досягає одержувача, пакет знищується. Таким чином, час життя є свого роду годинниковим механізмом самознищення пакету.

Поле протоколу верхнього рівня займає один байт і містить ідентифікатор, вказуючий, якому протоколу верхнього рівня належить інформація, розміщена в полі даних пакету. Значення ідентифікаторів для різних протоколів приводяться в документі RFC 1700, доступному за адресою http://www.iana.org. Наприклад, 6 означає, що в пакеті знаходиться повідомлення ТСР, 17 — повідомлення UDP, 1 — повідомлення ICMP.



Контрольна сума заголовка займає 2 байти (16 біт) і розраховується тільки по заголовку. Оскільки деякі поля заголовка міняють своє значення в процесі передачі пакету по мережі (наприклад, поле часу життя), контрольна сума перевіряється і повторно розраховується на кожному маршрутизаторі і кінцевому вузлі як доповнення до суми всіх 16-бітових слів заголовка. При обчисленні контрольної суми значення самого поля контрольної суми встановлюється в нуль. Якщо контрольна сума невірна, то пакет відкидається, як тільки виявляється помилка.

Поля IР-адрес джерела і приймача мають однакову довжину — 32 біта.

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

Практично для всіх маршрутизаторів існують три основні джерела появи запису в таблиці.

Одним з джерел записів в таблицю маршрутизації є програмне забезпечення стека ТСР/ІР, яке при ініціалізації маршрутизатора автоматично заносить в таблицю декілька записів, внаслідок чого створюється так звана мінімальна таблиця маршрутизації. Програмне забезпечення формує записи про безпосередньо підключені мережі і маршрути за умовчанням, інформація про які з'являється в стеку при ручній конфігурації інтерфейсів комп'ютера або маршрутизатора. Програмне забезпечення також автоматично заносить в таблицю маршрутизації записи про адреси особливого призначення.

Ще одним джерелом записів в таблиці є адміністратор, що безпосередньо формує записи за допомогою деякої системної утиліти, наприклад програми route, наявної в операційних системах Unix і Windows XP. У апаратних маршрутизаторах також завжди є команда для ручного завдання записів таблиці маршрутизації. Задані уручну записи завжди є статичними, тобто вони не мають терміну життя. Ці записи можуть бути як постійними, тобто що зберігаються при перезавантаженні маршрутизатора, так і тимчасовими, такими, що зберігаються в таблиці тільки до виключення пристрою. Часто адміністратор уручну заносить запис про маршрут за умовчанням. Таким же чином в таблицю маршрутизації може бути внесено запис про специфічний для вузла маршрут.

І, нарешті, третім джерелом записів можуть бути протоколи маршрутизації, такі як RIP або OSPF. Такі записи завжди є динамічними, тобто мають обмежений термін життя.

Питання 4. Як вже було відмічено, головне завдання транспортного рівня полягає в передачі даних між прикладними процесами. Цю задачу вирішують протокол управління передачею (Transmission Control Protocol, ТСР), описаний в RFC 793, і протокол призначених для користувача дейтаграм (User Datagram Protocol, UDP), описаний в RFC 768. Протоколи ТСР і UDP мають багато спільного. Той і інший забезпечують інтерфейс з вищерозміщеним прикладним рівнем, передаючи дані, що поступають на вхідний інтерфейс хоста, відповідному додатку. При цьому обидва протоколи використовують концепції «порт» і «сокет». Обидва вони також підтримують інтерфейс з мережевим рівнем IР, що пролягає нижче, Протокольна суть ТСР і UDP, як і у разі протоколів прикладного рівня, встановлюється тільки на кінцевих вузлах. Проте, як ми побачимо далі, відмінностей між ТСР і UDP значно більше, чим схожості.

Кожен комп'ютер може виконувати декілька процесів, більш того, прикладний процес теж може мати декілька точок входу, які є адресами призначення для пакетів даних. Тому після того, як пакет засобами протоколу IР доставлений на мережевий інтерфейс комп'ютера-одержувача, дані необхідно переправити конкретному процесу-одержувачеві.

Існує і зворотне завдання: пакети, які відправляють в мережу різні застосовання, що працюють на одному кінцевому вузлі, обробляються загальним для них протоколом IР. Отже, в стеку повинен бути передбачений засіб «збору» пакетів від різних застосовань для передачі протоколу IР. Цю роботу виконують протоколи ТСР і UDP.

Процедура прийому даних протоколами ТСР і UDP, що поступають від декількох різних прикладних служб, називається мультиплексуванням. Зворотна процедура — процедура розподілу протоколами ТСР і UDP пакетів, що поступають від мережевого рівня, між набором високорівневих служб — називається демультиплексуванням.

Протоколи ТСР і UDP ведуть для кожного додатку дві черги: черга пакетів, що поступають до даного додатку з мережі, і черга пакетів, що відправляються даним додатком в мережу. Пакети, що поступають на транспортний рівень, організовуються операційною системою у вигляді безлічі черг до точок входу різних прикладних процесів. У термінології ТСР/ІР такі системні черги називаються портами, причому вхідна і вихідна черги одного додатку розглядаються як один порт. Для однозначної ідентифікації портів їм привласнюють номери. Номери портів використовуються для адресації додатків.

Якщо процесами є популярні загальнодоступні служби, такі як FTP, telnet, НТТР, ТFTP, DNS і т. ін., то за ними закріплюються стандартні призначені номери, також звані добре відомими well-known номерами портів. Ці номери закріплюються і публікуються в стандартах Інтернету (RFC 1700, RFC 3232). Так, номер 21 закріплений за службою віддаленого доступу до файлів FТР, а 23 — за службою віддаленого управління telnet. Призначені номери є унікальними в межах Інтернету і призначаються додаткам централізовано з діапазону від 0 до 1023.

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

Надалі всі мережеві додатки повинні адресуватися до даного додатку з вказівкою призначеного йому номера порту. Після того, як додаток завершить роботу, виділений йому локальний номер порту повертається в список вільних і може бути призначений іншому додатку. Динамічні номери є унікальними в межах кожного комп'ютера, але при цьому звичайною ситуацією є збіг номерів портів додатків, що виконуються на різних комп'ютерах. Як правило, клієнтські частини відомих додатків (DNS, WWW, FTP, telnet і ін.) отримують динамічні номери портів від ОС.

Все, що було сказане про порти, в рівній мірі відноситься до обох протоколів транспортного рівня (ТСР і UDP). В принципі немає ніякої залежності між призначенням номерів для додатків, що використовують протокол ТСР, і додатків, що працюють з протоколом UDP. Додатки, які передають дані на рівень IР по протоколу UDP, отримують номери, звані UDP- портами. Аналогічно додаткам, що звертаються до протоколу ТСР, виділяються ТСР-порти.

У тому і іншому випадках це можуть бути як призначені, так і динамічні номери. Діапазони чисел, з яких виділяються номери ТСР- і UDP-портов, співпадають: від 0 до 1023 для призначених і від 1024 до 65535 для динамічних. Проте ніякого зв'язку між призначеними номерами ТСР- і UDP-портов не немає. Навіть якщо номери ТСР- і UDP-портов співпадають, вони ідентифікують різні додатки. Наприклад, одному додатку може бути призначений ТСР-порт 1750, а іншому — UDP-порт 1750. В деяких випадках, коли додаток може звертатися по вибору до протоколу ТСР або UDP (наприклад, таким додатком є DNS), йому, виходячи із зручності запам'ятовування, призначаються співпадаючі номери ТСР- і UDP-портов (у даному прикладі — це номер 53).



Протокол UDP, будучи дейтаграмним протоколом, реалізує сервіс по можливості, тобто не гарантує доставку своїх повідомлень, а, отже, жодним чином не компенсує ненадійність дейтаграммного протоколу IР.

Одиниця даних протоколу UDP називається UDP-дейтаграмою, або призначеною для користувача дейтаграмою. Кожна дейтаграмма переносить окреме призначене для користувача повідомлення. Це приводить до природного обмеження: довжина дейтаграми UDP не може перевищувати довжини поля даних протоколу IР, яке, у свою чергу, обмежене розміром кадру технології нижнього рівня. Тому якщо UDP-буфер переповнюється, то дані додатку відкидаються.

Заголовок UDP, що складається з чотирьох 2-байтових полів, містить номери портів відправника і одержувача, контрольну суму і довжину дейтаграммы.

Судячи по простоті заголовка, протокол UDP не є дуже складним. Дійсно, його функції зводяться до мультиплексування і демультиплексування даних між мережевим і прикладним рівнями.

Давайте розглянемо, як протокол вирішує задачу демультиплексування. Здавалося б, для цієї мети досить використовувати номери портів. Кадри, що несуть UDP-дейтаграми, приходять на мережевий інтерфейс хоста, послідовно обробляються протоколами стека і, нарешті, поступають в розпорядження протоколу UDP. UDP витягує із заголовка номер порту призначення і передає дані на відповідний порт відповідному додатку, тобто виконує демультиплексування.

Це рішення виглядає дуже логічно і просто, проте воно непрацездатне за ситуації, коли на одному кінцевому вузлі виконується декілька копій одного і того ж додатка. Хай, наприклад, на одному хості запущено два DNS-сервера, причому обидва використовують для передачі своїх повідомлень протокол UDP. DNS-сервер має добре відомий UDP-порт 53. В той же час у кожного з DNS-серверов можуть бути свої клієнти, власні бази даних, власні налагодження. Коли на мережевий інтерфейс даного комп'ютера прийде запит від DNS-клієнта, в UDP-дейтаграмі буде вказаний номер порту 53, який в рівній мірі відноситься до обох DNS-серверів — так кому ж з них протокол UDP повинен передати запит? Щоб зняти неоднозначність, застосовують наступний підхід. Різним копіям одного додатка, навіть встановленим на одному комп'ютері, привласнюють різні IР-адреси. Таким чином однозначно визначає прикладний процес в мережі (а тим більше в межах комп'ютера) пара (IР-адреса, номер порту UDP), звана UDP-сокетом .



Основною відмінністю ТСР від UDP є те, що на протокол ТСР покладена додаткова задача—забезпечити надійну доставку повідомлень, використовуючи як основу ненадійний дейтаграмний протокол IP.



Рис 4.6. ТСР з’єднання створює надійний логічний канал між кінцевими вузлами


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

При встановленні логічного з'єднання модулі ТСР домовляються між собою про параметри процедури обміну даними. У протоколі ТСР кожна сторона з'єднання посилає протилежній стороні наступні параметри:

максимальний розмір сегменту, який вона готова приймати;

максимальний об'єм даних (можливі декілька сегментів), які вона дозволяє іншій стороні передавати в свою сторону, навіть якщо та ще не отримала квитанцію на попередню порцію даних (розмір вікна);

початковий порядковий номер байта, з якого вона починає відлік потоку даних в рамках даного з'єднання.

В результаті переговорного процесу модулів ТСР з двох сторін з'єднання визначаються параметри з'єднання. Одні з них залишаються постійними протягом всього сеансу зв'язку, а інші адаптивно змінюються. Зокрема, залежно від завантаження буфера приймаючої сторони, а також надійності роботи мережі динамічно змінюється розмір вікна відправника. Створення з'єднання означає також виділення операційною системою на кожній стороні з'єднання певних системних ресурсів: для організації буферів, таймерів, лічильників. Ці ресурси будуть закріплені за з'єднанням з моменту створення і до моменту розриву. Логічне ТСР-з’єднання однозначно ідентифікується парою сокетів.

Автоматично створювані таблиці маршрутизації забезпечують раціональність маршрутів проходження пакетів через мережу, при цьому критерії вибору маршрутів можуть бути різними. У IР-мережах сьогодні застосовуються протоколи маршрутизації, в яких маршрут вибирається або по критерію найкоротшої відстані, де під відстанню, прохідним пакетом, розуміється кількість проміжних маршрутизаторів (хопів), або по комплексному показнику, що враховує також номінальну пропускну спроможність каналів між маршрутизаторами, надійність каналів або затримки, що вносяться ними.

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

Слідуючи принципу масштабованості, маршрутизація в Інтернеті функціонує в межах автономних систем (Autonomous Sistems, AS).

У результаті маршрутизація в Інтернеті носить яскраво виражений ієрархічний характер. Усередині кожної автономної системи може застосовуватися будь-який з існуючих протоколів маршрутизації, тоді як між автономними системами завжди застосовується один і той же протокол; що є своєрідною мовою «есперанто», на якому автономні системи спілкуються між собою.

У IР-мережах як внутрішні шлюзові протоколи, тобто протоколи, вживані усередині автономних систем, сьогодні активно використовуються три протоколи — RIP, OSPF і IS-IS. Зовнішнім шлюзовим протоколом, тобто протоколом вибору маршруту між автономними системами, сьогодні є протокол BGP.

У одній і тій же мережі можуть одночасно працювати декілька різних протоколів маршрутизації. Це означає, що на деяких (не обов'язково всіх) маршрутизаторах мережі встановлено і функціонує декілька протоколів маршрутизації, але при цьому, природно, через мережу взаємодіють тільки однойменні протоколи. Тобто якщо маршрутизатор 1 підтримує, наприклад, протоколи RIP і OSPF, маршрутизатор 2 — тільки RIP, а маршрутизатор 3 — тільки OSPF, то маршрутизатор 1 взаємодіятиме з маршрутизатором 2 по протоколу RIP, з маршрутизатором 3 — по OSPF, а маршрутизатори 2 і 3 взагалі безпосередньо один з одним взаємодіяти не можуть.

У маршрутизаторі, який підтримує одночасно декілька протоколів, кожен запис в таблиці є результатом роботи одного з цих протоколів. Якщо про деяку мережу з'являється інформація від декількох протоколів, то для однозначності вибору маршруту (а дані різних протоколів можуть вести до різних раціональних маршрутів) встановлюються пріоритети протоколів маршрутизації. Звичайна перевага віддається протоколам LSA, як такому що має в своєму розпорядженні повнішу інформацію про мережу в порівнянні з протоколами DVA. У деяких ОС у формах виводу на екран і друк в кожному записі таблиці маршрутизації є відмітка про те, за допомогою якого протоколу маршрутизації цей запис отриманий. Але навіть якщо ця відмітка на екран і не виводиться, вона обов'язково є у внутрішньому представленні таблиці маршрутизації. За умовчанням кожен протокол маршрутизації, що працює на певному маршрутизаторі, поширює тільки ту інформацію, яка була отримана цим маршрутизатором по даному протоколу. Таким чином, якщо про маршрут до деякої мережі маршрутизатор дізнався від протоколу RIP, то і поширювати по мережі оголошення про цей маршрут він буде за допомогою протоколу RIP.

Проте виникає питання: «Яким чином маршрутизатори, що підтримують різні протоколи, обмінюються між собою маршрутною інформацією, роблячи тим самим досяжними всі мережі складеної мережі?» Для цього необхідно встановити особливий внутрішній режим роботи, званий часто перерозподілом. Такий режим дозволяє одному протоколу маршрутизації використовувати не тільки «свої», але і «чужі» записи таблиці маршрутизації, отримані за допомогою іншого протоколу маршрутизації, вказаного при конфігурації.

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

Інтернет володіє не тільки організаційною структурою, що визначає ділення Інтернету на мережі різних постачальників послуг (ISP). Інтернет складається також з автономних систем.



Автономна система — це сукупність мереж під єдиним адміністративним управлінням, що забезпечує загальну для всіх вхідних в автономну систему маршрутизаторів політику маршрутизації. Зазвичай автономною системою управляє один постачальник послуг Інтернету, самостійно вибираючи, які протоколи маршрутизації повинні використовуватися в деякій автономній системі і яким чином між ними повинен виконуватися перерозподіл маршрутної інформації.
Постачальник послуг Інтернету (англ. Internet Service Provider, ISP), також провайдер послуг Інтернету, надавач послуг Інтернету, Інтернет-провайдер (від англ. to provide - забезпечувати, надавати доступ) - організація, яка надає послуги доступу та передачі (інформації) певними інформаційними каналами.
Крупні постачальники послуг і корпорації можуть представити свою складену мережу як набір декількох автономних систем. Реєстрація автономних систем відбувається централізовано, як і реєстрація IР-адрес і DNS-імен. Номер автономної системи складається з 16 розрядів і ніяк не пов'язаний з префіксами IР-адрес мереж, що входять в неї.

Відповідно до цієї концепції Інтернет виглядає як набір взаємозв'язаних автономних систем, кожна з яких складається з взаємозв'язаних мереж (рис. 4.8).





Рис. 4.8. Автономні системи Інтернету


Основна мета ділення Інтернету на автономні системи — забезпечення багаторівневого підходу до маршрутизації. До введення автономних систем передбачався дворівневий підхід — тобто спочатку маршрут визначався як послідовність мереж, а потім вів безпосередньо до заданого вузла в кінцевій мережі.

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

Автономні системи з'єднуються зовнішніми шлюзами. Що важливе, між зовнішніми шлюзами дозволяється використовувати тільки один протокол маршрутизації, причому не довільний, а той, який зараз визнається співтовариством Інтернету як стандартний для зовнішніх шлюзів. Такий протокол маршрутизації називається зовнішнім шлюзовим протоколом (Exterior Gateway Protokol, EGP) і в даний час їм є протокол BGP версії 4 (BGPv4). Решта всіх протоколів (наприклад, RIP, OSPF, IS-IS) є внутрішніми шлюзовими протоколами (Interior Gateway Protokol, IGP).

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

Внутрішні шлюзові протоколи відповідають за маршрут усередині автономної системи. У разі транзитної автономної системи ці протоколи указують точну послідовність маршрутизаторів від точки входу в автономну систему до точки виходу з неї.

Автономні системи складають магістраль Інтернету. Концепція автономних систем приховує від адміністраторів магістралі Інтернет проблеми маршрутизації пакетів на нижчому рівні — рівні мереж. Для адміністратора магістралі неважливо, які протоколи маршрутизації застосовуються усередині автономних систем, для нього існує єдиний протокол маршрутизації - BGPv4.



Укладач: Смаглюк В.М.
Міністерство ВНУТРІШНІХ СПРАВ УКРАЇНИ

НаціональнА АКАДЕМІЯ ВНУТРІШНІХ СПРАВ
Кафедра інформаційних технологій
ЗАТВЕРДЖУЮ

Начальник кафедри

полковник міліції

________________В.А.Кудінов


____.________ 20__

ПЛАН-КОНСПЕКТ ПРОВЕДЕННЯ

ЛЕКЦІЙНОГО ЗАНЯТТЯ
1   ...   4   5   6   7   8   9   10   11   ...   16