qual é a especificação de formato para 'ss -D'?

Question

Antecedentes da pergunta: Estou tentando resumir a largura de banda total, mas ss -i converteu inteligentemente os números em formatos mais legíveis, como Kbps / s ou Mbps / s, o que não é exato. O mesmo acontece com ss -o com temporizadores. Eu olhei o código-fonte e acho que a conversão é codificada. Então eu preciso de um número bruto de algum lugar.

De man ss

-D FILE
Do not display anything, just dump raw information about TCP sockets to FILE after applying filters. If FILE is - stdout is used.

Eu não vejo o formato documentado em qualquer lugar, eu sou muito n00b em C tão rapidamente se perdeu na selva de código fonte iproute2. Além disso, esse despejo bruto depende muito do kernel, eu acho. Qualquer guru do kernel pode me dar algumas dicas?

    

Answer 1

Além do que está disponível na man page de ss , não encontrei muita documentação sobre essa ferramenta. Pior, parece não haver nenhum guia ou menção em nenhum lugar sobre detalhes sobre o que é descartado no arquivo quando você usa a opção -D .

Eu encontrei este documento, SS Utility: Quick Intro , mas faz rally sem menção significativa da opção -D . OBSERVAÇÃO: Este documento é de autoria do criador de ss , e a fonte deste documento é mantido como parte da árvore de fontes .

Procurando na árvore de fontes ( kernel.org ou github ), a função que faz o trabalho de escrever este arquivo está contida, mas não é tão fácil de descobrir o que está acontecendo. / p>

Acabei de abrir um problema no github fazendo esta pergunta para ver se o desenvolvedor pode lançar alguma luz sobre isso.

• Documentação sobre a saída da chave ss -D?

UPDATE # 1

O autor voltou ao meu problema e afirmou que o formato do arquivo é chamado de netlink.

The file is in netlink format; ie. format the netlink message format used when iproute and related commands interact with kernel.

Detalhes sobre o formato do arquivo são abordados neste RFC3549, intitulado: Linux Netlink como um protocolo de serviços IP . Eu também encontrei este HOWTO intitulado: Generic Netlink HOW-TO baseado no documento original de Jamal , que pode ser útil também. Um howto também é mantido no site da linuxfoundation, intitulado: generic_netlink_howto .

O autor também sugeriu usar a biblioteca libmnl ao tentar analisar arquivos contendo informações de netlink.

Look at libmnl as best way to handle/parse netlink.

A documentação desta biblioteca é mantida aqui: Documentação libmnl . A página do projeto para libmnl é mantida sob o site netfilter.org como um subprojeto. A interface web do seu repositório git também está acessível.

    

Answer 2

De acordo com sua página de manual em um sistema Linux, ss(8) é "outro utilitário para investigar soquetes"; é específico do Linux, parte de iproute , mas parece ser similar em conceito ao mais comum netstat .

Este é um exemplo de saída de ss -i :

# ss -i | head
State      Recv-Q Send-Q      Local Address:Port          Peer Address:Port
ESTAB      0      0         173.xxx.xxx.xxx:46780         72.21.203.xx:www
         cubic wscale:6,7 rto:276 rtt:76/38 cwnd:10 send 1.5Mbps rcv_space:14600
ESTAB      0      0         173.xxx.xxx.xxx:35674        208.71.121.xx:www
         cubic rto:272 rtt:72/36 cwnd:10 send 1.6Mbps rcv_space:14600
ESTAB      0      0         173.xxx.xxx.xxx:33496       198.252.206.xx:https
         cubic wscale:9,7 rto:274 rtt:74.875/2.25 ato:40 cwnd:10 send 1.5Mbps rcv_rtt:524913 rcv_space:29456
ESTAB      0      0         173.xxx.xxx.xxx:49605       205.251.242.xx:www
         cubic wscale:6,7 rto:282 rtt:82.625/37.5 cwnd:10 send 1.4Mbps rcv_space:14600

Como você pode ver, as informações sobre a fila de recebimento e envio estão disponíveis, assim como com netstat , mas ss vai além e também fornece informações adicionais, que parecem girar em torno do conceito de Escalonamento da janela TCP e tamanho do buffer do soquete e em torno do conceito de produto de atraso de largura de banda .

Portanto, essa largura de banda sobre a qual você está falando provavelmente é calculada através da divisão do tamanho do buffer de envio por rtt (tempo de ida e volta). Qualquer cálculo desse tipo está fadado a ser muito grosseiro, impreciso e variável, assim, quando você vê um valor como 1.6Mbps , não há muito sentido em saber mais pontos decimais, já que o número inteiro é simplesmente um alvo em movimento.