Розділ 6

Минуле, сьогодення

та майбутнє протоколу TCP/IP

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

· Розповісти історію появи TCP / IP;

· Пояснити принципи роботи протоколів TCP та IP, а також методи використання протоколів UDP замість TCP;

· Розповісти про адресацію IP і зрозуміти способи її реалізації в локальних і глобальних мережах;

· Розповісти про новий протокол IP version 6 та його призначення;

· Обговорити способи використання прикладних протоколів, що входять у стек TCP/IP;

· Зрозуміти призначення прикладних протоколів стека TCP/IP;

· Співвіднести реалізацію TCP/IP з еталонною моделлю OSI.

Коли комп'ютери спілкуються через Інтернет, як мову спілкування вони використовують Transmission Control Protocol/Internet Protocol (TCP/IP). Також протоколи TCP/IP поширені у більшості середніх і великих мереж. Ці протоколи підтримують мережі на основі платформ Novell NetWare, UNIX і Windows, особливо – мережі та мережі, що розвиваються, в яких використовуються клієнт-серверні або веб-орієнтовані програми. Широке поширення, перевірені технології та можливості розширення роблять TCP/IP вдалим вибором для більшості проектів, що забезпечують взаємодію локальних та глобальних мереж. Навіть у невеликих мережах розгортання TCP/IP може виявитися життєво важливим для подальшого розвитку мережі.

У цьому розділі буде докладно розказано протоколах TCP/IP, включаючи опис пакетів TCP і IP, і навіть способи адресації IP. Також ви дізнаєтеся про альтернативу TCP - протокол User Datagram Protocol (UDP), який застосовується тоді, коли підтвердження переданих даних не так важливо, як швидкість і мале навантаження на мережу. У розділі обговорюється нова версія протоколу IP, названа IPv6, і порівнюється з попередньою версією, IPv4. Крім того, розповідається про прикладні протоколи, що входять у стек TCP/IP і призначені для емуляції терміналів передачі файлів і повідомлень електронної пошти, перетворень та призначення IP-адрес, а також для управління мережами. І, нарешті, ви дізнаєтеся, як архітектура TCP/IP співвідноситься з еталонною моделлю OSI.

Коротка історія стеку TCP/IP

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

Першу спробу створення засобів взаємодії різних комп'ютерів було здійснено кількома університетами, які розробили мережевий протокол, названий Network Control Protocol (NCP) і який дозволив хост-комп'ютерам різних компаній, включаючи DEC та IBM, обмінював інформацією. NCP був найпростішим протоколом, який забезпечував різним типам комп'ютерів DEC і IBM можливість мережевих взаємодій і запуску додатків через мережу, де хости були географічно віддалені друг від друга. Наприклад, однією з програм NCP була передача файлів між комп'ютерами. Це був добрий початок, проте протокол NCP не міг забезпечити достатньо надійної передачі даних, тому управління ARPA для його модернізації запустило проект. Розроблений протокол насправді був комбінацією двох протоколів – Transmission Control Protocol (TCP) і Internet Protocol (IP) назви яких зазвичай скорочуються до абревіатури TCP/IP.

Примітка

Протокол NCP, як і раніше, використовується у старих мережах DEC та IBM, хоча його дуже складно конфігурувати. Цей протокол створює велике навантаження на центральний процесор, оскільки він містить певний рівень комунікацій під час виконання мережевих операцій, який не використовується протоколом TCP

Увага

