Устранение проблем с производительностью: эффективное использование 'netstat' и 'ss'

Когда служба Linux работает медленно, таблица сокетов — одно из самых быстрых мест, чтобы отделить «приложение перегружено» от «сетевой путь запутан». Веб-сервер, который не может принимать новые соединения, рабочий процесс, застрявший при открытии сеансов базы данных, и хост с кучей полуоткрытых TCP-рукопожатий — все это выглядит как неопределенная медлительность для человека, ожидающего на другом конце.

netstat и ss помогают ответить на более узкий вопрос: какие сетевые сокеты существуют на этой машине прямо сейчас, в каком они состоянии и какой процесс ими владеет? netstat все еще полезен на старых системах и в старых руководствах. ss — это инструмент, к которому я обращаюсь в первую очередь на современном Linux, потому что он быстрее на загруженных хостах и имеет лучшую встроенную фильтрацию.

Зачем отслеживать сетевые сокеты?

Сетевая задержка и медлительность часто связаны с проблемами соединения, а не с исчерпанием ресурсов ЦП или памяти. Мониторинг сокетов помогает администраторам ответить на критические вопросы, такие как:

• Какие порты активно прослушивают соединения?
• Не слишком ли много соединений застряло в состояниях SYN_RECV или TIME_WAIT?
• Какой процесс (PID) использует определенный порт?
• Есть ли неожиданные исходящие соединения?

Изучая статистику сокетов, вы можете быстро исключить проблемы с конфигурацией сети или выявить конфликт ресурсов, связанный с обработкой соединений.

Устаревший инструмент: netstat

netstat был стандартной утилитой для отображения сетевых соединений, таблиц маршрутизации, статистики интерфейсов и маскарадных соединений на протяжении десятилетий. Хотя во многих современных системах он устарел в пользу ss, он остается широко доступным и часто знаком администраторам со стажем.

Распространенные примеры netstat

Наиболее распространенные флаги, используемые с netstat, предоставляют всесторонний обзор:

Флаг	Описание
-a	Показывает все сокеты (прослушивающие и непрослушивающие)
-n	Показывает числовые адреса вместо попытки разрешить имена хостов и служб (ускоряет вывод)
-t	Показывает TCP-соединения
-u	Показывает UDP-соединения
-l	Показывает только прослушивающие сокеты
-p	Показывает PID/имя программы, связанной с сокетом (требуются права root)

Пример: просмотр всех активных TCP-соединений в числовом формате

sudo netstat -ant

Пример: поиск того, что прослушивает порт 80 (HTTP)

sudo netstat -tulpen | grep ':80'

Понимание состояний соединений (netstat)

Вывод netstat часто включает столбец State. Ключевые состояния, на которые стоит обратить внимание, включают:

• LISTEN: Ожидание входящих соединений.
• ESTABLISHED: Активное, открытое соединение.
• TIME_WAIT: Сокет ожидает короткий период после закрытия, чтобы гарантировать обработку задержанных пакетов.
• SYN_RECV: Ожидание окончательного подтверждения трехстороннего рукопожатия (может указывать на SYN-флуд атаку, если их чрезмерно много).

