Início / server / Perguntas / 717161
Accepted
MikeKulls
Asked: 2015-08-27 22:49:24 +0800 CST

desempenho de captura de pacotes tshark CentOS 6 v CentOS 7

  • 772

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% de pacotes descartados. Se eu fizer a mesma coisa no CentOS 7, ele nunca relatará nenhum pacote descartado. Na verdade, tentei fazer com que ele descartasse pacotes fazendo coisas malucas, como enviar grandes quantidades de tráfego para xml. Tanto quanto eu posso dizer, não está perdendo pacotes. Minha pergunta é: o CentOS 7 possui algum tipo de recurso que impossibilita a eliminação de pacotes? Ou está descartando pacotes e não me avisando?

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 relata 4% de pacotes descartados, o CentOS 7 não relata nenhum. Para o segundo comando, o CentOS relata 66% de pacotes descartados, mas o CentOS 7 não relata nenhum.

Observe que ambas as máquinas estão executando o tshark 1.12.7 compilado a partir do código-fonte.

centos

1 respostas

  1. Best Answer

    Minha pergunta é: o CentOS 7 possui algum tipo de recurso que impossibilita a eliminação de pacotes?

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

    1. TPACKET_V3uma versão do kernel que inclui PF_PACKETsoquetes;
    2. uma versão libpcap que usa TPACKET_V3 para PF_PACKETsoquetes.

    Libpcap usa PF_PACKETsoquetes para capturar no Linux 2.2 e posterior (o Linux 1.xe 2.0 não tinha PF_PACKETsoquetes). Os PF_PACKETsoquetes originais entregavam pacotes usando os mecanismos normais de soquete, o que significa que o libpcap (ou qualquer outro programa de captura de tráfego) tinha que fazer uma recvmsg()chamada naquele soquete para cada pacote. Isso era mais caro do que, por exemplo, a forma como o mecanismo BPF no *BSD e OS X funciona, onde vários pacotes são entregues a cada leitura, portanto, com um alto nível de tráfego, menos chamadas de sistema são feitas.

    Acho que o Linux 2.4 introduziu o mecanismo "turbopacket" (que é o que o "T" em "TPACKET" significa - "turbo"), que fornece um buffer mapeado em memória compartilhado pelo kernel e pelo 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 userland faz uma chamada select(), poll(), ou epoll()). Infelizmente, esse mecanismo forneceu um anel de buffers de tamanho fixo e o libpcap precisa escolher um tamanho grande o suficiente para o maior pacote possível. Versões anteriores escolheram pacotes que tinham o mesmo tamanho do tamanho do instantâneo fornecido, ou seja, provavelmente 64K-1 para a versão do Wireshark que você está usando, o que é bastantedesperdício - o buffer acaba não tendo slots suficientes para pacotes para evitar saturação. Algumas versões posteriores tentaram usar o MTU para determinar o tamanho do slot, mas nem sempre pode fazer isso e, mesmo que possa, pode ser um desperdício.

    Em algumas versões 3.x (3.6?), TPACKET_V3um mecanismo turbopacket significativamente diferente foi adicionado. É mais parecido com o BPF, pois 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 captura e muito menos pacotes são perdidos.

    • 4

relate perguntas