IBM використовує абревіатуру NCP для назви Програми управління мережею – Network Control Program. Ця програма є програмою, що виконується на кінцевому процесорі (невеликому комп'ютері) або на шлюзі SNA, який підключений до мейнфрейму, забезпечуючи останньому можливість мережевих взаємодій.

Основи стека TCP/IP

Протокол TCP, описаний RFC 793, спочатку був розроблений для двоточкових взаємодій між комп'ютерами однієї мережі, а протокол IP (RFC 791) призначався для забезпечення комунікацій між комп'ютерами, підключеними до різних мереж або до глобальних мереж. Незабаром після появи обидва протоколи були об'єднані як стек TCP/IP для використання в популярних операційних системах Berkeley UNIX і були вбудовані в ОС Virtual Memory System (VMS, нині – OpenVMS) компанії DEC і Multiple Virtual Storage (MVS, нині – OpenMVS) компанії IBM.

З моменту появи на початку 1970-х років стек TCP/IP широко застосовувався у мережах у різних країнах світу. Він реалізований для PC-сумісних комп'ютерів, робочих станцій UNIX, міні-ЕОМ, комп'ютерів Macintosh та мережевих пристроїв, що зв'язують клієнтів та хости. TCP/IP забезпечує тисячам відкритих та комерційних мереж підключення до Інтернету, яким можуть користуватися мільйони людей.

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

· Transmission Control Protocol (TCP);

· User Datagram Protocol (UDP);

· Internet Protocol (IP).

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

Функціонування протоколуTCP

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

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

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

· поточний мережевий трафік;

Комерційні кооперативи (що належать співробітникам, що працюють у них)

Освітні

Урядові

Організації, які займаються реєстрацією доменних імен

Організації, створені згідно з міжнародними договорами

Музейні

Домени для особистого користування

Постачальники мережевих послуг

Некомерційні

Професійні (наприклад, об'єднання лікарів, бухгалтерів чи юристів)

Таблиця 6.4. Доменні імена ДМШ

Таблиця 6.5. Пропоновані глобальні доменні імена першого рівня (TLD)

Розпізнавачі іменDNSта простору імен

Для роботи DNS потрібні розпізнавачі доменних імен на кожному клієнті, а також сервер доменних імен, встановлений на одному або кількох хостах. DNS-сервери підтримують простір імен(namespace) для підприємства і реалізують механізм дозволу імен комп'ютерів та доменів в IP-адреси, а також зворотне перетворення. Простір імен є логічною областю мережі, що містить перелік іменованих об'єктів (наприклад, комп'ютерів) і дозволяє виконувати дозвіл імен.

Використання зон

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

Зона, що асоціює імена комп'ютерів з відповідними адресами JH, називається зоною прямого перегляду (forward lookup zone). Ця зона містить записи імен хостів, які називаються адресними записами. Кожен сервер та клієнт IP-мережі повинен мати адресний запис, який дозволяє знайти його за допомогою DNS. Наприклад, якщо DNS-сервер називається NetAdmin і має адресу 129.70.10.1, зона прямого перегляду пов'язує ім'я NetAdmin з адресою 129.70.10.1. Для протоколу IPv4 запис хоста називається ресурсним записом адреси хоста (типу A) (host address (A) resource record). Для протоколу IPv6 такий запис називається ресурсним записом адреси хоста (типу АААА) (IPv6 host address (АААА) resource record).

Примітка

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

В іншій зоні, званій зоною зворотного перегляду(reverse lookup zone) зберігаються ресурсні записи покажчиків (типуPTR) (pointer (PTR) resourse record), які пов'язують IP-адреси з іменами хостів. Зони зворотного перегляду використовуються не так часто, як зони прямого перегляду, однак не слід створювати в тих випадках, коли для забезпечення мережевих комунікацій потрібно зв'язувати IP-адресу з деяким комп'ютерним ім'ям (наприклад, для моніторингу мережі з використанням IP -адрес).

РоліDNS-серверів

Зазвичай DNS-сервер у мережі грає одну з двох ролей: він може виступати або як основний DNS-сервер, або виконувати функції додаткового DNS-сервера. ОсновнимDNS-сервером(primary DNS server) вважається сервер, який відповідає за деяку зону і тому називається авторитетним (authoritative) сервером для цієї зони. Наприклад, якщо на деякому DNS-сервері вперше створюється зона прямого перегляду ДД домену, то при цьому створюється ресурсний запис початку зони (SOA) (start of authority (SOA) resource record), що ідентифікує цей сервер як авторитетний DNS-сервер для домену. Це означає, що всі зміни зони (наприклад, створення ресурсних записів адреси хоста (типу А)) повинні виконуватися на цьому сервері.

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

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

Порада

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

Щоб познайомитися із зонами, ресурсним записом початку зони (SOA) та іншою інформацією, що зберігається на DNS-сервері, виконайте практичне завдання 6-8.

СтандартиDNS

Авторитетні сервери зазвичай підтримують два стандарти DNS: ресурсні записи служб та протокол динамічного оновлення DNS. Ресурсний записслужби (типуSVR) (Service Resource Record (SVR RR)) описана в RFC 2052 і являє собою тип DNS-запису, що дозволяє DNS розпізнавати різні сервери і визначати розташування широко використовуваних служб TCP/IP, що виконуються на конкретних серверах. SRV-записи дозволяють серверу DNS генерувати список серверів мережі, що надають послуги TCP/IP-сервісів. Також ці записи повідомляють про протоколи, які підтримують ці сервери, і дозволяють визначити бажаний сервер для певної служби. Формат запису SRV містить інформацію про тип служби, що виконується на певному сервері, імені домену, який обслуговується цим сервером, а також про протокол, який використовується сервером.

Протокол динамічного оновленняDNS(DNS dynamic update protocol) описаний у RFC 2136, з його допомогою можна автоматично оновлювати інформацію на 1 DNS-сервері. Прикладом може бути робоча станція під керуванням Windows ХР Professional, що оновлює свою IP-адресу, отриману від сервера DHCP. Протокол динамічного оновлення DNS може заощадити мережному адміністратору багато часу, оскільки йому не знадобиться вручну реєструвати кожну нову робочу станцію або виконувати реєстрацію комп'ютера щоразу після закінчення терміну орендованого йому 1Р-адреси при отриманні нової адреси.

Порада

У мережі, де працює служба Microsoft Active Directory, SRV-записи дозволяють робочим станціям швидко знаходити найближчий сервер для автентифікації запитів входу до мережі. Це дозволяє зменшити непотрібний мережевий трафік.

Dynamic Host Configuration Protocol (DHCP)

Протокол Dynamic Host Configuration Protocol (DHCP) (Протокол динамічно конфігурації хоста) дозволяє автоматично призначати в мережі 1Р-адреси за допомогою DHCP-сервера. Коли новий комп'ютер, налаштований працювати з DHCP, підключається до мережі, він звертається до DHCP-серверу, який виділяє (здає у найм) комп'ютеру IP-адресу, передаючи його за допомогою протоколу DHCP. Тривалість оренди встановлюється на DHCP-сервері мережним адміністратором. Наприклад, термін оренди для настільного комп'ютера може становити від кількох днів до кількох тижнів (оскільки комп'ютер постійно підключений до мережі). Термін оренди для портативного комп'ютера може становити від кількох годин до одного дня (оскільки портативний комп'ютер часто відключається від мережі або переміщається на інші ділянки мережі). І, нарешті, хост-комп'ютер або сервер може отримати адресу в безстрокову оренду, тому що їх адреса ніколи не змінюється.

Порада

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

Address Resolution Protocol(ARP)

У більшості випадків для відправки пакета приймаючому вузлу відправник повинен знати як IP-адресу, так і МАС-адресу. Наприклад, при групових передачах використовуються обидві адреси (IP та MAC). Ці адреси не збігаються і мають різні формати (десятковий з розділовими точками і шістнадцятковий відповідно).

Address Resolution Protocol (ARP) (Протокол дозволу адрес) дозволяє передавальному вузлу отримати МАС-адреси вибраного приймаючого вузла перед відправкою пакетів. Якщо вихідному вузлу потрібна деяка МАС-адреса, то він посилає широкомовний ARP-фрейм, що містить свою власну МАС-адресу та IP-адресу необхідного приймаючого вузла. Вузол, що приймає, відправляє назад пакет ARP-відповіді, що містить свою МАС-адресу.

Допоміжним протоколом є Reverse Address Resolution Protocol (RARP) (Протокол зворотного дозволу імен), за допомогою якого мережевий вузол може визначити свою власну IP-адресу. Наприклад, RARP використовується бездисковими робочими станціями, які можуть дізнатися свої адреси інакше як виконавши RARP-запрос до свого хост-серверу. Крім того, RARP використовується деякими програмами для визначення IP-адреси того комп'ютера, на якому він виконується.

Simple Network Management Protocol (SNMP)

Simple Network Management Protocol (SNMP) (Простий протокол мережного керування) дозволяє адміністраторам мережі безперервно стежити за активністю мережі. Протокол SNMP був розроблений у 1980-х роках для того, щоб забезпечити стек TCP/IP механізмом, альтернативним стандарту OSI на управління мережами – протоколу Common Management Interface Protocol (CMIP) (Протокол загальної інформації, що управляє).

Хоча протокол SNMP був створений для стека TCP/IP, він відповідає стандартній моделі OSI. Більшість виробників віддали перевагу використанню SNMP, а не CMIP, що пояснюється великою популярністю протоколів TCP/IP, а також простотою SNMP. Протокол SNMP підтримує багато сотень мережних пристроїв, включаючи файлові сервери, карти мережних адаптерів, маршрутизатори, повторювачі, мости, комутатори та концентратори. У порівнянні з цим протокол CMIP застосовується компанією IBM у деяких мережах з маркерним кільцем, однак у багатьох інших мережах він не зустрічається.

ПеревагиSNMP

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

Ще одна перевага SNMP полягає в тому, що контрольні функції виконуються на деякій станції керування мережею. У цьому SNMP відрізняється від протоколу CMIP, для якого функції керування розподілені між окремими мережевими вузлами, які одночасно є об'єктами моніторингу. З іншого боку, SN. MP потребує менше оперативної пам'яті, ніж CMIP. Для роботи CMIP потрібно до 1,5 Мбайт пам'яті кожному досліджуваному вузлі, a SNMP вимагає лише 64 Кбайт.

Типи вузлів, які використовуються протоколомSNMP

Протоколом SNMP передбачено два типи вузлів: станція управління мережею (network management station, NMS) та агенти мережі (network agents). Станція керування мережею стежить за мережевими пристроями, що підтримують SNMP. На цих пристроях виконується агентське програмне забезпечення, що взаємодіє зі станцією. Більшість пристроїв, що підключаються до сучасних мереж є агентами. До них належать маршрутизатори, повторювачі, концентратори, комутатори, мости, персональні комп'ютери (через свої мережеві адаптери), сервери друку, сервери доступу та джерела безперебійного живлення.

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

Багато програмних пакетів станцій керування мережею можуть у графічному вигляді надавати показання лічильників, що відображають ступінь використання мережі, потік пакетів та інші статистичні дані. При виникненні несправності графічні позначення допомагають зрозуміти серйозність проблеми і визначити тип агента, що відмовив. Деякі пакети мають інтерфейси прикладного програмування (API), що дозволяють взаємодіяти з програмним забезпеченням та запрограмувати специфічні завдання з використанням простої мови (наприклад, Visual Basic).

Кожен агент мережі зберігає інформаційну базу, що містить кількість надісланих або отриманих пакетів, кількість пакетних помилок та інші дані. Така база називається базою інформації, що управляє (Management Information Base, MIB). У станції управління мережею є безліч команд, що дозволяють звертатися до даних цієї бази та керувати нею. Такі команди передаються за допомогою OSI-сумісних модулів даних протоколу (PDU) та містять тип повідомлення (наприклад, запит на отримання, запит на отримання наступних даних, відповідь на запит, запит на надання значення та системне переривання). Отримані дані дозволяють визначити, чи увімкнено пристрій і чи є мережні проблеми. Станція керування мережею забезпечує навіть віддалене перезавантаження пристрою. Повідомлення між станцією та агентом передаються поверх протоколу UDP, до пакетів якого додається заголовок SNMP. Корисне навантаження SNMP містить групове ім'я(community name), що є деяким паролем, загальним для станції управління мережею та агента.

В основі керуючої інформації зберігаються відомості про мережеві об'єкти (таких як робочі станції, сервери, мости, маршрутизатори, концентратори та повторювачі). Основний набір змінних, які у цій основі, представлений у табл. 6.6. Спочатку таблицю бази MIB було описано у стандарті Management Information Base-I. Цей стандарт визначає відомості про пристрій та безліч відповідних змінних. Стандарти МІВ розробляються Проблемною групою проектування Інтернету (IETF).

Таблиця 6.6. Змінні бази керуючої інформації (Mlв)

ЗмінніMIB	Призначення
Address translation group (група перетворення адрес)	Перетворює мережеві адреси на адреси підмереж або фізичні адреси
Electronic gateway protocol group (Група шлюзового протоколу електронних пристроїв)	Забезпечує відомості про вузли у тому ж сегменті, в якому знаходиться агент мережі
Interfaces group (Група інтерфейсів)	Відстежує кількість мережних адаптерів та кількість підмереж
Internet control message protocol group (Група протоколу керуючих повідомлень Інтернету)	Збирає дані про кількість. повідомлень, надісланих агентом та отриманих ним
Internet protocol group (Група протоколу Інтернету)	Відстежує кількість вхідних прийнятих датаграм та кількість відкинутих датаграм
SNMP group (Група SNMP)	Збирає дані про звернення до бази MIB
System group (Системна група)	Містить інформацію про агента мережі
Transmission control protocol group (Група протоколу керування передачею)	Надає інформацію про ТСР-з'єднання в мережі, включаючи дані про адреси та тайм-аути
User datagram protocol group (Група протоколу даних користувача)	Надає інформацію про слухача, з яким станція управління мережею взаємодіє в даний момент

Новий, більш досконалий стандарт MIB-II описує додаткові засоби безпеки, підтримку мереж з маркерним кільцем та високошвидкісних інтерфейсів, а також підтримку телекомунікаційних інтерфейсів. Стандарт MIB-II прийнято багатьма виробниками мережного обладнання.

Нові можливості протоколуSNMPv2

Перша версія протоколу SNMP мала деякі недоліки, які були усунені у другій версії, названій SNMPv2. Можливо, головним із недоліків SNMP є відсутність механізмів захисту. При використанні SNMP групове ім'я передається станцією керування мережею без шифрування і в разі перехоплення цей пароль можна використовувати для отримання доступу до важливих команд керування мережею. Внаслідок такого витоку зловмисник може віддалено змінити налаштування маршрутизатора або концентратора та дискредитувати безпеку мережі.

SNMPv2 дозволяє шифрувати групове ім'я, покращити обробку помилок та забезпечити взаємодію з багатьма протоколами. Він підтримує також IPX та AppleTalk. Крім того, SNMPv2 забезпечує швидку передачу інформації та дозволяє одночасно отримувати більше даних з бази MIB-II.

Моніторинг із використанням протоколівSNMPіSNMPv2

Протоколи SNMP та SNMPv2 можна застосовувати для керування будь-якими мережами: локальними, глобальними та змішаними. Є безліч засобів та програмних пакетів для мережевого моніторингу, які використовують SNMP та SNMPv2. До них входять програми Sniffer компанії Network Associates (див. www. sniffer. com) та Network Monitor компанії Microsoft (див. www.).

Важливим SNMP-сумісним інструментом для моніторингу локальних мереж, з'єднаних через глобальні мережі, є розроблений на початку 1990-х років стандарт Remote Network Monitoring (RMON) (віддалений моніторинг мережі). RMON не тільки використовує протокол SNMP, але й задіює спеціальну базу даних для віддаленого моніторингу, звану RMON MIB-II. Ця база дозволяє віддаленим мережевим вузлам збирати мережеву статистику практично у будь-якій точці локальної чи глобальної мережі. Ці віддалені вузли є агентами або зондами. Інформація, отримана агентами, може бути передана на деяку станцію управління, яка заносить її до бази даних. В даний час стандарти RMON MIB-II адаптовані до мереж FDDI, Ethernet та Token Ring.

Інші прикладні протоколи стека TCP/IP

Є й інші протоколи чи прикладні програми, які входять у стек TCP/IP - Вони спрощують роботу інтернет-служб, передачу даних мультимедіа-додатків, керування мережею та пошук несправностей. Ці додаткові протоколи та додатки перераховані в табл. 6.7.

Таблиця 6.7. Програми та протоколи стека TCP/IP

Протокол абододаток	Опис
	Додаток, що дозволяє користувачеві стека TCP/IP знаходити FTP-сайти, що містять інформацію з певної тематики
Bootstrap Protocol (ВООТР)	Протокол, використовуваний бездисковими робочими станціями визначення своєї IP-адреси й у взаємодії з сервером, з якого копіюються файли операційної системи, необхідні завантаження цих станцій
Distance Vector Multicast Routing Protocol (DVMRP)	Протокол групової маршрутизації, що використовується разом із протоколом RIP для визначення вузлів, підписаних на певні групові посилки програм мультимедіа (Див. розділ 10)
	За допомогою даної утиліти мережевий користувач може визначити, які ще користувачі та хости активні в мережі
	Додаток, що пропонує список тем, з яких користувачі можуть отримати доступ до іншого меню або текстових файлів (наприклад, файлу, що містить список телефонів). В даний час служби Gopher зустрічаються рідко, оскільки в першу чергу їх замінили веб-сервери.
Hypertext Transfer Protocol (HTTP)	Протокол передачі HTML (Hypertext Markup Language) через Інтернет за запитами від веб-браузерів; ці документи можуть включати аудіо - і відеофайли, а також зображення і графіку
Internet Group Management Protocol (IGMP)	Протокол, що дозволяє передавати групові пакети їх одержувачам та маршрутизаторам. Визначає, які робочі станції належать до певної групи мультимовлення (Див.розділ 10)
Multicast Open Shortest Path First Protocol (MOSPF)	Протокол групової маршрутизації, що дозволяє визначити найкоротший маршрут від джерела до пункту призначення під час групових передач
Open Shortest Path First Protocol (OSPF)	Протокол, що використовується маршрутизаторами для обміну даними таблиць маршрутизації та оцінки мережевих маршрутів під час передачі даних з урахуванням певних критеріїв (наприклад, вартості маршруту)
	Утиліта, що дозволяє мережному вузлу взаємодіяти з іншим вузлом, що знаходиться в тій же або віддаленій мережі, і визначати, чи є зв'язок із зазначеним вузлом і відповідає той на запити. Мережевий адміністратор може використовувати утиліту ping для швидкої перевірки з'єднань з глобальною мережею, зв'язуючись з яким-небудь віддаленим вузлом.
Real-Time Protocol (RIP)	Цей протокол служить для ефективного управління груповим потоковим мультимовленням, що ведеться в реальному масштабі часу і використовується для організації відеоконференцій або для роботи аналогічних програм мультимедіа (Див. розділ 10)
Real-Time Transport Control Protocol (RTCP)	Дозволяє керувати мережевим трафіком, спрощуючи використання програм мультимедіа, що працюють у реальному масштабі часу. (Див. розділ 10)
Resource Reservation Protocol (RSVP)	Протокол, що дозволяє виділяти мережеві ресурси для певних додатків (наприклад, резервувати смугу пропускання додатків мультимедіа) (Див. розділ 10)
Routing Information Protocol (RIP)	За допомогою цього протоколу маршрутизатори передають один одному зміст таблиць маршрутизації та визначають найменшу кількість ретрансляцій від одного вузла мережі до іншого
Simple Network Management Protocol (SNMP)	Протокол, що забезпечує збирання мережевої статистики, зберігає цю інформацію в базі даних
Traceroute (tracert)	Додаток, який дозволяє користувачеві визначити кількість ретрансляцій між двома вузлами мережі

У практичних завданнях 6-9 та 6-10 ви можете попрактикуватися у роботі з командою ping, а в завданнях 6-11 та 6-12 ви дізнаєтесь, як за допомогою команд tracert та ping визначити кількість ретрансляцій від однієї точки мережі до іншої.

Порівняння архітектури стека TCP/IP та еталонної моделіOSI

Як показано на рис. 6.11 компоненти стека TCP/IP, про які розповідалося в цьому розділі, відповідають рівням еталонної моделі OSI. З розвитком стека TCP/IP його компоненти дедалі більше випливають моделі OSI. Наприклад, на Фізичному та Канальному рівнях стек TCP/IP сумісний із мережами Ethernet, Token Ring, FDDI та ATM, а також із шинними мережами з передачею маркера (token bus). На Фізичному рівні стек TCP/IP підтримує коаксіал, виту пару та оптоволокно, а також бездротові комунікації. Крім того, на канальному рівні стек сумісний зі стандартом IEEE 802.2 на управління логічним каналом та МАС-адресацію.

Еквівалентом мережного рівня у стеку TCP/IP є протокол IP. Наступним рівнем сумісності служить Транспортний рівень, цьому рівні можуть працювати обидва протоколу – TCP і UDP. Верхні рівні моделі OSI є прикладними протоколами TCP/IP. Наприклад, Telnet функціонує на рівні, еквівалентному Сеансовому, а протоколи SMTP і FTP працюють на рівнях, аналогічних Представницькому та Прикладному рівням OSI.

Резюме

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

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

· Для надійної доставки пакета необхідно, щоб кожна IP-адреса була унікальною. Для ідентифікації конкретного вузла та мережі, до якої він належить, використовуються методи адресації ІР.

· Важливо розуміти, що головне призначення протоколу IPv6 – забезпечить логічний перехід від IPv4, щоб програми та мережні пристрої могли справлятися з новими вимогами у міру їх виникнення

· Фактично TCP/IP є стеком протоколів та додатків, що надають важливі можливості. Для підключення робочих станцій до хост-комп'ютерів використовують протокол Telnet (при цьому робочі станції виступають у ролі терміналів). FTP – протокол, який мільйони клієнтів використовують щодня для завантаження файлів із Інтернету. Протокол SMTP забезпечує роботу поштових служб, а DNS перетворює імена комп'ютерів на їх IP-адреси. Протокол DHCP автоматично призначає IP-адреси мережевим комп'ютерам. Протокол SNMP важливий для мереж, оскільки може збирати інформацію про продуктивність мережі та може використовуватись для пошуку несправностей. Протокол ARP дозволяє комп'ютерам або пристроям визначати МАС-адресу іншого комп'ютера або пристрою.

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

· Слід зазначити, що з розвитком протоколу TCP/IP деякі його компоненти стали більшою мірою відповідати еталонної моделі OSI.

Протокол управління RTP (RTCP - Real-Time Control Protocol) заснований на періодичної передачі пакетів управління всім учасникам сеансу зв'язку при використанні того ж механізму розподілу, що протокол RTP. Протокол нижчого рівня повинен забезпечити мультиплексування інформаційних та керуючих пакетів, наприклад, з використанням різних номерів портів UDP. Протокол RTCP виконує чотири основні функції.

Функції з першої по третю є обов'язковими, коли RTP використовується в IP-мультимовленні, і рекомендовані у всіх інших випадках. Розробникам програм RTP рекомендується уникати механізмів, що працюють лише у двосторонньому режимі та не масштабуються для збільшення кількості користувачів.

4.1. Вимоги до пакетів RTCP

Для передачі різноманітних інформації управління визначено кілька типів пакетів RTCP, зокрема:

• SR: звіт відправника, для статистичної інформації про передачу та прийом учасників, які є активними відправниками;
• RR: звіт одержувача для статистики прийому від учасників, які не є активними відправниками;
• SDES: пункти опису джерела, включаючи CNAME;
• BYE: покажчик завершення участі у телеконференції;
• APP: функції, що визначаються програмою.

Кожен пакет RTCP починається з фіксованої частини (подібної до фіксованої частини інформаційних пакетів RTP). За нею йдуть структурні елементи, які можуть мати змінну довжину згідно типу пакета, але завжди вирівнюються по 32-розрядній межі. Вимога вирівнювання та включення поля довжини у фіксовану частину призначені забезпечити «нарощування» пакетів RTCP. Декілька пакетів RTCP можуть з'єднуватися без будь-яких роздільників, формуючи складовий пакет RTCP, який передається в одному блоці даних протоколу нижчого рівня, наприклад протоколу UDP. Будь-якого покажчика на кількість окремих пакетів RTCP у складовому пакеті не передбачено, оскільки протоколи нижчого рівня для визначення закінчення складеного пакета містять відомості про його повну довжину.

Кожен окремий пакет RTCP у складеному пакеті може оброблятись окремо без будь-яких вимог щодо порядку або комбінації пакетів. Однак для коректного виконання функцій протоколу є такі вимоги.

Статистика прийому (у пакетах звіту відправника SR або одержувача RR) повинна посилатися так часто, як дозволяє смуга пропускання, щоб максимізувати точність статистики: отже, у кожен складовий пакет RTCP повинен включатися пакет звіту.

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

Кількість типів пакетів, які можуть з'являтися першими у складеному пакеті, повинна бути обмежена, щоб збільшити кількість постійних бітів у першому слові та зменшити ймовірність помилок при розпізнаванні пакетів RTCP серед інших пакетів протоколів.

Таким чином, всі пакети RTCP повинні передаватися в складовому пакеті, що включає, принаймні, два індивідуальні пакети (SR/RR і SDES), з наступним форматом, що рекомендується.

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

SR чи RR. Перший пакет RTCP у складеному пакеті повинен бути пакетом звіту, щоб полегшити перевірку коректності заголовка. Це потрібно, навіть якщо жодні дані не були ні надіслані, ні отримані і якщо єдиний пакет RTCP у складовому пакеті - це пакет BYE (тоді надсилається порожній пакет RR).

Додаткові пакети RR. Якщо кількість джерел, для яких передається статистика прийому, перевищує 31 (максимальна кількість джерел, що відзначаються в одному пакеті SR або RR), то за початковим пакетом звіту повинні йти додаткові пакети RR.

SDES. Пакет SDES, що містить пункт CNAME, повинен включатися до кожного складового пакету RTCP. Якщо потрібна конкретна програма, то додатково й інші пункти опису джерела можуть бути включені в пакет SDES відповідно до обмежень смуги пропускання (див. ).

BYE чи APP. Інші типи пакетів RTCP можуть виконуватися в будь-якому порядку, за винятком того, що пакет BYE повинен бути останнім пакетом, надісланим з даними SSRC/CSRC.

Для трансляторів і мікшерів бажано об'єднувати індивідуальні пакети RTCP з безлічі джерел, з якими вони працюють, в один складовий пакет щоразу, коли це можливо, щоб зменшити надмірність і не передавати зайві заголовки пакета (див. розділ 5). Якщо повна довжина складового пакета перевищує величину максимального блоку передачі (MTU - maximum transmission unit) мережевого шляху, то складовий пакет може бути сегментований на множину більш коротких складових пакетів, які будуть передані в окремих блоках даних протоколу нижчого рівня. Зауважимо, що й у разі кожен із складових пакетів повинен починатися з пакета SR чи RR.

Програма може ігнорувати вхідні пакети RTCP з невідомими типами. Додаткові типи пакетів RTCP можуть бути зареєстровані у Співтоваристві призначення номерів Internet IANA (Internet Assigned Numbers Authority).

4.2. Інтенсивність передачі пакетів RTCP

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

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

Обчислення смуги пропускання для трафіку управління та даних виконуються з урахуванням нижченаведених протоколів транспортного та мережевого рівнів (наприклад, UDP та IP) . Заголовки рівня ланки передачі (ЗПД) при обчисленнях не враховуються, оскільки пакет у міру його передачі може інкапсулюватися з різними заголовками рівня ЗПД.

Трафік управління повинен бути обмежений малою та відомою частиною смуги пропускання сеансу: малою настільки, щоб не постраждала основна функція транспортного протоколу – передача даних; відомою так, щоб трафік управління міг бути включений до специфікації смуги пропускання, даної протоколу резервування ресурсів, і так, щоб кожен учасник міг незалежно обчислити свою частку. Передбачається, що частина смуги пропускання сеансу, що виділяється для RTCP, повинна бути рівною 5%. Усі учасники сеансу повинні використовувати однакову величину смуги пропускання RTCP, щоб обчислені значення інтервалу передачі пакетів управління були однаковими. Тому ці константи мають бути встановлені для кожного профілю.

Алгоритм обчислення інтервалу між посилками складових пакетів RTCP для поділу серед учасників смуги пропускання, виділеної для трафіку управління, має такі основні характеристики.

Відправники колективно використовують принаймні 1/4 лінії пропускання трафіку управління так, як у сеансах з великою кількістю одержувачів, але з малою кількістю відправників; Щойно встановивши з'єднання, учасники протягом короткого інтервалу часу отримують CNAME передавальних сайтів.

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

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

Для автоматичної адаптації до змін обсягу переданої інформації управління обчислюється динамічна оцінка середнього розміру складеного пакета RTCP з використанням всіх отриманих і надісланих пакетів.

Цей алгоритм можна використовувати для сеансів, у яких передача пакетів допустима всім учасників. У цьому випадку параметр смуги пропускання сеансу - це добуток смуги пропускання індивідуального відправника на число учасників, і смуга пропускання RTCP становить 5% цієї величини.

4.2.1. Облік числа учасників сеансу зв'язку

Обчислення величин інтервалів передачі RTCP пакетів залежить від оцінки числа учасників сеансу зв'язку. Нові учасники враховуються, коли вони відзначаються у роботі та коли для кожного у таблиці створюється запис із відповідним ідентифікатором SSRC або CSRC (див. розділ 6.2). Нові записи не можуть мати сили, доки не буде отримано безліч пакетів, що містять новий SSRC. При отриманні пакета BYE з відповідним ідентифікатором SSRC записи з таблиці видаляються.

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

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

4.2.2. Виділення смуги пропускання для пакетів опису джерела SDES

Крім обов'язкового пункту CNAME пакетів опису джерела (SDES - source description) у цій статті розглянуті й інші пункти, такі як NAME (персональне ім'я), EMAIL (адреса електронної пошти) тощо. Програми повинні враховувати можливість передачі додаткових пунктів при розподілі смуги пропускання RTCP, тому що це сповільнить швидкість, з якою будуть передаватися звіти про прийом та CNAME, таким чином, погіршуючи характеристики протоколу. Рекомендується, щоб передачі додаткової інформації використовувалося трохи більше 20% смуги пропускання RTCP, виділеної одному учаснику. Крім того, не потрібно, щоб усі пункти SDES використовувалися кожною програмою. За тими з них, які включені у користування, повинні бути закріплені деякі частини смуги пропускання.

