План нмв 2004 р. Укладачі

Вид материала

Документы

Содержание Інструменти та ресурси налагодження 2 Основні положення 2.1 Утиліта ping 2.2 Програма traceroute 2.3 Програма ttcp 2.4 Програма tcpdump

Подобный материал:

• Перлина українського театру, 100.45kb.
• Конспект лекции Методика формализованного составления обзора План, 144.39kb.
• Пояснительная записка данная рабочая учебная программа составлена в соответствии, 120.81kb.
• Принят Государственной Думой 24 мая 1996 года. Одобрен Советом Федерации 5 июня 1996, 39.78kb.
• Програма дій щодо реалізації положень Болонської декларації в системі вищої освіти, 77.05kb.
• Одобрен Советом Федерации 24 сентября 2003 года Распоряжением Правительства, 2307.63kb.
• Список статей периодических изданий. Базисный план для среднего (полного) общего образования., 191.48kb.
• Краткое содержание темы, 108.84kb.
• Вестник Банка России, n 2, 14. 01. 2004; указанием Банка России от 1 июня 2004 года, 20.19kb.
• Указатель литературы, 117.65kb.

Лабораторна робота № 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, а також кількістю загублених відповідей, можна зробити висновки щодо трафіка в мережі.


2.2 Програма traceroute


Програма traceroute — це важливий інструмент для відшукування помилок маршрутизації, вивчання трафіка в Internet та досліджування топології мережі. Програма намагається визначати маршрут поміж двома хостами в мережі, примушуючи кожний проміжний маршрутизатор надсилати ICMP-повідомлення про помилку хосту-відправлячеві. На рис. 2.4 подано маршрут до хоста, який відстежує traceroute. Перше число зліва у кожному рядку — це номер проміжного вузла. За ним іде ім’я хоста або маршрутизатора у цьому вузлі й далі IP-адреса вузла. Якщо ім’я вузла виявити не вдається, traceroute видає лише IP-адресу. Така ситуація спостерігається у вузлі 13. Вочевидь, що за умовчанням програма тричі намагалась визначати ім’я хосту або маршрутизатора, а три числа, що йдуть за IP-адресою, — це періоди RTT для кожної з трьох спроб. Якщо за чергової спроби на запит ніхто не відповідає або відповідь губиться, то замість відповіді виводиться “*”.


bsd: $ traceroute ziggy. usf. edu

traceroute to ziggy. usf. edu (131. 247. 1. 40), 30 hops max,

40 byte packets

1 tam-f1-pm8. netcom. net (163. 179. 44. 15)

128. 960 ms 139. 230 ms 129. 483 ms

2 tam-f1-gw1. netcom. net (163. 179. 44. 254)

139. 436 ms 129. 226 ms 129. 570 ms

3 h1-0.mig-f1-gw1. netcom. net (165. 236. 144. 110)

279. 582 ms 199. 325 ms 289. 611 ms

4 a5-0-0-7.was-dc-gw1. netcom. net (163. 179. 235. 121)

179. 505 ms 229. 543 ms 179. 422 ms

5 h1.mae-east. netcom. net (163. 179. 220. 182)

189. 258 ms 179. 211 ms 169. 605 ms

6 s1-mae-e-f0-0. sprintlink. net (192. 41. 177. 241)

189. 999 ms 179. 399 ms 189. 472 ms

7 s1-bb4-dc-1-0-0. sprintlink. net (144. 228. 10. 41)

180. 048 ms 179. 388 ms 179. 562 ms

8 s1-bb10-rly-2-3. sprintlink. net (144. 232. 7. 153)

199. 433 ms 179. 390 ms 179. 468 ms

9 s1-bb11-rly-9-0. sprintlink. net (144. 232. 0. 46)

199. 259 ms 189. 315 ms 179. 459 ms

10 s1-bb10-or1-1-0. sprintlink. net (144. 232. 9. 62)

189. 987 ms 199. 508 ms 219. 252 ms

11 s1-gw3-or1-4-0-0. sprintlink. net (144. 232. 2. 154)

219. 307 ms 209. 382 ms 209. 502 ms

12 s1-usf-1-0-0. sprintlink. net (144. 232. 154. 14)

209. 518 ms 199. 288 ms 219. 495 ms

13 131.247.254.36 (131.247.254.36) 209.318 ms 199.281 ms 219.588 ms

14 ziggy. usf. edu (131. 247. 1. 40) 209.591 ms * 210.159 ms


Рисунок 2.4 — Маршрут до хоста


У кожній IP-дейтаграмі є поле ТТL (Time-to-Live) — тривалість життя. Це поле зменшується на одиницю кожним маршрутизатором, через який проходить дейтаграма. Коли TTL дорівнюватиме нулю, дейтаграма знищується. Офіційно TTL вимірюється в секундах, але інтерпретується маршрутизаторами як лічильник проміжних вузлів. Після знищення дейтаграми маршрутизатор надсилає джерелу ICMP-повідомлення “завершено час у путі”.

