Як читати втрати пакетів, перш ніж звинувачувати кабель

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

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

Що насправді вимірює відсоток ping

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

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

Порівнюйте різниці лічильників, а не пожиттєві суми

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

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

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

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

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

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

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

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

Змініть одну межу, не рухаючи інші

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

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