Наприклад, програма може бути розроблена так, щоб включати в пакети SDES тільки пункти CNAME, NAME, EMAIL та інших. Пункту NAME може бути призначений набагато більший пріоритет, ніж пункту EMAIL, тому що NAME буде індикуватися безперервно в інтерфейсі користувача цієї програми, тоді як пункт опису користувача EMAIL буде відображатися лише на вимогу. У кожному інтервалі RTCP надсилається пакет RR та пакет SDES з пунктом CNAME. Для сеансу з малим числом користувачів, що працює з мінімальним інтервалом звітності, це було б у середньому кожні 5 секунд. Кожен третій інтервал (15 секунд), один додатковий пункт був включений у пакет SDES. Сім із восьми разів це буде пункт NAME, а кожного восьмого разу (2 хвилини) - пункт EMAIL.

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

4.3. Пакети звітів відправника та одержувача (SR та RR)

Одержувачі RTP забезпечують зворотний зв'язок - оцінку якості прийому, використовуючи пакети звіту RTCP, які можуть приймати одну з двох форм залежно від того, є одержувач також відправником чи ні. Єдина різниця між формами звіту відправника (SR - sender report) та звіту одержувача (RR - receiver report), крім коду типу пакета, - це те, що звіт відправника включає 20-байтовий розділ інформації відправника для використання активними відправниками. SR передається, якщо сайт надсилав будь-які пакети даних протягом інтервалу, починаючи з передачі останнього або попереднього звіту, інакше передається RR.