Предупреждение о netstat: netstat часто полагается на разбор файлов /proc/net/*, что может быть медленно, особенно в системах с очень большим количеством активных соединений (тысячи). Это основная причина, по которой был разработан ss.

Современная замена: ss (Статистика сокетов)

Утилита ss значительно быстрее netstat, поскольку она получает информацию о сокетах непосредственно из пространства ядра с помощью сокетов Netlink, минуя более медленные обращения к файловой системе.

Распространенные примеры ss

Структура флагов для ss очень похожа на netstat, что облегчает переход:

Флаг	Описание
-a	Показывает все сокеты
-n	Показывает числовые адреса
-t	Показывает TCP-сокеты
-u	Показывает UDP-сокеты
-l	Показывает прослушивающие сокеты
-p	Показывает информацию о процессе (PID/Программа)

Пример: просмотр всех активных TCP-соединений в числовом формате (эквивалент netstat -ant)

ss -ant

Пример: поиск того, что прослушивает порт 443 (HTTPS)

sudo ss -tulpen | grep ':443'

Расширенная фильтрация с помощью ss

Одним из самых больших преимуществ ss является возможность выполнять прямую фильтрацию по состояниям соединений, что гораздо эффективнее, чем передача вывода netstat в grep.

Фильтрация по состоянию соединения

Вы можете использовать опцию state непосредственно в команде ss. Это чрезвычайно полезно для диагностики накопления соединений.

Поиск всех сокетов, находящихся в состоянии TIME-WAIT:

ss -tan state time-wait

Поиск всех сокетов в состоянии SYN-SENT (клиентская сторона ожидает ответа сервера):

ss -tan state syn-sent

Фильтрация по порту или адресу

Фильтрация по адресу или порту назначения/источника проста:

Показать установленные соединения, предназначенные для порта 22 (SSH):

ss -tn state established '( dport = :22 or sport = :22 )'

Показать соединения, связанные с определенным локальным IP-адресом:

ss -ant '( daddr = 192.168.1.100 or saddr = 192.168.1.100 )'

Анализ производительности: сравнение netstat и ss

При устранении неполадок выбор между инструментами часто сводится к скорости и детализации.

Особенность	netstat	ss
Скорость	Медленнее (Читает файлы)	Намного быстрее (Использует сокеты Netlink)
Синтаксис	Зрелый, хорошо документированный	Похожие флаги, новые специфические опции
Фильтрация	Требуется передача в grep	Встроенная поддержка фильтрации по состоянию и адресу
Глубина информации	Хорошо для основ	Больше деталей о размерах буфера сокета (TCP Info)
Доступность	Почти повсеместно	Стандарт на современных дистрибутивах Linux

Диагностика медленного установления соединения

Если клиенты сообщают о медленных соединениях, проверьте сокеты, застрявшие в ожидании рукопожатий. Использование ss — самый быстрый способ это определить:

1. Проверьте высокое количество SYN-RECV: Это предполагает, что сервер получает запросы на соединение, но не завершает рукопожатие, часто из-за нехватки ресурсов или высокой нагрузки трафика.

   ss -s | grep syn-rec
   

2. Проверьте высокое количество SYN-SENT: Если сам сервер инициирует много соединений (например, выступая в роли клиента для баз данных или других API), это показывает, что он ожидает ответов.

   ss -s | grep syn-sent
   

Если вы видите постоянно высокие числа в любой из категорий, рассматривайте их как зацепку, а не как вердикт. SYN-SENT может означать, что удаленный хост не работает, маршрут неверен, брандмауэр молча отбрасывает трафик или удаленная служба перегружена. SYN-RECV может означать, что сервер находится под нагрузкой, пакеты теряются или клиенты открывают соединения и не завершают их.

Практический поток триажа

Когда кто-то говорит «приложение тормозит», я обычно начинаю с короткого повторяемого прохода:

sudo ss -tulpen
ss -s
sudo ss -tan state established '( sport = :443 or dport = :443 )' | head
sudo ss -tan state syn-recv
sudo ss -tan state time-wait | head

Первая команда подтверждает, что ожидаемая служба действительно прослушивается, и показывает владеющий процесс. Сводка показывает, есть ли на хосте удивительное количество TCP-сокетов. Отфильтрованная команда established доказывает, что реальный клиентский трафик привязан к порту. Проверки syn-recv и time-wait показывают, заслуживает ли внимания установка соединения или смена соединений.

Например, представьте обратный прокси-сервер Nginx, где пользователи жалуются, что новые запросы зависают на несколько секунд. sudo ss -tulpen | grep ':443' подтверждает, что Nginx владеет HTTPS-прослушивателем. ss -s показывает большое общее количество TCP, а sudo ss -tan state syn-recv '( sport = :443 )' продолжает возвращать строки из одних и тех же диапазонов источников. Это не доказывает автоматически атаку, но говорит вам проверить проверки работоспособности балансировщика нагрузки, потерю пакетов выше по потоку, давление SYN-очереди, журналы брандмауэра и, возможно, ограничения скорости.

Теперь представьте, что тот же прокси-сервер имеет очень мало сокетов SYN_RECV, но много установленных соединений с вышестоящей базой данных на порту 5432. Это направляет вас от публичного HTTPS к пути базы данных:

sudo ss -tanp '( dport = :5432 or sport = :5432 )'

Если владеющим процессом является ваше приложение, и количество продолжает расти, следующий полезный вопрос: не утекают ли у приложения соединения, ожидает ли оно медленных запросов или не возвращает ли соединения в пул. ss не отвечает на этот вопрос на уровне приложения, но он приводит вас в нужную комнату.

Чтение TIME_WAIT без паники

TIME_WAIT — это нормальное состояние TCP, само по себе не ошибка. Сервер, который обрабатывает много короткоживущих соединений, естественно, будет показывать сокеты TIME_WAIT. Они существуют, чтобы задержанные пакеты от старого соединения не были спутаны с новым.

Полезный вопрос: соответствует ли TIME_WAIT рабочей нагрузке. Пакетное задание, которое открывает новое HTTP-соединение для каждого маленького запроса, может создать волну TIME_WAIT. Служба, которая должна использовать keep-alive, но не использует, может делать то же самое. Прежде чем настраивать параметры ядра, проверьте, может ли приложение повторно использовать соединения, включить HTTP keep-alive или использовать правильный пул клиентов.

Будьте осторожны со старыми советами, которые предлагают слепо изменять TCP sysctl для «исправления» TIME_WAIT. Некоторые настройки зависят от версии ядра, некоторые были удалены или не рекомендуются со временем, а некоторые создают тонкие сбои за NAT или балансировщиками нагрузки. Начните с понимания того, почему соединения являются короткоживущими.

Проверка локального и удаленного давления

Одна деталь, которая экономит время, — это то, принимает ли локальный хост в основном соединения или в основном их создает. Интерфейсный прокси-сервер обычно имеет много соединений, где локальный порт — 80 или 443. Сервер приложений, который общается с базами данных и API, может иметь много соединений, где удаленный порт — 5432, 3306, 6379 или 443.

Для локальных прослушивателей и входящего трафика:

sudo ss -tan '( sport = :443 )'

Для исходящего трафика к зависимостям:

sudo ss -tan '( dport = :6379 )'

Это различие меняет следующий разговор. Если входящий HTTPS накапливается, вам может потребоваться проверить балансировщик нагрузки, завершение TLS, лимиты рабочих процессов или поведение клиента. Если исходящие соединения Redis накапливаются, локальное приложение может создавать слишком много клиентских соединений, ожидать Redis или слишком агрессивно повторять попытки.

Когда вам нужен быстрый подсчет без чтения сотен строк, объедините ss с простыми инструментами оболочки:

sudo ss -tan state established '( dport = :443 )' | wc -l
sudo ss -tan state established '( dport = :5432 )' | wc -l

Подсчет включает строку заголовка, поэтому это не идеальная метрика. Для триажа это все еще полезно. Если число удваивается каждую минуту во время инцидента, у вас есть более сильный сигнал, чем один снимок.

Контейнеры и сетевые пространства имен

На хостах с контейнерами будьте осторожны с тем, где вы выполняете команду. Запуск ss на хосте показывает сетевые пространства имен хоста и опубликованные порты, но может не показывать тот же вид, который процесс видит внутри своего контейнера. Если служба работает в контейнере, сравните оба представления:

sudo ss -tulpen
docker exec <container> ss -tulpen

Для Kubernetes используйте представление узла для прослушивателей на уровне хоста и kubectl exec для сетевого пространства имен модуля. Порт может быть открыт внутри контейнера, в то время как хост, служба, ingress или сетевая политика все еще препятствуют достижению трафика. ss — это инструмент локальной истины, а не сквозной тест связности.

Лучшие практики для устранения неполадок в сети

1. Всегда используйте -n: При устранении неполадок с производительностью или написании скриптов используйте числовой флаг (-n), чтобы избежать задержек разрешения DNS, которые могут замедлить диагностику.
2. Отдавайте приоритет ss: Примите ss как свой инструмент по умолчанию. Оставьте netstat только для устаревших систем, где ss недоступен.
3. Запускайте от root для PID: Чтобы увидеть, какая программа использует порт, вам обычно нужны sudo или права root при использовании флага -p с обеими утилитами.
4. Проверяйте статистику интерфейсов: Не забывайте о счетчиках интерфейсов. Используйте ip -s link show <имя_интерфейса> для проверки потерянных пакетов или ошибок, которые могут указывать на проблему физического уровня, а не на проблему сокетов.
5. Сравнивайте снимки. Один вывод ss — это фотография. Два вывода, сделанные с интервалом в минуту, показывают, растет ли ситуация, уменьшается или стабильна.
6. Записывайте точный фильтр. Во время инцидентов сохраненная команда, такая как ss -tan '( dport = :5432 )', легче повторяется и сравнивается, чем наполовину запомненный конвейер grep.

Привычка, которая окупается, проста: начинайте с прослушивателей, переходите к состояниям соединений, определяйте владеющий процесс, а затем решайте, принадлежит ли следующий шаг приложению, сетевому пути, брандмауэру или ядру.