La herramienta antigua netstat muestra sockets, rutas y estadísticas de interfaces. En Linux moderno, ss es la herramienta preferida para inspeccionar sockets porque expone con eficiencia su estado en el kernel y se mantiene junto con iproute2.
Resolución de Problemas · Lección 4
netstat
Aprende a inspeccionar sockets, listeners, colas y estados TCP de Linux con ss.
Enumerar sockets a la escucha
Muestra numéricamente los sockets TCP y UDP a la escucha, incluidos los procesos propietarios cuando esté permitido:
$ sudo ss -lntup
-l selecciona listeners, -n evita la resolución de nombres, -t y -u seleccionan TCP y UDP, y -p solicita datos de procesos. UDP no usa conexiones, por lo que sus sockets vinculados sin conexión no tienen negociaciones LISTEN como TCP.
¿Por qué se utiliza -n al diagnosticar sockets?
Puertos, extremos y servicios
Un extremo de socket local combina una dirección, un protocolo de transporte y un puerto. Una conexión TCP se distingue por el protocolo y las direcciones y puertos de origen y destino. /etc/services asigna nombres convencionales a números, pero no demuestra qué proceso posee un puerto en ese momento ni qué protocolo de aplicación utiliza.
¿Qué establece una entrada de /etc/services como https 443/tcp?
Leer los estados TCP
Algunos estados habituales son:
SYN-SENT: el extremo local envió una solicitud de conexión y espera que avance.ESTAB: la conexión TCP está establecida.CLOSE-WAIT: el par cerró su lado emisor, pero la aplicación local no ha cerrado su socket.TIME-WAIT: el extremo que cerró activamente espera para que caduquen los segmentos retrasados y el intercambio final pueda manejarse de forma segura.
Una población grande o creciente de CLOSE-WAIT suele apuntar al comportamiento de limpieza de la aplicación local. TIME-WAIT es un estado normal del protocolo; su cantidad y el impacto sobre los recursos determinan si supone un problema operativo.
¿Qué lado todavía debe cerrar un socket en CLOSE-WAIT?
Interpretar las colas
El significado de Recv-Q y Send-Q depende del estado y el protocolo. En sockets TCP establecidos pueden indicar datos en espera de recepción por la aplicación o de confirmación de transmisión. En sockets a la escucha, los campos de cola describen el estado de la acumulación de conexiones, no bytes de carga útil de la aplicación de la misma manera.
Una sola instantánea no permite confirmar una fuga o un cuello de botella. Toma muestras a lo largo del tiempo y correlaciónalas con el comportamiento del proceso, la latencia de la aplicación, las retransmisiones y los límites de recursos.
¿Por qué una sola instantánea de una cola de sockets grande no basta para diagnosticar?
Filtrar una investigación
Limita la salida al protocolo, estado, extremo o proceso investigado:
$ ss -tn state established
$ ss -ltn 'sport = :443'
Un listener demuestra que el transporte local está preparado, no que sea accesible de forma remota ni que la aplicación funcione correctamente. Continúa con pruebas de ruta, cortafuegos, paquetes, TLS y aplicación adecuadas para el síntoma.
¿Qué no demuestra un listener TCP en el puerto 443?
Lección completada
Has completado netstat
Ahora puedes utilizar ss para inspeccionar el estado de los sockets sin confundir los puertos con las aplicaciones.
Enumera listeners numéricamente con el contexto de sus procesos.
Distingue los nombres de servicio convencionales de la propiedad en ejecución.
Interpreta los estados de cierre TCP desde la perspectiva del extremo local.
Toma muestras de las colas a lo largo del tiempo y con el contexto de la carga.
Verifica el comportamiento remoto de la aplicación más allá del listener local.
Guarda tu progreso
Crea una cuenta gratuita para guardar esta lección y continuar en cualquier dispositivo.
Crear una cuenta gratuita