Програма tracerout використовує цю властивість. Спочатку вона надсилає одержувану UDP-дейтаграму, в якій TTL встановлено в одиницю. Перший маршрутизатор визначає одиницю в полі TTL, відкидає дейтаграму й надсилає відправлячеві ICMP-повідомлення, з якого він дізнається про перший проміжний вузол з поля ”адреса відправляча” в заголовку ICMP. Програма traceroute намагається виявити ім’я вузла за допомогою функції gethostbyaddr(3N). З метою отримання інформації про другий вузол traceroute повторює процедуру, але поле TTL встановлюється дорівнюваним двом. Маршрутизатор на першому проміжному вузлі зменшить TTL на одиницю й надішле дейтаграму на другий вузол. Другий маршрутизатор визначить одиницю в полі TTL, відкине дейтаграму та надішле ICMP-повідомлення відправлячеві.

Повторюючи ці дії, але зі збільшеним на одиницю значенням TTL кожного разу, tracerout може відстежити весь маршрут від відправляча до одержувача. Коли дейтаграма з достатньо великим початковим значенням TTL врешті надходить до отримувача, TTL дорівнюватиме одиниці. Оскільки далі передавати дейтаграму нема куди, стек TCP/IP спробує доставити її додаткові, але як порт призначення у traceroute встановлюється таке значення, що ним напевно ніхто не користується, тому хост-одержувач поверне ICMP-повідомлення “порт є неприступний”. Це і є ознакою завершення маршруту і — трасування завершується.

Програма traceroute використовує ненадійний протокол UDP, тому можлива ситуація, коли дейтаграми губляться і traceroute намагається “достукатися” до кожного проміжного хосту чи маршрутизатору неодноразово, тобто надсилає кілька дейтаграм з одним значенням TTL. За умовчанням операція повторюється тричі, але кількість повторювань можна змінити за допомогою опції -g. У traceroute за умовчанням встановлено термін очікування ICMP-повідомлення після кожної спроби 5 с, але його можна змінити за допомогою опції -w. Якщо за цей термін ICMP-повідомлення не отримано, замість значення RTT видається символ (*). Слід зауважити, що деякі маршрутизатори не надсилають ICMP-повідомлень “завершено час у путі”, й тоді виводиться одразу (*). Є такі маршрутизатори, які надсилають повідомлення, але з тим значенням TTL, яке надійшло. Якщо воно дорівнюватиме нулю, то не буде жодного результату.

Можливий випадок, коли маршрутизатори помилково спрямовують дейтаграми далі, хоча TTL дорівнює нулю. У такому разі наступний маршрутизатор, наприклад N+1, відкине дейтаграму і поверне ICMP-повідомлення “завершено час у путі”. На наступній ітерації N+1-й маршрутизатор отримає дейтаграму зі значенням TTL, що вона дорівнює одиниці, й поверне звичайне ICMР-повідомлення. Отже, маршрутизатор N+1 з’явиться на екрані двічі: вперше внаслідок помилки попереднього маршрутизатора, вдруге — після коректного відкидання дейтаграми з часом у путі, що його завершено. На екрані у певних умовах можна спостерігати різку зміну маршруту після першої спроби. Така ситуація виникає в разі спроби маршрутизатору збалансувати навантаження в мережі або в разі відмикання одного маршрутизатору після першої спроби та підмикання іншого.

Маршрутизатори, іноді зумисно, повністю блокують усі ICMP-повідомлення, побоюючись, що вони несуть небезпеку. У такому разі traceroute не можна використовувати. Наступною проблемою є асиметрія маршрутів: немає жодної гарантії, що реальна дейтаграма піде тим самим маршрутом. Статистичні дослідження свідчать про те, що асиметрія маршрутів становить 49% хоча б в одному проміжному вузлі.


2.3 Програма ttcp


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

На рис. 2.5 подано порядок викликання ttcp.


Порядок викликання: ttcp-t [-опції] хост [in]

ttcp-r [-опції >out]

Часто використовувані опції:

-l ## довжина у байтах буферів, до яких зчитуються дані з мережі та записування до мережі (за умовчанням 8192)

-u використовувати UDP, a не TCP

-p ## номер порту, до якого треба надсилати дані або прослуховувати (за умовчанням 5001)

-s -t: відправити дані до мережі

-r: прочитати та відкинути всі дані з мережі

-А вирівнювати початок кожного буферу за цією межею (за умовчанням 16384)

-О вважати, що буфер розпочинається з цього зміщення відносно межі (за умовчанням)

-v друкувати більш детальну статистику

