УЛИКА #03
В мониторинге видим:
Packet loss: 1%
Первая реакция может быть такой:
всего один процент — почти ничего.
Но процент потерь сам по себе ещё не говорит, насколько проблема серьёзна.
1% packet loss
≠
1% ухудшения сервиса
Что означает потеря пакетов
Упрощённо:
отправили 1000 пакетов
↓
990 дошли
10 потерялись
↓
packet loss = 1%
Причины могут быть разными:
- перегруженный канал;
- ошибки интерфейса;
- проблемы физического соединения;
- Wi-Fi;
- VPN;
- перегрузка сетевого оборудования;
- некорректный MTU;
- фильтрация или ограничение трафика.
Но главное — что происходит с приложением после потери пакета.
Для TCP потеря может означать повторную передачу
TCP должен доставить данные надёжно. Если пакет потерян:
пакет отправлен
↓
потеря
↓
обнаружение потери
↓
повторная передача
↓
дополнительная задержка
Поэтому даже небольшая постоянная потеря может проявляться как:
- снижение скорости передачи;
- увеличение времени ответа;
- рывки при работе через удалённый канал;
- медленные SSH/RDP-сессии;
- нестабильная работа приложений.
То есть пользователь может ощущать проблему значительно сильнее, чем выглядит цифра 1%.
Для другого трафика последствия могут быть другими
Например, для голосового или видеотрафика потерянный пакет часто уже невозможно просто «дождаться позже». Результатом могут стать:
звук → прерывается видео → артефакты интерактивный трафик → задержки и рывки
Поэтому одинаковый 1% для резервного копирования и для голосового звонка — не одинаковая проблема.
Важно и то, как распределены потери
Есть большая разница между:
1 потерянный пакет из 100
раз в несколько часов и:
постоянные потери около 1%
на рабочем канале. Ещё хуже, если потери идут группами:
OK OK OK OK LOSS LOSS LOSS LOSS OK OK OK
Кратковременный burst потерь может заметно нарушить работу интерактивного приложения, даже если среднее значение за час выглядит небольшим.
А ping всё покажет?
Не обязательно.
Например:
ping server.example.ru
проверяет ICMP-трафик. Но рабочее приложение может использовать:
TCP/443 UDP VPN другой маршрут
Кроме того, сетевое оборудование иногда обрабатывает или ограничивает ICMP иначе, чем прикладной трафик. Поэтому:
ping loss
≠
автоматически application loss
и наоборот.
ping — хорошая улика.
Но не всегда окончательное доказательство.
Что проверять дальше
Если потеря повторяется, полезно определить:
где начинается loss?
Проверяем путь последовательно:
клиент ↓ локальная сеть ↓ шлюз ↓ VPN / WAN ↓ удалённая сеть ↓ сервер
И дополнительно смотрим:
- ошибки и drops на интерфейсах;
- загрузку канала;
- состояние физических портов;
- MTU;
- наличие потерь только в одном направлении;
- время возникновения проблемы;
- корреляцию с нагрузкой.
Главное
Packet loss = 1%
≠
«можно игнорировать»
Но и:
Packet loss = 1%
≠
готовый диагноз
Это сигнал, который нужно оценивать вместе с:
длительностью + характером потерь + типом трафика + точкой возникновения + влиянием на сервис
Правильный вопрос не:
«1% — это много или мало?»
А:
«Где теряются пакеты и что эти потери делают с нашим сервисом?»
#УликиИнфры #Network #Troubleshooting #ПоФактам