6 Зміст протоколу
Протокол лабораторної роботи “Програмна реалізація протоколів ТСР/ІР” оформлюється у робочому зошиті в послідовності, котра визначається стандартом підприємства з основ лабораторного практикуму. Протокол має містити назву лабораторної роботи та її мету, результати виконання домашнього завдання згідно з вимогами пунктів 1 та 3 домашнього завдання; результати виконання пунктів лабораторного завдання 6...12; висновки.
7 Список рекомендованої літератури
1 Робачевский А. М. Операционная система UNIX. — СПб.: БХВ-Петербург, 2002.
2 Ивановский С. Операционная система UNIX. — М.: Познавательная книга плюс, 2000.
3 Дегтярев Е. К. Введение в UNIX. — М.: МП "Память", 1991.
4 Снейдер И. Эффективное программирование TCP/IP. — СПб.: Питер, 2002.
5 http://www.freebsd.org.ru
6 http://www.anriintern.com/computer/freebsd/
7 http://www.linuxrsp.ru/freebsd/
Лабораторна робота № 18
ІНСТРУМЕНТИ ТА РЕСУРСИ НАЛАГОДЖЕННЯ
МЕРЕЖ ТА МЕРЕЖНИХ ДОДАТКІВ
1 Мета роботи
Метою роботи є ознайомлення зі структурою, програмною реалізацією та використанням засобів налагодження мереж та набуття навичок роботи з ними.
2 Основні положення
До найголовніших та корисних інструментів та ресурсів моніторінгу та налагодження мереж належать утиліта ping, програми tсpdump, traceroute, ttсp, netstat.
2.1 Утиліта ping
Основні призначення утиліти ping — перевірка наявності зв’язку поміж двома хостами. Утиліта не використовує протоколу TCP або UDP, тому не потребує жодного добре відомого порту. Для перевірення наявності зв’язку ping користується функцією луна-контролю, вбудованою в протокол ICMP, який вважається частиною IP. На рис. 2.1 наведено структуру пакета, який надсилає ping.
ІР-заголовок
Луна-повідомлення запит/відповідь для протоколу
ICMP
20 байт
8 + n байт
Рисунок 2.1 — Формат пакета ping
Кількість додаткових байтів n в пакеті ping обирається для OC UNIX дорівнюваним 56, але може бути скоригована за допомогою прапорця -s. За умовчанням у більшості версій додаткові дані — це циклічно переставлювані по колу дані.
На рис. 2.2 наведено пакет луна-повідомлення запит/відповідь протоколу ICMP.
Рисунок 2.2 — Пакет луна-повідомлень запит/відповідь протоколу ICMP
Поля Ідентифікатор та Порядковий номер не використовуються ані в луна-запиті, ані в луна-відповіді, тому їх можна задіяти для ідентифікування отриманих ICMP-відповідей. Для IP-дейтаграм немає спеціального порту, вони можуть доставлятися кожному процесові, який відкрив простий (raw) сокет із зазначенням протоколу ICMP. Утиліта ping розміщує свій ідентифікатор процесу у полі Ідентифікатор, завдяки чому кожен запущений екземпляр здатен відрізнювати відповіді на свої запити. У полі Порядковий номер ping розміщує значення лічильника, щоби зв’язати відповідь із запитом. Саме це значення ping показує як icmp-seg. Проілюструємо на прикладі роботу ping.
Припустімо, що треба зв’язатися з хостом А за допомогою програми telnet, але з’єднання не встановлюється через тайм-аут. Причин тому може бути кілька: проблема на ділянці мережі поміж двома хостами, не працює сам хост А, не запущено сервер telnet, не підтримується стек TCP/IP на хості. Перш за все перевірюється, чи можна дістатися хоста А. Якщо робота йде нормально, то мережа є в порядку, а проблема скоріш за все в самому хості А. Якщо неможливо отримати відповідь від хоста А, то треба “пропінгувати” найближчий маршрутизатор, аби зрозуміти, чи можна дістатися межі власної мережі. Якщо все проходить успішно, то далі слід скористатися програмою traceroute, щоб виявити маршрутизатор, який “зазбоїв”, або зробити припущення щодо цього. Оскільки утиліта ping працює на рівні протоколу IP, вона не залежить від правильності конфігурації TCP чи UDP, тому іноді є корисним пропінгувати власний хост з метою перевірки власного мережного програмного забезпечення. Для цього ping треба вказати спочатку зворотну адресу — localhost(127.0.0.1), а потім адреси одного чи кількох мережних інтерфейсів, аби переконатись у тому, що їх правильно сконфігуровано. На рис.2.3 подано результат короткого прогону ping.
%ping 195.5.27.1
PING 195.5.27.1 (195.5.27.1): 56 data bytes
64 bytes from 195.5.27.1: icmp_seq=0 ttl=63 time=5.397 ms
64 bytes from 195.5.27.1: icmp_seq=1 ttl=63 time=5.486 ms
64 bytes from 195.5.27.1: icmp_seq=2 ttl=63 time=5.208 ms
64 bytes from 195.5.27.1: icmp_seq=3 ttl=63 time=5.162 ms
64 bytes from 195.5.27.1: icmp_seq=4 ttl=63 time=5.274 ms
64 bytes from 195.5.27.1: icmp_seq=5 ttl=63 time=5.166 ms
64 bytes from 195.5.27.1: icmp_seq=6 ttl=63 time=5.221 ms
64 bytes from 195.5.27.1: icmp_seq=7 ttl=63 time=5.225 ms
64 bytes from 195.5.27.1: icmp_seq=8 ttl=63 time=5.211 ms
64 bytes from 195.5.27.1: icmp_seq=9 ttl=63 time=13.853 ms
64 bytes from 195.5.27.1: icmp_seq=10 ttl=63 time=5.134 ms
^C
--- 195.5.27.1 ping statistics ---
11 packets transmitted, 11 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.134/6.031/13.853/2.476 ms
Рисунок 2.3 — Короткий прогін ping
Період колового обернення, RTT, для різних пакетів мало змінюється й залишається у межах 500 мс. RTT змодифіковується в діапазоні від 480,137 мс до 598,534 мс зі стандартним відхиленням 40 мс.
При більш тривалому прогоні (близько двох хвилин) результат істотно не зміниться й можна припустити, що навантаження на мережу є незмінне. Значний розкид RTT — це зазвичай ознака того, що навантаження змінюється. При підвищенні навантаження збільшується довжина черги в маршрутизаторі, а разом з нею й RTT. При зменшенні навантаження черга зменшується, що призводить до зменшення RTT. Спостерігаючи за значеннями та дисперсією RTT, а також кількістю загублених відповідей, можна зробити висновки щодо трафіка в мережі.