Форми SR та RR включають нуль або більше блоків звіту прийому, один для кожного із джерел синхронізації, від яких одержувач прийняв пакети даних RTP, починаючи з останнього звіту. Для джерел, перелічених у списку CSRC, звіти не випускаються. Кожен блок звіту прийому забезпечує статистику щодо даних, одержаних від конкретного джерела, позначеного в цьому блоці. Оскільки максимум 31 блок приймальних звітів можливий у пакетах SR або RR, то додаткові пакети RR можуть бути поміщені у стек після початкових пакетів SR або RR. Це необхідно, щоб містити звіти прийому для всіх джерел, що відзначаються протягом інтервалу звітності, починаючи з останнього звіту.

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

4.3.1. Формат пакета звіту відправника (SR)

Пакет звіту відправника містить три основні секції і може містити додаткову четверту секцію розширення, що визначається профілем. Перша секція, заголовок має довжину 8 октетів (див. таблицю). Її поля мають такі значення.

Версія (V - version): 2 біти. Ідентифікує версію RTP, яка є однаковою у пакетах RTCP та інформаційних пакетах RTP. У статті розглядається протокол версії 2.

Додаток (P - padding): 1 біт. Якщо біт доповнення встановлено в 1, цей пакет RTCP в кінці містить деякі октети доповнення, які є частиною інформації управління. Останній акт доповнення - це лічильник додаткових октетів, які повинні ігноруватися. Додаток може бути потрібним деякими алгоритмами шифрування з фіксованими розмірами блоку. У складовому пакеті RTCP доповнення має використовуватися лише в останньому індивідуальному пакеті, тому що складовий пакет шифрується загалом.

