Get best of the week

¿Qué significa la salida de "ss -s"

La utilidad netstat ha sido reemplazada por la utilidad ss , y muy a menudo el resultado de la información agregada (resumen) " ss -s " (o " ss --summary ") se utiliza para monitorear las necesidades. Sin embargo, ¿qué significa cada uno de los campos mostrados?

# ss -s
Total: 15046 (kernel 16739)
TCP:   39306 (estab 11458, closed 25092, orphaned 110, synrecv 0, timewait 24929/0), ports 0

Transport Total     IP        IPv6
*	  16739     -         -        
RAW	  0         0         0        
UDP	  15        5         10       
TCP	  14214     1214      13000    
INET	  14229     1219      13010    
FRAG	  0         0         0

Al final resultó que, hay sutilezas.

La fuente de la verdad es el código fuente. El código fuente de la utilidad «ss» se encuentra en iproute2 / varios / ss.c . La salida de "ss -s" se realiza en la función print_summary .

Antes de la versión 4.17.0, la salida de "ss -s" se muestra arriba. Después de cometer 90ee99d, comenzó a verse así:

# ss -s
Total: 15046
TCP:   39306 (estab 11458, closed 25092, orphaned 110, timewait 24929)

Transport Total     IP        IPv6
RAW	  0         0         0        
UDP	  15        5         10       
TCP	  14214     1214      13000    
INET	  14229     1219      13010    
FRAG	  0         0         0

Como puede ver, el campo "kernel" se ha eliminado de la línea "Total". En la línea "TCP", se eliminó el campo "synrecv", quedó un (primer) número "tiempo de espera", se eliminó el campo "puertos". En la tabla "Transporte" se eliminó la fila "*". El significado general de la confirmación se puede traducir como: " Hemos eliminado de la salida lo que se ha roto durante mucho tiempo ".

¿Qué estaba roto?


En print_summary versión 4.16.0 se usa la estructura slabstat , rellenada llamando a get_slabstat . Si intentamos traducir la llamada get_slabstat en comandos de shell, obtenemos lo siguiente:

# egrep '^(sock|tcp_bind_bucket|tcp_tw_bucket|tcp_open_request|skbuff_head_cache)' /proc/slabinfo | awk '{ print $1, $2; }'

Donde las claves de "/ proc / slabinfo" corresponden a los campos de la estructura "slabstat":

struct slabstat {
	int socks;       // sock, net/core/sock.c:sk_init,   2.6.12
	int tcp_ports;   // tcp_bind_bucket, net/ipv4/tcp.c:tcp_init
	int tcp_tws;     // tcp_tw_bucket, net/ipv4/tcp.c:tcp_init,   2.6.14
	int tcp_syns;    // tcp_open_request, net/ipv4/tcp.c:tcp_init,   2.6.13
	int skbs;        // skbuff_head_cache, net/core/skbuff:skb_init,  
};

En otras palabras, de todos los valores obtenidos de "/ proc / slabinfo" hoy, solo se puede obtener el valor "tcp_bind_bucket", que se muestra en el campo "puertos". Daré su descripción del libro “Arquitectura, diseño e implementación TCP / IP en Linux. Por S. Seth y MA Venkatesulu 2008, la IEEE Computer Society ":
This structure keeps information about the port number usage by sockets and the way the port number is being used. The information is useful enough to tell the new binding socket whether it can bind itself to a particular port number that is already in use. The data structure also keeps track of all the socket’s that are associated with this port number.
Ahora de nuevo lo mismo, pero en forma de imagen (el artista mío es más o menos):



¿Notas algo extraño? El "calcetín" de losa (eliminado en 2.6.12) tiene un valor distinto de cero. La explicación es muy simple: debido a las peculiaridades de la comparación de cadenas, cualquier número cuya clave comience con "calcetín" entrará en el valor del campo. En mi caso, esto es "sock_inode_cache" de "net / socket.c: init_inodecache" relacionado con "sockfs" - una lista de "inodes" que contiene "socket struct" (tal vez esto no es exactamente lo que pretendía el autor de la utilidad):

# egrep '^sock' /proc/slabinfo | awk '{ print $1, $2; }'
sock_inode_cache 16739

Bueno, "tcp_bind_bucket" falta solo por las opciones de compilación del núcleo (y, en consecuencia, el campo "puertos" siempre tiene el valor "0").

Descripción de salida "ss -s"


Antes de sumergirse en las complejidades de los cálculos de campo, tiene sentido actualizar el estado de los sockets en la memoria (ESTABLECIDO, CIERRE-ESPERA, TIEMPO-ESPERA, etc.). Para aquellos que lo han olvidado, ayuda wiki: RU , EN .

El resultado de la utilidad se basa en los valores obtenidos de los archivos:

# cat /proc/net/sockstat
sockets: used 15046
TCP: inuse 1205 orphan 111 tw 24952 alloc 14368 mem 5890
UDP: inuse 5 mem 86
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0

# cat /proc/net/sockstat6
TCP6: inuse 13000
UDP6: inuse 10
UDPLITE6: inuse 0
RAW6: inuse 0
FRAG6: inuse 0 memory 0

# egrep '^Tcp:' /proc/net/snmp
Tcp: RtoAlgorithm RtoMin RtoMax ... AttemptFails EstabResets CurrEstab ...
Tcp: 1 200 120000 ... 1348218 4095008 11458 ...

Valores calculados a partir del contenido de "net / sockstat" (para simplificar la percepción en las imágenes):



  • Total : el número total de sockets en el sistema (incluidos los sockets Unix) en cualquier estado, excepto TIME_WAIT;
  • TCP: el número total de sockets TCP (incluido IPv6) en cualquier estado, los sockets tw se separan de los sockets de asignación debido a la llamada. " Corredor de la muerte ": no se pueden usar hasta la transición al estado CERRADO.
    • orphaned — «» TCP (, );
    • timewait — TCP TIME_WAIT;
    • inuse TCP, UDP, RAW — v4 CLOSED TIME_WAIT;
    • inuse FRAG (bool) — , memory — ( mem, ).

Valores calculados por el contenido de "net / sockstat6":



Todo parece ser simple aquí: " Transporte / Total " es la suma de uno de los valores de " IP " e " IPv6 ".

Valores calculados a partir del contenido de "net / snmp". De acuerdo con RFC-4022 , " tcpCurrEstab " es "El número de conexiones TCP para las cuales el estado actual está ESTABLECIDO o CIERRE-ESPERA".



Y el último campo " cerrado " es la suma de los sockets asignados y los sockets en el estado TIME_WAIT menos la suma de los sockets TCPv4 y TCPv6 en cualquiera de los estados no cerrados:



PS Y no olvide firmar los ejes en los gráficos.

More articles:


All Articles