Устаревший инструмент netstat отображает сокеты, маршруты и статистику интерфейсов. В современном Linux для проверки сокетов предпочтительна команда ss: она эффективно показывает состояние сокетов ядра и поддерживается вместе с iproute2.
Устранение неполадок · Урок 4
netstat
Научитесь проверять сокеты, слушающие порты, очереди и состояния TCP в Linux с помощью ss.
Список слушающих сокетов
Покажите слушающие сокеты TCP и UDP в числовом виде, включая владеющие ими процессы, если это разрешено:
$ sudo ss -lntup
-l выбирает слушающие сокеты, -n отключает поиск имён, -t и -u выбирают TCP и UDP, а -p запрашивает сведения о процессах. UDP не устанавливает соединение, поэтому у его неприсоединённых привязанных сокетов нет рукопожатия LISTEN, подобного TCP.
Зачем использовать -n при диагностике сокетов?
Порты, конечные точки и службы
Локальная конечная точка сокета объединяет адрес, транспортный протокол и порт. Соединение TCP различается по протоколу, исходным и конечным адресам и портам. /etc/services сопоставляет условные имена с числами, но не доказывает, какой процесс сейчас владеет портом или на каком прикладном протоколе он говорит.
Что устанавливает запись /etc/services вроде https 443/tcp?
Чтение состояний TCP
Распространённые состояния:
SYN-SENT: локальная конечная точка отправила запрос соединения и ожидает продолжения.ESTAB: соединение TCP установлено.CLOSE-WAIT: другая сторона закрыла свою отправляющую часть, но локальное приложение ещё не закрыло сокет.TIME-WAIT: активно закрывшая соединение сторона ждёт, чтобы задержанные сегменты истекли, а заключительный обмен можно было безопасно обработать.
Большое или растущее число CLOSE-WAIT часто указывает на поведение локального приложения при очистке. TIME-WAIT — нормальное состояние протокола; эксплуатационная проблема зависит от количества и влияния на ресурсы.
Какая сторона ещё должна закрыть сокет в состоянии CLOSE-WAIT?
Интерпретация очередей
Значение Recv-Q и Send-Q зависит от состояния и протокола. Для установленных сокетов TCP они могут показывать данные, ожидающие чтения приложением или подтверждения передачи. Для слушающих сокетов поля описывают состояние очереди соединений, а не байты полезной нагрузки приложения в том же смысле.
Один снимок не доказывает утечку или узкое место. Наблюдайте изменения во времени и сопоставляйте их с поведением процесса, задержкой приложения, повторными передачами и ограничениями ресурсов.
Почему одного снимка большой очереди сокета недостаточно для диагностики?
Ограничение области исследования
Ограничивайте вывод интересующими протоколом, состоянием, конечной точкой или процессом:
$ ss -tn state established
$ ss -ltn 'sport = :443'
Слушающий сокет подтверждает локальную готовность транспорта, но не удалённую достижимость или исправность приложения. Затем выполните проверки маршрута, межсетевого экрана, пакетов, TLS и приложения, соответствующие симптому.
Чего не доказывает слушающий TCP-сокет на порту 443?
Урок завершён
Вы завершили netstat
Теперь вы можете использовать ss для проверки состояния сокетов, не путая порты с приложениями.
Выводите слушающие сокеты численно и со сведениями о процессах.
Отличайте условные имена служб от владения во время выполнения.
Интерпретируйте состояния закрытия TCP с точки зрения локальной конечной точки.
Наблюдайте очереди во времени с учётом нагрузки.
Проверяйте удалённое поведение приложения помимо локального слушающего сокета.
Сохраните прогресс
Создайте бесплатный аккаунт, чтобы сохранить этот урок и продолжить на любом устройстве.
Создать бесплатный аккаунт