Лічильник звітів прийому (RC - reception report count): 5 біт. Число блоків звітів прийому, що містяться в цьому пакеті. Нуль – можливе значення RC.

Тип пакету (PT – packet type): 8 біт. Містить константу 200 для ідентифікації пакета, як SR протоколу пакета RTCP.

Довжина: 16 біт. Довжина цього пакету RTCP у 32-розрядних словах мінус одне слово, включаючи заголовок та будь-яке доповнення (зміщення на одиницю робить нуль допустимою величиною і запобігає можливості нескінченного зациклювання при перегляді складеного пакету RTCP, з іншого боку, підрахунок 32-розрядних слів виключає перевірку допустимості значення довжини щодо кратності чотирьом).

SSRC: 32 біти. Ідентифікатор джерела синхронізації для джерела пакета SR.

Друга секція, інформація відправника, має довжину 20 октетів і є у кожному пакеті звіту відправника. Вона підсумовує факти передачі від цього відправника. Поля другої секції мають такі значення.

Тимчасова мітка NTP: 64 біти. Вказує абсолютний час, коли був надісланий цей звіт, так що вона може використовуватися в комбінації з тимчасовими мітками, які повернулися у звітах прийому від інших одержувачів, щоб виміряти час передачі на маршруті туди і назад для цих одержувачів. Одержувачі повинні очікувати, що точність вимірювання тимчасової мітки може бути прийнята набагато меншою, ніж роздільна здатність тимчасової мітки NTP. Невизначеність вимірювання для мітки не позначається, оскільки вона не може бути відома. Відправник, який може стежити за минулим часом, але не має даних про абсолютний час, натомість може використовувати час, що минув від початку з'єднання сеансу. Воно має бути меншим, ніж 68 років, - тоді старший розряд матиме нульове значення. Для оцінки минулого часу допустимо використання таймера дискретизації. Відправник, який не має жодних даних про абсолютний або минулий час, може встановлювати тимчасову мітку NTP в нуль.

Тимчасова мітка RTP: 32 біти. Відповідає тому самому часу, що і тимчасова мітка NTP (див. вище), але виражається в тих же одиницях і з тим самим випадковим зсувом, що і тимчасові мітки RTP в інформаційних пакетах. Ця відповідність може використовуватися для зовнішньої та внутрішньої мультимедійної синхронізації джерел, чиї тимчасові мітки NTP синхронізовані та можуть використовуватися незалежними від типу трафіку одержувачами для оцінки номінальної частоти таймера RTP. Зауважимо, що в більшості випадків ця тимчасова мітка не дорівнюватиме тимчасовій мітці RTP в будь-якому сусідньому інформаційному пакеті. Вона обчислюється з відповідної тимчасової мітки NTP з використанням зв'язку між лічильником тимчасової мітки RTP і реальним часом, який періодично підтримується контролем абсолютного часу в моменти дискретизації.

Лічильник пакетів відправника: 32 біти. Загальна кількість інформаційних пакетів RTP, переданих відправником від початку передачі до часу генерації пакета SR. Лічильник скидається, якщо відправник змінює ідентифікатор SSRC.

Лічильник октетів відправника: 32 біти. Загальна кількість октетів трафіку (тобто октетів пакета, не включаючи заголовок та доповнення), переданих в інформаційних пакетах RTP відправником з початку передачі аж до часу генерації цього пакета SR. Лічильник обнулюється, якщо відправник змінює ідентифікатор SSRC. Це поле можна використовувати для оцінки середньої швидкості передачі трафіку.

