Как быстро понять, что проблема именно в сети
Медленное приложение не всегда означает медленную сеть. Одна медленная операция не может быть объяснена сетью без измерений. Начните с проверки симптомов: долгий TCP connect, медленный DNS, задержки при передаче данных, таймауты, плавающий отклик и снижение throughput. Если одновременно растут задержки, потери, повторные передачи или ошибки интерфейса, а локальные ресурсы хоста остаются в норме, сеть становится вероятной причиной.
Порядок проверки: зафиксируйте время и сценарий, проверьте доступность и RTT, посмотрите потери и retransmissions, оцените загрузку интерфейса, проверьте ошибки, MTU и состояние соседних узлов. Потеря ICMP-ответов не всегда означает потерю пользовательского трафика, так как ICMP может фильтроваться или обрабатываться с низким приоритетом.
Какие метрики определяют сетевую производительность
Эффективность сети не сводится к скорости канала. Для диагностики собирайте несколько показателей вместе: пропускную способность, фактический throughput, задержку, джиттер, потери пакетов, повторные передачи и ошибки интерфейса. Одна метрика без контекста может привести к неправильному выводу.
Пропускная способность и фактический throughput
Bandwidth, goodput и throughput различаются. Заявленная скорость канала не равна полезной скорости приложения. На фактический throughput влияют TCP-окно, RTT, потери, шифрование, ограничения диска и виртуализация. Для измерений используйте iperf3 и проверяйте направление передачи, несколько потоков и загрузку конечных хостов.
Задержка, джиттер и потери пакетов
Низкая скорость не всегда главная проблема. Нестабильный отклик влияет на приложения сильнее. Средний, минимальный и максимальный RTT, вариативность задержки и процент потерь связаны с TCP retransmissions, таймаутами, интерактивными сессиями, API и репликацией.
Ошибки интерфейса и счетчики операционной системы
Для подтверждения сетевой гипотезы на хосте и коммутаторе используйте ip -s link, ethtool -S, nstat, ss -s, данные SNMP и метрики мониторинга. Счетчики смотрите в динамике и сопоставляйте с моментом деградации, а не оценивайте только по абсолютному значению.
Диагностика потерь пакетов: от симптома к проблемному участку
Потери пакетов могут возникать на разных участках. Не локализуйте проблему по одному ping. Проверяйте конечные точки, промежуточные узлы и транспортный протокол.
Как подтвердить реальные потери, а не ICMP-фильтрацию
Сравните результаты ping до маршрутизатора, сервера и прикладного порта. Используйте mtr с длительным тестом и анализируйте потери на конечной точке. Проверяйте TCP или UDP-трафик, когда ICMP-поведение не отражает состояние сервиса.
Потери на хосте, порту коммутатора или маршруте
Проверьте rx_dropped, tx_dropped, overruns, CRC, ошибки на физическом порту и соответствующие counters на коммутаторе. Сопоставьте результаты между клиентом, сервером, виртуальным свитчем, балансировщиком и шлюзом.
Повторные передачи TCP как прикладной индикатор
Retransmissions, duplicate ACK, out-of-order packets и снижение congestion window подтверждают влияние потерь на реальное соединение, даже если базовый ping выглядит приемлемо. Рост повторных передач может быть связан не только с потерями, но и с переупорядочиванием или перегрузкой.
Постройте диагностику от простого к сложному: повторяемый ping между клиентом и сервисом, сравнение нескольких точек маршрута, mtr или traceroute, анализ TCP retransmissions и захват трафика через tcpdump. Отличите потерю на конечном хосте от потери на маршруте: промежуточный узел может ограничивать ICMP, но корректно пересылать транзитный трафик. Подробнее о диагностике маршрутизации читайте в руководстве по поиску потери пакетов и сетевых петель.
Диагностика сетевых задержек и джиттера
Сервис доступен, но отвечает медленно или нестабильно. Перейдите от простого факта высокого RTT к поиску очереди, перегруженного звена, проблемного маршрута или задержки внутри приложения.
Постоянная и переменная задержка
Постоянный высокий RTT связан с географическим расстоянием, маршрутизацией или дополнительным сетевым узлом. Переменный RTT связан с очередями, перегрузкой канала, радио-сегментом, виртуализацией и bufferbloat.
Где именно возникает задержка
Сопоставьте время DNS, TCP connect, TLS handshake, time to first byte и время полной загрузки. Одновременно посмотрите CPU, load average, disk latency, очередь запросов и сетевые retransmissions. Сравните запросы к локальному адресу, соседнему узлу и удаленному сервису.
Джиттер как причина нестабильного поведения
Одинаковый средний RTT не гарантирует одинаковое качество работы. Разброс задержек, кратковременные пики влияют на таймауты, репликацию, распределенные блокировки и интерактивные подключения. Храните percentile-метрики, например p95 и p99, а не только среднее значение.
Сравните latency между разными парами узлов и в разные периоды нагрузки. Используйте ping, mtr, traceroute, tcpdump и метрики приложения. Разделите задержку установления соединения, передачи данных, ожидания ответа сервера и обработки запроса. Среднее значение скрывает пики, а jitter особенно критичен для VoIP, видеосвязи, кластерных протоколов и интерактивных систем.
Перегрузка канала: признаки и проверка bufferbloat
Канал может оставаться формально доступным при неприемлемых задержках. Отличите нехватку пропускной способности от неисправности оборудования.
Признаки перегруженного канала
Сопоставьте загрузку канала, скорость передачи, длину очередей, drops, latency и поведение нескольких сервисов. Один поток может не заполнять канал, а суммарный трафик всех потребителей уже создавать очередь.
Что такое bufferbloat и как его подтвердить
Bufferbloat вызывает резкий рост задержки при заполнении буферов без обязательной потери пакетов. Проведите тест: измерьте базовый RTT, затем запустите контролируемую передачу и повторите измерение. Большие буферы, очереди на маршрутизаторе и ограничения uplink влияют на задержку. Проверьте qdisc и политику управления очередями.
Как снизить задержку под нагрузкой
После подтверждения перегрузки примените shaping, QoS, AQM, приоритизацию критичного трафика, ограничение фоновых задач и перераспределение потоков. Увеличение канала не устраняет проблему, если узкое место находится на другом интерфейсе или в очереди конечного устройства. Подробнее о настройке QoS и TCP/IP читайте в практическом руководстве по оптимизации сетевой производительности.
Как проверить MTU в сети и найти проблемы с фрагментацией
Небольшие запросы проходят, а крупные пакеты, VPN, репликация или отдельные TCP-сессии работают нестабильно. Проверьте MTU.
Симптомы неправильного MTU
Зависание HTTPS, частично загружающиеся страницы, проблемы с репликацией, нестабильные VPN-сессии и успешный ping малыми пакетами при отказе крупных. Проявление может зависеть от направления трафика.
Проверка MTU на Linux и в туннелях
Используйте ip link, ping с заданным размером и DF, tracepath, проверку интерфейсов и параметров туннеля. Тестируйте весь путь между приложением и сервисом, а не только локальный интерфейс.
Как исправлять несогласованный MTU
Выровняйте MTU на хостах, виртуальных свитчах, физических портах и туннелях. Временное снижение MTU может быть диагностическим шагом. После изменения повторите тест.
MTU, DF-флаг и Path MTU Discovery важны для корректной передачи. Проверяйте пакетами разного размера между конечными узлами с учетом заголовков IPv4 или IPv6. Типичные причины: туннели, VPN, VXLAN, GRE, PPPoE, несогласованные jumbo frames и фильтрация ICMP fragmentation needed. Для практического скрипта подбора MTU обратитесь к руководству по диагностике сетевой маршрутизации.
Ошибки интерфейса сети: диагностика физических и канальных проблем
Проблемы не всегда видны через ping или мониторинг приложения: поврежденный кабель, неисправный SFP, mismatch duplex, flapping линка и переполнение очереди.
Какие счетчики считать критичными
Разделите физические ошибки, ошибки приема и передачи, drops из-за очередей и административные изменения линка. Значения, требующие немедленной проверки кабеля, порта или SFP, отличаются от ожидаемых в конкретной архитектуре.
Flapping SFP-аплинка и просадка оптической мощности
Нестабильный аплинк вызывает кратковременные потери и скачки задержки. Link down/up, carrier changes, CRC и просадки DDM связаны с обрывами соединения. Проверьте оба конца линии, патч-корды, трансиверы, загрязнение коннекторов и совместимость модулей.
Несогласованные speed и duplex
Проверьте negotiated parameters на сервере и коммутаторе. Mismatch приводит к коллизиям, retransmissions, низкой скорости и нестабильному отклику. Изменения выполняйте с учетом удаленного доступа и возможности потерять соединение.
Разберите счетчики интерфейса на хосте и коммутаторе. Проверьте состояние линка, negotiated speed, duplex, CRC, alignment errors, frame errors, drops, overruns и carrier changes. Для оптических соединений используйте DDM-показатели: температура, напряжение и оптическая мощность. Счетчики анализируйте в динамике, фиксируя прирост за интервал.
Как связать сетевые метрики с поведением приложения
Сеть может выглядеть исправной на базовом уровне, но приложение все равно медленно работает. Переведите технические показатели в диагноз, понятный владельцу сервиса и команде эксплуатации.
Симптомы приложения и вероятные сетевые причины
Таймауты связаны с потерями и retransmissions, медленное установление соединения с RTT или DNS, скачки времени ответа с jitter и очередями, частичная загрузка данных с MTU или фрагментацией. Учитывайте альтернативные причины, чтобы не делать вывод только по одному признаку.
Один клиент или весь сервис
Сравните несколько клиентов, подсетей, availability zones и интерфейсов. Проверьте, повторяется ли симптом при обращении к сервису напрямую, через балансировщик и через внешний URL. Рассмотрите влияние DNS, NAT, firewall и service mesh.
Сеть в Docker и Kubernetes
Проверьте сетевой путь внутри pod, между узлами и за пределами кластера. Учитывайте CNI, overlay encapsulation, MTU, kube-proxy, NetworkPolicy, conntrack и нагрузку на node. Сравните запрос из pod, с worker-ноды и с внешнего хоста.
Покажите корреляцию по времени между latency, packet loss, retransmissions, bandwidth, CPU, disk latency, DNS и временем ответа приложения. Различите проблемы одного клиента, одной зоны, одного сервера, одного маршрута и всех пользователей. Трассируйте запрос через reverse proxy, балансировщик, контейнерную сеть и backend.
Пошаговый сценарий диагностики для рабочего инцидента
Готовая последовательность действий для быстрого применения.
Минимальный набор команд на Linux
Используйте ping, tracepath, traceroute, mtr, ip -s link, ethtool, ss, nstat, iperf3 и tcpdump. Для каждой команды определите задачу и интерпретацию результата.
Что собрать до изменения конфигурации
Зафиксируйте counters, route, MTU, speed/duplex, загрузку интерфейсов, pcap при необходимости, логи приложения и временные метки. Согласуйте активные тесты iperf3 и захват трафика в production.
Как оформить результат проверки
Укажите источник и назначение, время, протокол, размер пакета, RTT, процент потерь, retransmissions, utilization, прирост ошибок интерфейса и выполненные действия. Отдельно зафиксируйте, какая гипотеза подтверждена, а какая исключена.
Соберите практический runbook: зафиксируйте симптом и временной интервал, определите пару клиент-сервис, проверьте DNS и TCP connect, измерьте RTT и потери, проверьте маршрут, интерфейсные счетчики, MTU, загрузку канала и состояние хоста, затем повторите тест после изменения или переключения маршрута. Для каждой команды укажите, какой результат подтверждает или опровергает гипотезу.
Типовые сценарии и ошибки при поиске сетевого узкого места
Практические кейсы и предупреждения о действиях, которые приводят к неверному диагнозу.
Почему нельзя делать вывод по одному ping
ICMP имеет ограничения: малый размер пакета, отсутствие проверки прикладного порта и различия между контрольным и пользовательским трафиком. Для надежного вывода нужны дополнительные измерения.
Почему увеличение канала не всегда помогает
Узкие места могут быть на интерфейсе сервера, uplink, VPN, балансировщике, диске, CPU, очереди или удаленном сервисе. Сначала определите участок с ограничением.
Когда проблема не в сети
Признаки проблем DNS, TLS, приложения, базы данных, файловой системы, CPU, памяти и диска. Отсутствие потерь, стабильный RTT и нормальные counters помогают перенести фокус на хост или сервис.
Разберите несколько сценариев: рост RTT только во время резервного копирования, потери на одном SFP-аплинке, зависание HTTPS из-за MTU, высокая скорость iperf3 при медленном приложении из-за диска или CPU, retransmissions при корректном ping и проблемы только в Kubernetes overlay-сети.
Чек-лист диагностики сетевой производительности
Компактная шпаргалка для инцидента:
- Кто и куда подключается?
- Когда началась деградация?
- Затронуты ли другие клиенты?
- Каковы RTT и jitter?
- Есть ли реальные потери и retransmissions?
- Не перегружен ли канал?
- Растут ли ошибки интерфейса?
- Совпадает ли MTU на всем пути?
- Что показывают CPU, память и диск?
- Повторяется ли проблема на прикладном уровне?
Критерии достаточного доказательства сетевой причины: одновременный рост задержек, потерь, повторных передач или ошибок интерфейса при нормальных локальных ресурсах. Условия для эскалации на сетевую команду: подтвержденные потери на маршруте, ошибки интерфейса или нестабильность линка.
Часто задаваемые вопросы о задержках и потерях пакетов
Всегда ли потеря ping означает потерю трафика приложения?
Нет. ICMP может фильтроваться или обрабатываться с низким приоритетом. Проверяйте конечную точку, прикладной порт, TCP retransmissions и счетчики интерфейсов.
Какой процент потерь пакетов считается проблемой?
Допустимый уровень зависит от протокола, приложения, длительности теста и места возникновения. Для критичного TCP-сервиса даже небольшие повторяющиеся потери могут заметно снизить throughput и увеличить задержку.
Как проверить MTU в сети через VPN или туннель?
Проверяйте размер пакета с DF, учитывайте накладные заголовки туннеля и тестируйте путь от реального клиента до сервиса. После изменения повторите проверки крупных пакетов и прикладной операции.
Что делать, если ping нормальный, а приложение медленное?
Проверьте DNS, TCP connect, TLS handshake, retransmissions, размер и направление передачи, загрузку канала, время обработки на сервере, диск и базу данных. Сравните прямой запрос к backend с запросом через балансировщик или proxy.
Для углубленной диагностики сетевых проблем используйте полный чек-лист диагностики проблем маршрутизации и статью о влиянии сети на производительность автоматических систем.