tshark desempenho de captura de pacotes CentOS 6 v CentOS 7

Question

Estou tentando capturar aproximadamente 20mbit / s de tráfego continuamente com o tshark. Se eu capturar pacotes com tshark no CentOS 6.5, recebo cerca de 4% a 66% dos pacotes descartados. Se eu fizer a mesma coisa no CentOS 7, ele nunca reportará nenhum pacote descartado. Na verdade, tentei fazer com que ele descartasse pacotes fazendo coisas malucas, como gerar grandes quantidades de tráfego para xml. Tanto quanto eu posso dizer que não está perdendo pacotes. Minha pergunta é: o CentOS 7 tem algum tipo de recurso que impossibilita a eliminação de pacotes? Ou está descartando pacotes e não está me dizendo?

Como exemplo, executo comandos como este:

tshark -i ens224 -c 100000 -w /tmp/delme.pcap
tshark -i ens224 -c 100000 -T pdml > /tmp/delme.pcap

Para o primeiro comando, o CentOS 6 reporta 4% de pacotes descartados, o CentOS 7 reporta nenhum. Para o segundo comando, os relatórios do CentOS caíram 66% dos pacotes, mas o CentOS 7 reportou nenhum.

Note que ambas as máquinas estão executando o tshark 1.12.7 compilado a partir da fonte.

    

Answer 1

My question is, does CentOS 7 have some sort of feature that makes dropping packets impossible?

Não, mas tem dois recursos que tornam menos provável a eliminação de pacotes:

1. uma versão do kernel que inclui TPACKET_V3 para PF_PACKET sockets;
2. uma versão da libpcap que usa TPACKET_V3 para PF_PACKET sockets.

O Libpcap usa PF_PACKET sockets para capturar no Linux 2.2 e posterior (o Linux 1.xeo 2.0 não possuem PF_PACKET sockets). Os pacotes originais PF_PACKET sockets entregues usando os mecanismos de socket regulares, significando que libpcap (ou qualquer outro programa que captura tráfego) tinha que fazer uma chamada recvmsg() naquele socket para cada pacote. Isso era mais caro do que, por exemplo, o funcionamento do mecanismo BPF no * BSD e OS X, onde vários pacotes são entregues em cada leitura, portanto, com um alto nível de tráfego, menos chamadas do sistema são feitos.

O Linux 2.4, eu acho, introduziu o mecanismo "turbo" (que é o que significa "T" em "TPACKET" - "turbo"), que fornece um buffer mapeado por memória compartilhado pelo kernel e pela userland. Com isso, menos cópias são necessárias ao entregar pacotes, e o loop de leitura de pacotes no userland pode processar vários pacotes por ativação (para aguardar a chegada dos pacotes, o usuário faz uma chamada select() , poll() ou epoll() ) . Infelizmente, esse mecanismo forneceu um anel de buffers de tamanho fixo, e a libpcap tem que escolher um tamanho grande o suficiente para o maior pacote possível. Versões anteriores escolheram pacotes que eram do mesmo tamanho que a duração do snapshot, ie provavelmente 64K-1 para a versão do Wireshark que você está usando, o que é bastante desperdício - o buffer acaba não tendo slots suficientes para pacotes para evitar excesso. Algumas versões posteriores tentaram usar o MTU para determinar o tamanho do slot, mas nem sempre ele pode fazer isso, e mesmo que isso possa ser um desperdício.

Em alguma versão 3.x (3.6?), foi adicionado TPACKET_V3 , um mecanismo de turbojato significativamente diferente. É mais como BPF, em que um buffer não contém um pacote, ele pode ter vários pacotes compactados nele. Isso faz um uso muito melhor da memória para capturar e muito menos pacotes são descartados.