-d встановити опцію сокета SO_DEBUG

-b ## встановити розмір буферу сокета

-f X формат для обчислення швидкості обміну: k, K=кіло; m, M=мега; g, G=гіга

Опції, використовувані разом з - t:

-n ## кількість буферів, передаваних до мережі (за умовчанням 2048)

-D не буферизувати запис за протоколом TCP (встановити опцію сокета TCP_NODELAY)

Опції, використовувані разом з -r:

-B для -s, виводити лише повні блоки відповідно до опції -1

-T “touch”: звертатись до кожного прочитаного байта


Рисунок 2.5 — Порядок викликання ttcp


2.4 Програма tcpdump


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

Користувацька компонента tcpdump взаємодіє з компонентою в ядрі за допомогою бібліотеки libcap (бібліотека для перехоплення пакетів). У системах BSD libcap взаємодіє з пакетним фільтром BPF-BSD packet filter, який аналізує кожний пакет, який проходить повз канальний рівень, і зіставляє його параметри з опціями, заданими користувачем для цього фільтру. Якщо пакет задовольняє критерієві фільтрування, його копія розміщується у виокремленому ядром буфері, який асоціюється з даним фільтром. Коли буфер заповнюється або закінчується заданий користувачем тайм-аут, вміст буфера передається додаткові за допомогою libcap. На рис. 2.6 зазначено, як tсpdump читає неопрацьовані пакети за допомогою BPF, а праворуч, для порівняння, подано ще один додаток, який читає дані із стека TCP/IP, як за звичай. BPF перехоплює пакети на рівні драйверу пристрою, тобто відразу після їхнього зчитування з хосту, на відміну від читання з простого сокету, де можна отримати лише IP-дейтаграми, вже опрацьовані рівнем IP та передані безпосередньо додаткові, оминаючи транспортний рівень (TCP або UDP).

Для використання tсpdump треба отримати дозвіл, за умовчанням tсpdump конфігурується з повноваженнями суперкористувача root. Можна також зробити tсpdump setuid-програмою. Можна викликати tсpdump взагалі без параметрів, тоді вона перехоплюватиме всі мережні пакети та виводитиме інформацію про них. Але краще зазначити певні потрібні атрибути фільтра:

• протокол;
  
• хост відправляння та/або призначення;
  
• мережа відправляння та/або призначення;
  
• Ethernet-адресу відправляння та/або призначення;
  
• порти призначення та/або відправляння;
  
• розмір пакета;
  
• пакети, передавані на всю локальну мережу чи то на групу (у Ethernet та у IP);
  
• пакет, використовуваний як шлюз по зазначеним хостом.
  

Можна також перевірити конкретні біти чи байти у заголовках протоколів. Наприклад, аби добирати лише TCP-сегменти, в яких встановлено біт терміновості, слід використовувати фільтр: tcp [13] & 16, тому що четвертий біт чотирнадцятого байта заголовка TCP — біт терміновості. Фільтр

icmp and not src net localnet

відфільтровує ICMP-пакети, що вони надходять із зовнішньої мережі.





Рисунок 2.6 — Перехоплювання пакетів за допомогою BPF


Інформація, надавана tcpdump, залежить від протоколу. На рис. 2.7 подано трасування сеансу за протоколом SMTP (простий протокол електронної пошти). У першому терміналі (bsd) надсилається електронний лист користувачеві з адресою в домені gte.net, тобто user@gte.net.

Рядки 1...4 описують пошук адреси SMTP-серверу, який обслуговує домен gte.net. У рядку 1 клієнт bsd запитує у серверу імен свого сервіс-провайдера (ns1.ix.netcom.com) ім’я чи імена поштового серверу gte.net. У першому полі знаходиться перший штамп пакета (12:54:32.920881). Оскільки таймер на машині bsd має дозвіл 1мкс, то зазначено шість десяткових знаків. Пакет вийшов з порту 1067 на bsd до порту 53 (domain) на машині nsl. Далі виводиться інформація щодо даних в пакеті. Перше поле (45801) — номер запиту, використовуваний функціями дозволу імен на bsd для зіставляння відповідей та запитів. Знак “+”означає, що функція дозволу задає опитування DNS-сервером інших серверів, якщо в нього не має інформації. Рядок “MX?” показує, що це запит про запис поштового обміну для мережі, ім’я якої стоїть у наступному полі (gte.net) а (25) — це довжина запиту — 25 байтів. Рядок 2 — це відповідь на запит у рядку 1. Число 45801 — номер запиту, до якого належить відповідь. Наступні три поля — кількість записів у відповіді, записів від серверу імен тощо. “371”вказує на кількість байтів у відповіді. “DF” означає, що в IP-заголовку було встановлено біт “Don’t fragment” (не фрагментувати). Перші два рядки ілюструють використання системи DNS для пошуку опрацьовувачів пошти.