Третій розділ пакета SR містить нуль або більше блоків звіту прийому (починаючи з останнього звіту) залежно від кількості інших джерел, яких бачить цей відправник. Кожен блок звіту прийому передає статистичну інформацію про прийом пакетів RTP із одного джерела синхронізації. Одержувачі не переносять статистики, коли джерело змінює свій ідентифікатор SSRC внаслідок колізій. Ця статистика містить таку інформацію.

SSRC_n (ідентифікатор джерела): 32 біти. Ідентифікатор SSRC джерела, якого відноситься інформація в цьому блоці звіту прийому.

Частка втрат: 8 біт. Частина інформаційних пакетів RTP із джерела SSRC_n, втрачених, починаючи з моменту відправки попереднього пакета SR або RR, представлена ​​у вигляді цілого числа з фіксованою точкою без знака (у вигляді цілої частини числа після множення частки втрачених пакетів на 256). Ця частка визначається як кількість втрачених пакетів, поділена на кількість очікуваних пакетів. Якщо величина втрат - негативна через наявність дублікатів пакетів, частка втрат дорівнює нулю.

Загальна кількість втрачених пакетів: 24 біти. Загальна кількість інформаційних пакетів RTP із джерела SSRC_n, які були втрачені з моменту початку прийому. Це число є різницею між числом пакетів, що очікуються для отримання, і числом фактично отриманих пакетів. До отриманих пакетів входять будь-які пакети, у тому числі запізнілі і дублікати. Таким чином, пакети, які прибувають пізно, не зараховуються до втрачених, а число втрат може бути негативним, якщо є дублікати. Число очікуваних пакетів визначається як різниця останнього отриманого порядкового номера та початкового порядкового отриманого номера.

Розширений найбільший порядковий номер: 32 біти. Молодші 16 біт містять найбільший порядковий номер, отриманий в інформаційному пакеті RTP з джерела SSRC_n, а старші 16 біт розширюють цей порядковий номер відповідним лічильником циклів порядкового номера . Зауважимо, що різні одержувачі в рамках того самого сеансу генерують різні розширення порядкового номера, якщо час початку для них значно різниться.

Джиттер прибуття: 32 біти. Це - статистична оцінка різниці відносного часу прибуття інформаційних пакетів RTP, що вимірюється в одиницях тимчасової мітки та виражається цілим числом без знака. Джиттер прибуття J визначається як середня величина (згладжене абсолютне значення) різниці D часу між надходженнями двох пакетів одержувачу та часу між моментами передачі цих пакетів. Як показано в рівнянні нижче, це еквівалентно різниці відносного часу передачі для двох пакетів (відносний час передачі - це різниця між часовою міткою пакета RTP і значенням таймера одержувача під час надходження, вираженим у тих самих одиницях).

Якщо Si - це тимчасова мітка RTP з пакета i, а Ri - час надходження в одиницях мітки тимчасової RTP для пакета i, то для двох пакетів i і j, D може бути виражено як

D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si).

