Коротко и по делу: инструменты и методика диагностики, что смотреть в результатах и какие типичные причины.
Инструменты
- Пакетный захват: tcpdump / tshark / Wireshark (запись на целевых хостах/SPAN).
- Активные тесты: iperf3, nuttcp, netperf — для воспроизведения и измерения пропускной способности.
- RTT / path tracing: ping, mtr (или Paris-traceroute), hping3.
- Потоковая телеметрия: NetFlow/sFlow/IPFIX — для идентификации «тяжёлых» потоков и асимметрии трафика.
- SNMP/агрегация графиков: MRTG, Cacti, LibreNMS, Prometheus+Grafana — для истории интерфейсных/CPU/пакетных счётчиков.
- Интерфейсные/железные утилиты: ethtool, ethtool -S, ifconfig/ip -s, dmesg, show interfaces (коммутаторы/роутеры) — ошибки/CRC/drops/link speed/duplex.
- TCP/OS инструменты: ss/tcpdump для retransmits, tcp_probe, tcptrace, Wireshark TCP Expert.
- QoS/queue анализ: tc (Linux), show queue (на сетевом оборудовании).
- При необходимости: портовый зеркалинг -> анализатор/packet broker, BPF/ebpf мониторинг (bcc, bpftrace).
Методика (шаги)
1. Сбор базовой телеметрии: построить графики интерфейсов, CPU, memory, error counters за период деградации (MRTG/Prometheus).
2. Воспроизвести проблему синтетикой: запустить iperf3 клиент/сервер в момент падения, замерить throughput, jitter, packet loss (пример: iperf3 -c host -t $60$ -P $4$).
3. Одновременный пакетный захват на краю сети и на сервере/клиенте: tcpdump -i eth0 -w capture.pcap. Идентифицировать retransmits, dupACKs, out-of-order, MSS, ECN.
4. Измерить RTT распределение и correlate с падениями пропускной способности (mtr длительно).
5. Посмотреть интерфейсные счётчики на всех промежуточных устройствах: CRC, errors, drops, overruns, collisions, queue drops.
6. Проверить настройки link: скорость/duplex, авто-negotiation, Ethernet flow control (PAUSE).
7. Проверить правила QoS, shaping, policers и ACL/Firewall (rate-limits, per-flow limits).
8. NetFlow/sFlow — найти «тяжёлые» потоки и время совпадения с деградацией.
9. Если подозрение на bufferbloat — тест с ping во время iperf: если RTT резко растёт при загрузке канала, это буферизация/очереди.
10. Контроль на уровне ОС/приложения: window size, TCP window scaling, busy CPU, I/O (диск), контейнеры/виртуализация.
Что искать в захвате/метриках (интерпретация)
- Высокая доля retransmits/dup ACKs → потеря пакетов в сети.
- Увеличение RTT одновременно с ростом throughput и без потерь → длинные очереди (bufferbloat).
- Постоянные кратковременные падения throughput с большим количеством пакетов в короткие интервалы → микропики/микробёрсты (switch buffer overflow).
- Ассиметричный маршрут (NetFlow + traceroute) → возможные ответы идут по другому пути с лимитом.
- Низкая оконная рекомендация (recv window) или выключенный window scaling → TCP не набирает скорость.
- Интерфейсные ошибки (CRC, frame) → физические проблемы: кабель, SFP, перегрев.
- Политики QoS/policer → видно как drop при превышении профиля.
- Перегрузка CPU или прерываний на хосте/шлюзе → производительность сетевого стека падает.
Ключевые метрики и пороги (что измерять)
- Packet loss rate $p$ — даже $p\ge 0.5\%$ заметно снижает TCP throughput.
- RTT median / p95 / p99 — рост p99 указывает на всплески задержки.
- Retransmits (\%): отслеживать > $1\%$ как тревожный.
- Interface drops/errors: любое ненулевое число CRC/frame → ремонт/замена железа.
- Throughput (полезная нагрузка) vs линк-скорость (например $1\text{Gbps}$).
Формула для понимания влияния потерь/RTT на TCP throughput (приблизительно, модель Mathis):
$$T\approx \frac{MSS}{RTT}\sqrt{\frac{3}{2p}}$$ где $T$ — скорость, $MSS$ — максимальный размер сегмента, $RTT$ — время в круге, $p$ — вероятность потери пакета. Отсюда видно, что рост $RTT$ или $p$ сильно снижает $T$.
Типичные причины периодических падений скорости
- Конгестия на линке/в очередях (недостаточная ёмкость, пик нагрузки, отсутствует правильный AQM).
- Политики QoS/policers или rate-limit на маршрутизаторах/файрволах.
- Пакетная потеря из-за ошибок физического уровня: бракованные кабели, SFP, шум, неверный duplex/скорость.
- Микробёрсты: короткие пики, которые переполняют буферы.
- Ассиметрия маршрутов и stateful firewall (ответы идут через узкое место).
- Неправильные настройки TCP (window scaling off), старые стеки, анти-DDoS/сниффинг.
- Перегрузка CPU/прерываний на сетевых устройствах или VMs (черезмерные контексты прерываний, interrupt coalescing).
- VLAN/MTU/fragmentation/PMTU проблемы — фрагментация и drops.
- Flow-control (Ethernet pause) в комбинации с плохими NIC/коммутаторами.
- Аппаратные баги/прошивки/драйверы.
Короткие рекомендации при обнаружении проблемы
- При потерях: локализовать сегмент (по hop), проверить физику, уменьшить MTU/исключить фрагментацию, обновить прошивку.
- При bufferbloat: включить AQM (fq_codel), уменьшить буферизацию на очередях.
- При QoS/policer: проверить и скорректировать правила/шейпинг.
- При микробёрстах: увеличить буфер на коммутаторах или настроить burst в shaping.
- При CPU-проблемах: offload (SR-IOV), уменьшить обработку в kernel-space, оптимизировать firewall rules.
Если нужно — могу предложить конкретный чеклист команд и фильтров tcpdump/Wireshark и примеры интерпретации с capture.