1. 12:54:32.920881 bsd.1067 > nsl.ix.netcom.com.domain:
   

45801+ MX? gte.net

2. 12:54:33.254981 nsl.ix.netcom.com.domain > bsd.1067:
   

45801 5/4/9 (371) (DF)

3. 12:54:33.256127 bsd.1068 > nsl.ix.netcom.com.domain:
   

45802+ A? mtapop2.gte.net (33)

4. 12:54:33.534962 nsl.ix.netcom.com.domain > bsd.1068:
   

45802 1/4/4 (202) (DF)

5. 12:54:33.535737 bsd.1059 > mtapop2.gte.net.smtp:
   

S 585494507:585494507 (0) win 16384


timestamp 6112 0> (DF)

6. 12:54:33.784963 mtapop2.gte.net.smtp > bsd.1059
   

S 1257159392:1257159392 (0) ack 585494509 win 49152


timestamp 7853753 6112> (DF)

7. 12:54:33.785012 bsd.1059 > mtapop2.gte.net.smtp:
   

. ack 1 win 17376
timestamp 6112 > 7853753 (DF)

8. 12:54:33.235066 mtapop2.gte.net.smtp > bsd.1059
   

P 1:109(108) ack 1 win 49152

(DF)

9. 12:54:33.235277 bsd.1059 > mtapop2.gte.net.smtp:
   

P 1:19(18) ack 109 win 17376

(DF)

14 строк опущено

24. 12:54:33.675105 bsd.1059 > mtapop2.gte.net.smtp:
    

P 663:663(0) ack 486 win 17376

(DF)

24. 12:54:33.685080 mtapop2.gte.net.smtp > bsd.1059
    

F 486:486(0) ack 663 win 49152

(DF)

24. 12:54:33.685126 bsd.1059 > mtapop2.gte.net.smtp:
    

. ack 487 win 17376

(DF)

24. 12:54:33.934985 mtapop2.gte.net.smtp > bsd.1059
    

F 486:486(0) ack 664 win 49152

(DF)

24. 12:54:33.935020 bsd.1059 > mtapop2.gte.net.smtp:
    

. ack 487 win 17376

(DF)


Рисунок 2.7 — Трасування SMTP-сеансу з вмиканням обміну

за протоколами DNS та TСP


У двох наступних рядках йде пошук IP-адреси опрацьовувача пошти мережі gte.net. “A” у рядку 3 зазначає, що це запит IP-адреси хосту mtapop2.gte.net. — одного з відомих поштових серверів у США. Рядки 5…28 вміщують деталі обміну за протоколом SMTP. Процедура трибічного квітування розпочинається в рядку 5 і завершується в рядку 7. Перше поле після часового штампу та імен хостів — це поле flags. “S” у рядку 5 зазначає, що у сегменті встановлено прапорця SYN. Інші можливі значення прапорця: “F” (FIN),”U” (URG), “P” (PUSH), “R” (RST) та “.” (немає прапорців). Далі йдуть порядкові номери першого та останнього байтів, а за ними в дужках — кількість байтів даних. Перше число — порядковий номер першого байта в сегменті (SYN або інформаційному), а друге — порядковий номер першого байту плюс кількість байтів у сегменті. За умовчанням подані реальні порядкові номери для SYN-сегментів та зміщення — для наступних сегментів.

У всіх сегментах, окрім першого SYN, є поле АСК, яке зазначає, на який наступний порядковий номер очікує відправляч. Це поле (у вигляді ack nnn) за умовчанням вміщує зміщення відносно порядкового номера, зазначеного в сегменті SYN.

За полем АСК йде поле Window — кількість байтів даних, які готовий прийняти віддалений хост. Зазвичай воно відбиває обсяг вільної пам’яті в буферах з’єднання.

У кутових дужках зазначено опції ТСР. У рядках 8...23 подано діалог поміж програмою senmail на клієнтському боці bsd та SMTP-сервером на машині mtapop2. Рядки 24...28 відбивають процедуру розривання з’єднання. Спочатку bsd надсилає FIN у рядку 24, потім надходить FIN від mtapop2 (рядок 25). У рядку 27 mtapop2 вдруге надсилає FIN, тому що не отримав від bsd підтвердження АСК на свій перший FIN.

Один з недоліків tсpdump — неповна підтримка виведення даних. Часто під час налаштовування мережних додатків треба знати, які дані надсилаються. Цю інформацію можна отримати, задавши опції -s та -x. Опція -s зазначає, скільки даних з пакета треба виводити, а –x — вказує на шістнадцяткову форму виведення даних. За умовчанням tcpdump виводить лише перші 68 байтів, що є достатнім для заголовків більшості протоколів.

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