Investigando conexões no Linux: por que abandonei o netstat e fui para o ss e lsof no nível de kernel

Quem gerencia servidores web e aplicações com tráfego real conhece bem o momento em que a carga sobe de repente, as requisições começam a enfileirar e você precisa de uma resposta rápida: o que está acontecendo com as conexões do sistema agora?

Por muito tempo, o reflexo padrão de muitos usuários foi digitar o velho netstat. Porém, em cenários de alta concorrência ou saturação de rede, confiar no binário clássico do pacote net-tools pode travar o terminal exatamente na hora do incidente.

Abaixo, compartilho por que migrei meu fluxo de diagnóstico definitivo para o ss (Socket Statistics) e o lsof, analisando o que muda nas chamadas de sistema (syscalls) e no Kernel do Linux.

O gargalo do netstat sob alta carga: a armadilha do /proc#

Ao precisar identificar portas presas ou conexões zumbis, a velocidade da ferramenta de inspeção é determinante.

O netstat obtém os dados lendo e interpretando os arquivos virtuais em /proc/net/tcp e /proc/net/udp. Em ambientes com dezenas de milhares de conexões ativas, o kernel precisa formatar cada entrada de socket como uma linha de texto antes de entregar os dados:

1. Alto consumo de CPU e I/O virtual: O kernel gasta ciclos preciosos serializando texto.
2. Latência de resposta: A ferramenta demora para exibir os dados enquanto o servidor já está sobrecarregado.
3. Leitura não-atômica: O estado da tabela de sockets pode mudar no meio da leitura do arquivo gigante.

Para contornar esse gargalo, a solução moderna é o ss (presente no pacote iproute2).

O comando padrão de diagnóstico no dia a dia (ss)#

Para extrair um panorama completo de sockets com máxima velocidade e sem travas de rede:

ss -tupna

O que cada flag faz:#

• -t: Filtra sockets TCP.
• -u: Filtra sockets UDP.
• -p: Mostra o nome do processo e o PID associado ao socket (exige sudo).
• -n: Modo numérico. Desativa a resolução de nomes para evitar esperas no DNS.
• -a: Exibe todos os sockets (tanto em escuta (listening) quanto estabelecidos).

O que acontece por baixo dos panos: netlink IPC e tcp_diag#

A superioridade do ss é estrutural. Em vez de abrir arquivos no /proc, o ss conversa diretamente com o módulo tcp_diag (ou inet_diag) do Kernel Linux utilizando sockets Netlink IPC.

Ao rodar um strace no ss:

strace -e socket,sendto,recvmsg ss

Vemos o kernel abrindo um socket AF_NETLINK para transferir um dump binário atômico da tabela de sockets:

socket(AF_NETLINK, SOCK_RAW, NETLINK_INET_DIAG) = 3
sendto(3, {len=72, type=INET_DIAG_GET /* ou TCPDIAG_GETSOCK */, ...}) = 72
recvmsg(3, {msg_name=..., msg_iov=[{...}]}, ...) = 4096

Essa comunicação direta via Netlink entrega o estado da rede instantaneamente, mesmo sob ataques de DDoS ou picos de tráfego.

Caçando portas presas e conflitos com lsof#

Enquanto o ss brilha em métricas de rede, o lsof (List Open Files) é imbatível para caçar descritores de arquivos e resolver o temido erro Address already in use (EADDRINUSE).

1. Filtrar portas específicas sem resolução de nomes:#

lsof -i :80,443 -nP

2. Isolar o processo exato que está escutando na porta:#

lsof -i TCP -s TCP:LISTEN

Isso revela workers órfãos ou processos zumbis que impedem o Nginx, Apache ou Node.js de iniciarem.

Filtros rápidos e métricas úteis no ss#

Sumário instantâneo de estados TCP:#

Para verificar se há acúmulo de SYN_RECV (possível SYN Flood) ou TIME_WAIT (exaustão de portas efêmeras):

ss -s

Filtros nativos inline (sem usar grep):#

ss -o state established '( dport = :http or dport = :https )'

Sockets de domínio unix (PHP-FPM, MySQL):#

ss -x 'src unix:/tmp/php-fpm.sock' # ou de forma portavel: ss -xlp | grep php-fpm.sock

Afinando o kernel: parâmetros sysctl essenciais#

Durante a análise de conexões, dois parâmetros do kernel merecem atenção para evitar o descarte silencioso de pacotes:

1. net.core.somaxconn: Tamanho máximo da fila de conexões pendentes (backlog). O padrão antigo em distribuições legadas era 128 ou 1024, enquanto kernels modernos (5.4+) já trazem 4096 por padrão. Eleve para 65535 se os testes de carga confirmarem descarte de pacotes SYN.
2. net.ipv4.ip_local_port_range: Intervalo de portas efêmeras para conexões de saída (indispensável para proxies reversos conectando ao backend).

Para inspecionar os valores atuais no terminal:

sysctl -a | grep -E 'somaxconn|port_range'

Conclusão#

Dominar utilitários que conversam diretamente com o kernel via Netlink (ss) e entender o mapeamento de descritores com o lsof transforma completamente a agilidade no diagnóstico de redes no Linux.

Veja também

Linux Post-mortem de um desktop travando: do futex lockup ao Cgroups v2 no Linux

Infraestrutura Anatomia de um deadlock silencioso no CloudLinux e cPanel: processos fantasmas, travas de sessão e filas TCP

DevOps Quando o VS code remote e o antigravity quase derrubaram meu servidor: anatomia de um thrashing de memória

Este post está licenciado sob CC BY-NC.