Клиенты жалуются на периодические таймауты при обращении к сервису. Какие команды (ss, netstat, tcpdump) помогут диагностировать проблему на сетевом уровне и что именно они покажут?

Короткий ответ

ss -tan покажет список TCP-соединений и их состояния (сколько в ESTABLISHED, SYN-SENT, TIME-WAIT и т.д.), ss -tlnp — какие процессы слушают какие порты, netstat используется аналогично как более старая альтернатива ss, а tcpdump позволяет захватить реальный сетевой трафик для детального анализа конкретного взаимодействия вплоть до отдельных пакетов и флагов TCP.

Как это работает подробнее

ss и netstat читают информацию о сокетах из ядра (через netlink или procfs) и дают статическую картину на момент выполнения команды — полезно для оценки общего состояния (переполнена ли очередь accept, сколько соединений зависло); tcpdump захватывает пакеты на сетевом интерфейсе в реальном времени, позволяя увидеть ретрансмиссии TCP, незавершённые рукопожатия, RST-пакеты или аномальные задержки между запросом и ответом — то, что ss/netstat в принципе не показывают, так как не видят содержимое отдельных пакетов.

Пример кода

commands.shКопировать

ss -tan state established '( dport = :443 or sport = :443 )' | wc -l
tcpdump -i eth0 host 203.0.113.10 and port 443 -w capture.pcap -C 100

Что использовать на практике

• Практика. для периодических (intermittent) таймаутов стоит сначала собрать статическую картину через ss (есть ли признаки переполнения очередей, аномальное число соединений в определённом состоянии), а затем запустить длительный захват tcpdump с фильтром по нужному хосту/порту и ограничением размера файла, чтобы поймать момент проблемы и потом детально разобрать её в Wireshark или tshark.

Подводные камни

• Риск. Частая ошибка — запускать tcpdump без фильтров и ограничения размера на высоконагруженном сервере, что создаёт огромные дампы, сложные для анализа, и дополнительную нагрузку на диск и CPU именно в момент диагностики проблемы.