Иногда приложение вроде бы работает, 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 203.0.113.10 and port 443
Если нужно сохранить дамп для Wireshark:
tcpdump -i any -nn host 203.0.113.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 203.0.113.10
Но тут важно помнить: mtr показывает потери по ICMP/UDP/TCP-проверкам, а не всегда идеально отражает конкретный TCP-трафик приложения. Зато помогает понять, где примерно начинаются проблемы.
Еще полезно проверить ошибки на сетевом интерфейсе:
ip -s link
или:
ethtool -S eth0
#linux #network
🧑💻 NetworkAdmin