Как читать потери пакетов, прежде чем винить кабель

Два процента потерь на длинной серии ping кажутся числом, с которым можно что-то делать, и так бывает редко. Оно не говорит, где пропали ответы, пропали ли они вместе и как конкретное приложение пережило этот интервал. Потери, равномерно размазанные по минуте, и потери, собранные внутри одного обмена, дают при одном и том же проценте очень разные результаты.

Сравните три измерения вместо того, чтобы доверять одному: что увидел зонд, что сделали счётчики интерфейса и чего на самом деле ждало приложение.

Что на самом деле измеряет процент ping

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

Сохраните результат зонда как подсказку о пути. Затем ищите время и границу, которые его создали.

Сравнивайте разницы счётчиков, а не пожизненные суммы

Снимите показания с отметками времени до и после окна, в котором появился симптом, на обоих концах и на любом порту коммутатора, которым вы управляете. Записывайте объём трафика вместе с ошибками, сбросами и изменениями состояния канала, потому что ненулевая сумма, накопленная за месяцы, описывает историю, а не этот случай. Счётчик, сдвинувшийся на три во время остановки, — это другое наблюдение, чем счётчик, показывающий три тысячи и никогда не менявшийся.

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

Пакеты, отброшенные из-за ошибок приёма, и пакеты, отброшенные по другим причинам, живут в отдельных счётчиках, и это различие меняет следующий шаг. Счётчики ошибок указывают на физический уровень или уровень драйвера, а давление очередей и сбросы по политике указывают куда-то выше. Сохраняйте также направление и имя интерфейса, потому что рост ошибок приёма на восходящем канале и счётчик пакетов туннеля не взаимозаменяемы.

Если драйвер предоставляет подробные физические счётчики, читайте их по документации этого адаптера. Приписать одно значение каждому полю с именем «drop» у двух производителей — это путь, которым обычная учётная особенность превращается в аппаратный диагноз.

Как потерянный сегмент превращается в долгое ожидание

Приложение может ждать гораздо дольше одного оборота после потери сегмента. TCP оценивает время оборота, вычисляет из этой оценки таймер повтора передачи и отступает, когда повтор тоже не удаётся, так что один потерянный сегмент в неподходящий момент может остановить запрос на заметный интервал. Этот механизм описан в RFC 6298, и он объясняет, почему скорость потерь, которая выглядит ничтожной, всё же может ощущаться.

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

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

Меняйте одну границу, не трогая остальные

Если доказательства указывают на локальный канал, замените одобренный кабель или порт как контролируемое сравнение и оставьте всё остальное в покое. Держите конечную точку, приложение и нагрузку сопоставимыми и меняйте ровно одну границу за попытку. Сравнение проводного ноутбука с беспроводным при одновременной смене выходов и протоколов не говорит ничего, что можно было бы отнести к причине.

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