Джиттер прибуття обчислюється безперервно у міру того, як кожен інформаційний пакет i надходить від джерела SSRC_n, з використанням цієї різниці D для цього пакета та попереднього пакету i-1 у порядку надходження (не обов'язково в послідовності передачі), згідно з формулою

J=J+(D(i-1,i)|-J)/16.

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

Тимчасова мітка останнього SR (LSR): 32 біти. Середні 32 біти з 64 бітів тимчасової мітки NTP (як показано в розділі 2.4), отримані як частина останніх пакетів звітів відправника RTCP (SR) з джерела SSRC_n. Якщо SR ще не отримано, то тимчасова мітка LSR має нульове значення.

Затримка з останнього SR (DLSR): 32 біта. Затримка в приймачі пакетів, виражена в одиницях, рівних 1/65536 секунд, між отриманням останнього пакета SR з джерела SSRC_n і посилкою цього блоку звіту про прийом. Якщо пакет SR ще не отримано від SSRC_n, то поле DLSR має нульове значення.

За допомогою значень тимчасової мітки останнього SR (LSR) та затримки в приймачі з моменту останнього SR (DLSR) джерело SSRC_n може обчислювати затримку розповсюдження пакетів на шляху до отримувача SSRC_r та назад (кругову затримку). При надходженні звіту прийому джерело SSRC_n фіксує час цієї події Т. Потім він обчислює загальний час подвійного проходу Т-LSR з використанням поля тимчасової мітки останнього SR (LSR) і віднімає затримку DLSR, в результаті отримуючи час поширення пакета туди і назад (Т-LSR -DLSR). Це може використовуватися як приблизна відстань до кластера одержувачів, хоча деякі лінії мають дуже асиметричні затримки. звіту

розширений найбільший порядковий номер 1 джиттер прибуття тимчасова мітка останнього SR (LSR) затримка з моменту останнього SR (DLSR) SSRC другого джерела (SSRC_2) Блок . . . звіту 2 розширення, що залежать від профілю

Формат пакета звіту одержувача RR (receiver report) такий самий, як і формат пакета SR, за винятком того, що поле типу пакета містить константу, що дорівнює 201, а п'ять слів інформації відправника відсутні (тимчасові мітки NTP та RTP та лічильники пакетів та октетів відправника ). Поля, що залишилися, мають те саме значення, що і для пакета SR.

Коли немає жодної передачі даних або прийому, про які можна було б повідомити, на чолі складеного пакету RTCP міститься порожній пакет RR (RC = 0).

4.3.3. Розширення звітів відправника та одержувача

Якщо є додаткова інформація про відправника або одержувачів, яка повинна регулярно повідомлятись, профіль повинен визначати розширення до звіту відправника та одержувача. Використовувати цей метод краще, ніж визначати інший тип пакету RTCP, тому що він вимагає менше надмірності:

• менше октетів у пакеті (не потрібно ні заголовка RTCP, ні поля SSRC);
• більш простий і швидкий аналіз, тому що програми, що виконуються згідно з цим профілем, можуть програмуватися так, щоб завжди розглядати поля розширення безпосередньо доступному місці після звітів прийому.

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

4.3.4. Аналіз звітів відправника та одержувача

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

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

Розглянемо приклад обчислення інтенсивності втрат пакета на інтервалі між двома звітами прийому. Різниця значень кумулятивних лічильників втрачених пакетів дає кількість пакетів, втрачених протягом цього інтервалу. Різниця останніх отриманих розширених порядкових номерах дає кількість пакетів, очікуваних протягом інтервалу. Ставлення цих двох величин - частка втрат пакетів на інтервалі. Це ставлення має дорівнювати значення поля частки втрат, якщо ці два звіти є послідовними, в іншому випадку - ні. Число втрат пакетів за 1 секунду може бути отримано шляхом розподілу частки втрат на різницю тимчасових міток NTP, що виражається в секундах. Кількість отриманих пакетів - це очікуваних пакетів мінус число втрачених. Кількість очікуваних пакетів може також використовуватися визначення статистичної достовірності будь-яких оцінок втрат. Наприклад, втрата одного пакета з п'яти має нижчу представницьку цінність, ніж втрата 200 пакетів із 1000.

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

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

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

Протокол управління передачею (Transmission Control Protocol - TCP) забезпечує надійну передачу даних серед IP. TCP відноситься до транспортного рівня еталонної моделі OSI (4-й рівень). TCP надає такі служби, як потокова передача даних, надійність, ефективне керування потоком, дуплексний режим та мультиплексування.

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

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

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

У дуплексному режимі TCP-процес може одночасно пересилати та приймати пакети.

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

Встановлення ТСР-з'єднання

Для використання надійних транспортних служб TCP-вузли повинні встановлювати один з одним сеанси, орієнтовані з'єднання. Установка з'єднання виконується за механізмом, який називається триетапною синхронізацією (three-way handshake).

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

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

Перший вузол (Вузол А) ініціює з'єднання, відправляючи пакет з початковим порядковим номером та біт синхронізації SYN для індикації запиту з'єднання. Другий вузол (Вузол) отримує SYN, записує порядковий номер X і відповідає підтвердженням SYN (разом з АСК = X + 1). Вузол показує власний порядковий номер (SEQ = Y). Тоді, якщо АСК дорівнює 20, це означає, що вузол прийняв байти з 0 по 19 і чекає наступний байт 20. Ця технологія називається підтвердженням передачі. Потім Вузол А підтверджує прийом всіх байтів, посланих Вузлом з підтвердженням передачі, вказуючи наступний байт, який Вузол А очікує отримати (АСК = Y + 1). Після цього може розпочинатися передача даних.

Підтвердження прийому та повторна передача

Простий транспортний протокол може забезпечувати надійність і таку технологію управління потоком, коли вихідний вузол посилає пакет, запускає таймер і чекає підтвердження прийому перед відправкою нового пакета. Якщо підтвердження не отримано після часу, вузол передає пакет ще раз. Ця технологія називається підтвердженням прийому та повторною передачею (Positive Acknowledgment and Retransmission - PAR).

Присвоюючи кожному пакету порядковий номер, PAR дозволяє вузлам відстежувати пакети, втрачені чи дубльовані внаслідок затримок мережі та передчасної повторної передачі. Номери послідовностей надсилаються назад як повідомлення у можливості відстеження підтверджень прийому.

Однак PAR неефективно використовує пропускну здатність, тому що перед відправкою нового пакета вузол повинен чекати на підтвердження і, отже, пакет можна передавати лише один за одним.

Ковзне вікно TCP

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

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

Припустимо, що TCP-відправнику треба надіслати за допомогою ковзного вікна послідовність байт (пронумерованих від 1 до 10) одержувачу з розміром вікна 5. Відправник поміщає у вікно перші 5 байт, передає їх все відразу і чекає на підтвердження прийому.

Одержувач відповідає з АСК, рівним 6, показуючи, що отримав байти з 1 по 5 і чекає байта 6. У тому ж пакеті одержувач показує, що розмір вікна дорівнює 5. Відправник зсуває ковзне вікно на 5 байт вправо і передає байти з 6 по 10. Одержувач відповідає АСК, рівним 11, показуючи, що він чекає на байт 11. У цьому пакеті одержувач може вказати, що його розмір вікна дорівнює 0 (оскільки, наприклад, його внутрішні буфери заповнені). Тоді відправник більше не зможе посилати байти, поки одержувач не надішле інший пакет з ненульовим розміром вікна.

Формат ТСР-пакету

Поля та повний формат TCP-пакету показані на рис. 35.10.

Мал. 35.10. Формат ТСР-пакету

Опис полів ТСР-пакету

Нижче описано поля TCP-пакету, показані на рис. 35.10.

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

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

Номер підтвердження. Порядковий номер наступного байта даних, який очікує отримати отримувач.

Зсув даних. Число 32-розрядних слів у заголовку TCP.

Резервні. Область зарезервована для використання в майбутньому.

Прапори. Різна керуюча інформація, у тому числі біти SYN та АСК, що використовуються для встановлення з'єднання, і біт FIN для розриву з'єднання.

Вікно. Розмір приймального вікна одержувача (обсяг буфера для даних).

Контрольна сума. Показує, чи не було заголовка пошкоджено під час передачі.

Вказівник терміновості. Вказує перший байт термінових даних у пакеті.

Параметри. Різні додаткові параметри TCP.

Дані. Інформація про верхній рівень.

Література:

Посібник з технологій об'єднаних мереж, 4-те видання. : Пров. з англ. – К.: Видавничий дім «Вільямі», 2005. – 1040 с.: Іл. – Парал. тит. англ.

TCP (Transmission Control Protocol) – протокол керування передачею. Для забезпечення надійної доставки даних на рівні транспортного протоколу в додатках використовується протокол TCP, який перевіряє факт доставки даних через мережу в потрібному порядку. TCP – надійний потоковий протокол, що вимагає створення логічних з'єднань. Надійність TCP забезпечує механізм підтвердження прийому із повторною передачею. При використанні даного механізму повторне відправлення даних відбуватиметься доти, доки не отримає підтвердження від системи-адресата, що дані були успішно передані.

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

Розглянемо процес так званого "рукостискання" - встановлення TCP-з'єднання. З боку клієнта відправляється пакет із виставленим прапором SYN – це означає ініціалізацію TCP-сесії. На даному етапі хостом буде згенеровано порт джерела та порт призначення (порт джерела вибирається випадково з діапазону 1024 – 655535). Порт призначення залежить від конкретної служби (http – 80, ftp – 21, pop3 – 110).

При отриманні пакета сервер, якщо він не проти з'єднання, посилає пакет у відповідь з бітами SYN, ACK. ACK означає біт підтвердження. Також в TCP-заголовку сервер генерує довільне число Sequence number, а до Acknowledgment number додає одиницю.

Нарешті хост передає пакет, що підтверджує отримання даних від сервера, а також перший блок даних.

Заголовок протоколу TCP містить поле, яке називається Sequence Number, в яке заноситься номер деякої послідовності. Також є поле Acknowledgment Number, яке говорить про підтвердження пакета з цим номером. Числа Sequence Number, Acknowledgment Number застосовуються для збереження порядку проходження даних. Але якщо говорити конкретніше, то Sequence Number є точкою звіту системи нумерації байтів. З міркувань безпеки ISN слід бути випадковим числом. Acknowledgment Number служить для підтвердження прийому та управління потоком. Підтвердження повідомляє джерелу, який обсяг даних отримано і скільки даних адресат здатний прийняти. Номер підтвердження – це порядковий номер наступного байта, який очікується адресатом.

Поле Windows size (розмір вікна) – містить кількість байт, що може прийняти адресат. Вікно є вказівкою джерела, що можна продовжувати передачу сегментів, якщо загальний обсяг байт, що передаються менше байтового вікна адресата. Адресат управляє потоком байтів джерела, змінюючи розмір вікна. Нульове вікно наказує відправнику припинити передачу, доки не буде отримано ненульове значення вікна.

Поля Source port, Destination port – порт джерела, порт призначення. UGR,

Поля UGR, ACK, PSH, RST, SYN. FIN - керуючі біти:

• UGR - вказівник терміновості, показує пріоритет TCP-пакетів
• ACK – підтвердження, позначає цей пакет як підтвердження отримання
• PSH - виштовхування, виштовхує поставлені в чергу дані з буферів
• RST – скидання, скидає з'єднання TCP після завершення чи після розриву
• SYN – синхронізація, синхронізує з'єднання
• FIN – завершення, завершує передачу даних

На малюнку нижче показаний потік даних TCP із нульовим значенням вихідного порядкового номера. Адресат отримав і підтвердив отримання 2000 байт, тому поточний номер підтвердження ACK = 2001. Крім того, адресат має можливість прийняти ще 6000 байт, а тому пред'являє вікно зі значенням 6000. Джерело відправляє сегмент розміром 2000 байт1 з порядковим номером. 2001 та наступних ще не були отримані підтвердження, проте джерело продовжує передачу даних, поки не вичерпано ресурси вікна. Якщо на момент заповнення вікна джерелом для вже відправлених даних не отримано підтвердження, після закінчення певного інтервалу часу джерело повторно передає дані, починаючи з першого непідтвердженого байта.

Цей метод гарантує надійність доставки даних адресату. Крім того, TCP відповідає за доставку отриманих від IP даних відповідному додатку. Програма, якій призначаються дані, позначається 16-бітовим числом, номером порту. Значення вихідного порту та порту призначення знаходяться в заголовку TCP. Коректний обмін даними із прикладним рівнем – це важлива складова функціональності служб транспортного рівня.

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

Підписуйтесь на нашу

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

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

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

Поняття стека протоколів

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

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

Принципи використання адрес у стеку протоколів

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

• Адреси різного типу мають бути узгоджені.Наприклад, перетворення домену сайту на IP-адресу сервера і назад, або перетворення імені вузла на адресу і назад. Таким чином стає можливий доступ до точки не тільки за допомогою IP-адреси, але і за інтуїтивною назвою.
• Адреси мають бути унікальними.Це викликано тим, що в окремих випадках пакет повинен потрапити тільки в одну конкретну точку.
• Необхідність конфігурування локальних обчислювальних мереж.

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

Саме тому для мереж TCP/IP було винайдено спеціальний підхід, який став відмінною рисою стека протоколів. Було введено поняття – масштабованість.

Рівні стеку протоколів TCP/IP

Тут є певна ієрархія. Стек протоколів TCP/IP передбачає чотири рівні, кожен із яких обробляє свій набір протоколів:

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

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

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

Цей рівень надає вищому (прикладному) два типи сервісу:

• Здійснює гарантовану доставку за допомогою протоколу ТСР.
  
• Здійснює доставку наскільки можна за протоколом UDP .

Щоб забезпечити гарантовану доставку, згідно з протоколом TCP встановлюється з'єднання, яке дозволяє виставляти на пакетах нумерацію на виході та підтверджувати їх прийом на вході. Нумерація пакетів та підтвердження прийому – це так звана службова інформація. Цей протокол підтримує передачу у режимі "Дуплекс". Крім того, завдяки продуманому регламенту протоколу він вважається дуже надійним.

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

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

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

На цьому рівні використовуються такі мережеві протоколи TCP/IP: ICMP, IP, RIP, OSPF. Основним і найбільш популярним на мережному рівні, звичайно ж є протокол IP (Internet Protocol). Основним його завданням є передача пакетів від одного роутера до іншого, доки одиниця даних не потрапить на мережевий інтерфейс вузла призначення. Протокол IP розгортається як на хостах, а й у мережевому устаткуванні: маршрутизаторах і керованих комутаторах. Протокол IP працює за принципом негарантованої доставки з максимальними зусиллями. Т. е. для відправки пакета немає необхідності заздалегідь встановлювати з'єднання. Такий варіант призводить до економії трафіку та часу на русі зайвих службових пакетів. Пакет прямує у бік призначення, і цілком можливо, що вузол залишиться недоступним. У такому разі повертається повідомлення про помилку.

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

• Кодування пакета в одиниці даних проміжної мережі.
• Перетворення інформації про місце призначення на стандарти необхідної підмережі та відправлення одиниці даних.

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

Одиниці даних, що передаються

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

Щоб мати уявлення про те, що і в який час відбувається з даними, потрібно було придумати таку термінологію:

• Потік даних- Дані, які надходять на транспортний рівень від протоколів вищого прикладного рівня.
• Сегмент - фрагмент даних, куди дробиться потік за стандартами протоколу TCP.
• Датаграма(Особливо безграмотні вимовляють як "Дейтаграма") - одиниці даних, які одержуються шляхом дроблення потоку за допомогою протоколів, що працюють без встановлення з'єднання (UDP).
• Пакет- одиниця даних, вироблена у вигляді протоколу IP.
• Протоколи TCP/IP упаковують IP-пакети в блоки даних, що передаються по складових мережах, які називаються кадрамиабо кадрами.

Типи адрес стеку протоколів TCP/IP

Будь-який протокол передачі даних TCP/IP для ідентифікації вузлів використовує один із наступних типів адрес:

• Локальні (апаратні) адреси.
• Мережеві адреси (IP-адреси).
• Доменні імена.

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

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

У результаті було розроблено систему, коли він вузлам призначається IP адреса і маска підмережі. Маска підмережі показує, скільки біт відводиться під номер мережі, а скільки під номер вузла. IP адреса складається з 32 біт, розділених на блоки по 8 біт.

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

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

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

IP-адреса. Формат. складники. Маска підмережі

IP адреса - 32-бітове число, яке в традиційному поданні записується у вигляді чисел, від 1 до 255, розділених між собою крапками.

Вигляд IP-адреси в різних форматах запису:

• Десятковий вид IP-адреси: 192.168.0.10.
• Двійковий вигляд тієї ж IP адреси: 11000000.10101000.00000000.00001010.
• Запис адреси у шістнадцятковій системі числення: C0.A8.00.0A.

Між ID мережі та номером точки у записі немає роздільного знака, але комп'ютер здатний їх розділяти. Для цього існує три способи:

1. Фіксований кордон.У цьому способі вся адреса умовно ділиться на частини фіксованої довжини побайтно. Таким чином, якщо під номер мережі віддати один байт, тоді ми отримаємо 28 мереж по 224 вузлів. Якщо кордон зрушити ще на байт праворуч, тоді мереж стане більше – 2 16 , а вузлів стане менше – 2 16 . На сьогоднішній день підхід вважається застарілим та не використовується.
2. Маска підмережі.Маска йде в парі з IP-адресою. Маска має послідовність значень "1" у тих розрядах, які відведені під номер мережі, та певну кількість нулів у тих місцях IP адреси, які відведені на номер вузла. Кордон між одиницями та нулями в масці – це межа між ідентифікатором мережі та ID вузла в IP-адресі.
3. Метод класів адрес.Компромісний метод. При його використанні розміри мереж не можуть бути обрані користувачем, однак є п'ять класів – А, В, С, D, Е. Три класи – А, В та С – призначені для різних мереж, а D та Е – зарезервовані для мереж спеціального призначення . У класовій системі кожен клас має межу номера мережі та ID вузла.

Класи IP адрес

До класу Авідносяться мережі, в яких мережа ідентифікується за першим байтом, а три решти є номером вузла. Всі IP адреси, які мають у своєму діапазоні значення першого байта від 1 до 126 – це мережі класу А. Кількісно мереж класу А виходить зовсім мало, зате в кожній з них може бути до 224 точок.

Клас В- мережі, в яких два вищі біти дорівнюють 10. У них під номер мережі та ідентифікатор точки відводиться по 16 біт. В результаті виходить, що кількість мереж класу У більшу сторону відрізняється від кількості мереж класу А кількісно, ​​але вони мають меншу кількість вузлів - до 65 536 (2 16) шт.

У мережах класу С- зовсім мало вузлів - 2 8 в кожній, але кількість мереж величезна, завдяки тому, що ідентифікатор мережі в таких структурах займає три байти.

Мережі класу D- вже належать до спеціальних мереж. Він починається з послідовності 1110 і називається груповим адресою (Multicast adress). Інтерфейси, що мають адреси класу А, В і С, можуть входити в групу і отримувати ще й індивідуальну групову адресу.

Адреси класу Е- у резерві на майбутнє. Такі адреси починаються з послідовності 11110. Швидше за все, ці адреси будуть застосовуватися як групові, коли настане брак IP адрес у глобальній мережі.

Налаштування протоколу TCP/IP

Налаштування протоколу TCP/IP доступне на всіх операційних системах. Це - Linux, CentOS, Mac OS X, Free BSD, Windows 7. Протокол TCP/IP потребує лише наявності мережного адаптера. Зрозуміло, серверні операційні системи здатні більше. Дуже широко за допомогою серверних служб налаштовується протокол TCP/IP. IP-адреси у звичайних настільних комп'ютерах задаються в налаштуваннях мережних підключень. Там налаштовується мережна адреса, шлюз - IP адреса точки, що має вихід у глобальну мережу, та адреси точок, на яких розташовується DNS сервер.

Протокол Інтернету TCP/IP може налаштовуватися вручну. Хоча не завжди в цьому є потреба. Можна отримувати параметри протоколу TCP/IP з адреси сервера, що динамічно роздає, в автоматичному режимі. Такий спосіб використовують у великих корпоративних мережах. На DHCP сервер можна зіставити локальну адресу до мережного, і як тільки в мережі з'явиться машина із заданою IP-адресою, сервер відразу дасть йому заздалегідь підготовлену IP-адресу. Цей процес називається резервування.

TCP/IP Протокол дозволу адрес

Єдиний спосіб встановити зв'язок між MAC-адресою та IP адресою – ведення таблиці. За наявності таблиці маршрутизації кожен мережевий інтерфейс обізнаний про свої адреси (локальну та мережну), проте постає питання, як правильно організувати обмін пакетами між вузлами, застосовуючи протокол TCP/IP 4.

Навіщо було придумано протокол дозволу адрес (ARP)? Щоб зв'язувати сімейство TCP/IP протоколів та інших систем адресації. На кожному вузлі створюється таблиця відповідності ARP, яка заповнюється опитуванням усієї мережі. Це відбувається після кожного вимкнення комп'ютера.

ARP таблиця

Такий приклад складеної ARP таблиці.