Кратко и по шагам — что делать, какие метрики смотреть и какими инструментами, с пояснениями интерпретации.
1) Быстрая изоляция (проверить, на каком уровне проблема)
- Повторяем проблему на конкретном хосте: ping/iperf3 между проблемным клиентом и сервером/шлюзом:
- ping: `ping -c 100 ` — смотрим средний/медианный RTT и потери.
- iperf3: `iperf3 -c -t 60 -P 1` — пропускная способность и поведение при нагрузке.
- Если беспроводная сеть — проверяем RSSI/рейты: `iwconfig`/`iw` и статистику retries.
Метрика: потеря пакетов (пакетов потеряно / отправлено → %), RTT распределение, throughput. Например: если потери $>1\%$ — уже критично.
2) Анализ tcpdump / Wireshark (у вас уже есть дамп)
- Открыть в Wireshark / tshark и смотреть TCP-аналитику (TCP analysis flags): Retransmission, Fast Retransmission, Out-of-Order, Dup ACK, ZeroWindow.
- Важные признаки:
- повторные передачи с DupACK → потеря пакета в пути к получателю;
- повторная передача без DupACK (таймаут) → потеря/очень большая задержка или потеря ACK;
- множ. Retransmissions + уменьшение cwnd/zero window → либо потеря/конгестия на пути, либо приёмник не успевает.
- Команды: `tshark -r dump.pcap -q -z io,stat,0,COUNT,TCP` и фильтры `tcp.analysis.retransmission`, `tcp.analysis.duplicate_ack`.
- Считаем долю повторных передач: $\text{retrans\_rate}=\frac{\text{retransmissions}}{\text{total TCP segments}}$.
3) Проверка интерфейсов и ошибок физического уровня
- На хостах: `ethtool -S eth0`, `ip -s link show dev eth0`, `dmesg | grep -i eth`, `ifconfig` — смотрим rx_errors, tx_errors, rx_dropped, tx_dropped, fifo, frame, carrier.
- На коммутаторах: show interface counters (у Cisco/Juniper) — CRC, FCS, collisions, input/output errors, flaps.
- Ищем: CRC/FCS/align errors, carrier loss, link flaps, duplex mismatch (speed/duplex). Если есть CRC или большой rx_errors — заменить кабель/SFP/порт.
- Проверка дуплекса: `ethtool eth0` — убедиться в совпадении настроек на обеих сторонах.
4) Проверка загрузки канала и потоков (конгестия)
- Замерить текущую загрузку интерфейса: `sar -n DEV 1 10`, `ifstat`, `nload`, `iperf3`.
- Узнать топовые разговоры: `iftop`, `nethogs`, sFlow/NetFlow, `ntop`.
- При высокой загрузке смотреть: link utilisation $>$ порог (например $>80\%$) — вероятность потерь при перегрузке.
- Если есть множество больших TCP потоков – может требоваться QoS или увеличение пропускной способности.
5) Буферная задержка (bufferbloat)
- Тест: одновременно запускать iperf3 (нагрузка) и ping — смотреть рост RTT под нагрузкой.
- Инструменты: Flent, `bwping`, `router-bloat` тесты. Метрика — увеличение RTT под нагрузкой (latency inflation).
- Проверка qdisc на Linux роутерах: `tc -s qdisc show dev ethX` — смотреть drops, backlog.
- Решение: применить fq_codel/fq или настроить qdisc и размеры буферов.
6) Проверка маршрутизации и L3 проблем
- traceroute/mtr между клиентом и сервером внутри LAN (или до шлюза) — смещение маршрута, hops с большими RTT.
- Проверить ARP: дублирование MAC, ARP storms (`arp -n`, `ip -s neigh`).
- Проверить ECMP или асимметрию маршрутов — возможны перепады/потери при балансировке.
7) L2 (коммутатор) — STP, CAM, broadcast storms
- Логи коммутатора: flaps, STP topology changes.
- Счетчики широковещательных/мультикастовых пакетов — если высокий broadcast → затор в коммутаторе.
- Проверить CAM table/таблицу MAC: переполнение → flooding.
8) Диагностика TCP-параметров и поведения соединения
- Просмотр TCP-статистики на хосте: `ss -s`, `netstat -s | grep -i tcp`.
- Смотреть cwnd/rcv_wnd/tcp_info (curl подключение с `--trace` или использовать `ss -ti`).
- Вычислить BDP для ориентировки по размеру окна: $\mathrm{BDP}=\text{bandwidth}\times \text{RTT}$. Например при $\text{bandwidth}=1\text{Gbps}$ и $\text{RTT}=1\text{ms}$ BDP $\approx 125\text{kB}$.
- Если окна регулярно уменьшаются — смотреть ZeroWindow/Window Update в дампе; если уменьшение из-за потерь — лечится уменьшением потерь/переходом на SACK/куча.
9) Сбор метрик и мониторинг (чтобы подтвердить гипотезы)
- Что собирать: интерфейсные ошибки и utilisation, TCP retransmissions, RTT percentiles (p50/p95/p99), packet loss %, queue drops, buffer backlog, switch port errors, link flaps, SNR (для Wi‑Fi).
- Инструменты: Prometheus + node_exporter, SNMP (switch counters), sFlow/NetFlow, Grafana, ELK для логов.
10) Типичные соответствия признаков → возможные причины и действия
- Много CRC/align/errors → физическая проблема (кабель/SFP/порт) — заменить/переместить порт.
- Повторы с DupACK → потеря пакета в пути (конгестия/ошибка) — найти перегруженные сегменты/коммутатор/дропы на qdisc.
- Retransmission без DupACK → возможны большие задержки/флопы маршрутизации или потеря ACK → смотреть маршрутизацию.
- RTT растёт под нагрузкой, qdisc backlog растёт → bufferbloat → применить fq_codel/параметры qdisc.
- Уменьшение receive window / zero window → проблема на принимающей стороне (приложение/CPU/память).
11) Практический план действий (порядок)
- Сначала: собрать интерфейсные ошибки на хостах и коммутаторах (ethtool, switch counters).
- Затем: локализовать (host-to-host тесты: ping/iperf3/mtr).
- Анализ pcap: определить тип повторных передач (DupACK vs RTO), посмотреть direction.
- Проанализировать загрузку и топовые потоки (iftop, sFlow).
- Проверить qdisc/буферы на маршрутизаторах и применить fq_codel если bufferbloat.
- Если физические ошибки — заменить кабель/порт/SFP.
- Если маршрутизация/коммутатор — смотреть логи/поменять конфигурацию/исправить STP/удалить профильные бродкасты.
Если нужно, могу прислать конкретные команды по вашей платформе (Linux/Windows/тип коммутатора) и примеры того, как по дампу отличить DupACK-RTT‑triggered retransmission от RTO‑retransmission.