Иногда приложение вроде бы работает, CPU нормальный, память есть, база живая, но пользователи жалуются: «все медленно». И начинается классика: смотрим логи приложения, nginx, базу, systemd, load average. А причина может быть ниже — на сетевом уровне. Один из важных признаков сетевых проблем — TCP retransmits.
TCP — надежный протокол. Если пакет потерялся по дороге, получатель его не подтвердил, и отправитель через время отправит этот сегмент заново. Это и есть retransmission. Небольшое количество повторных передач в сети бывает всегда. Но если их много — это уже симптом:
• перегруженный канал;
• проблемы на интерфейсе;
• плохой Wi-Fi или VPN;
• перегруженный firewall/NAT;
• проблемы у провайдера.
Снаружи это часто выглядит не как «сеть упала», а как странная деградация: страницы открываются медленно, API иногда отвечает долго, SSH подвисает, загрузка файлов идет рывками и т.д.
Первое, что можно посмотреть на linux:
netstat -s | grep -i retrans
или через ss:
ss -ti
В выводе ss -ti можно увидеть детали по TCP-соединениям, включая retrans, rtt, cwnd и другие параметры.
Для конкретного направления лучше использовать tcpdump. Например, смотрим трафик между сервером и клиентом:
tcpdump -i any -nn host 185.110.11.10 and port 443
Если нужно сохранить дамп для Wireshark:
tcpdump -i any -nn host 185.110.11.10 and port 443 -w retrans.pcap
В wireshark потом удобно фильтровать:
tcp.analysis.retransmission
Также полезные фильтры:
tcp.analysis.fast_retransmission tcp.analysis.lost_segment tcp.analysis.duplicate_ack
Если видите много retransmission, duplicate ACK и lost segment — это уже повод смотреть сеть, а не только приложение.
Быстрая проверка маршрута:
mtr -rw -c 100 185.110.11.10
Но тут важно помнить: mtr показывает потери по ICMP/UDP/TCP-проверкам, а не всегда идеально отражает конкретный TCP-трафик приложения. Зато помогает понять, где примерно начинаются проблемы.
Еще полезно проверить ошибки на сетевом интерфейсе:
ip -s link
или:
ethtool -S eth0