“ss” no pacote iproute; Por que consultar tabela de laje para soquetes de timewait?

Question

Perdoe-me se este não for o melhor fórum para esta questão, mas parece mais relevante para o kernel do que para a própria programação.

Estou escrevendo um script que consulta o sistema em busca de portas abertas para que possamos representar graficamente e monitorar as estatísticas. Para isso, estou usando o comando "ss" do pacote iproute. Se você executar ss -s|grep estab , você receberá uma saída semelhante a esta:

TCP:   296 (estab 6, closed 238, orphaned 0, synrecv 0, timewait 238/0), ports 0

Minha pergunta tem a ver com a variável timewait, que mostra os soquetes calculados no estado TIME_WAIT. Quando tentei descobrir qual número era referenciado após a barra, tornou-se uma aventura rápida procurar código-fonte, o que me levou a encontrar o seguinte trecho:

printf("TCP:   %d (estab %d, closed %d, orphaned %d, synrecv %d, timewait %d/%d), ports %d\n",
       s.tcp_total + slabstat.tcp_syns + s.tcp_tws,
       sn.tcp_estab,
       s.tcp_total - (s.tcp4_hashed+s.tcp6_hashed-s.tcp_tws),
       s.tcp_orphans,
       slabstat.tcp_syns,
       s.tcp_tws, slabstat.tcp_tws,
       slabstat.tcp_ports
       );

Devo admitir, minha busca pelo que "slabstat" deveria significar, em última instância, levou ao meu aprendizado sobre os caches slab e sua interface de relatórios em / proc / slabinfo.

A pergunta: O que a slabtable tem a ver com os cálculos de socket TIME_WAIT? Não consigo descobrir por que esse número é relatado, pois toda vez que executei o comando em todos os servidores em que o testei, o número sempre foi zero.

    

Answer 1

Parece que tcp_tw_buckets é o que é pesquisado, o que é uma estrutura removida do Linux 2.6.12

Assim, o último número provavelmente seria sempre 0, a menos que esteja nos kernels de 7 anos.

Quanto à consulta de placas, até onde eu sei, é ridiculamente mais rápido do que os outros métodos disponíveis.