rperf
v0.1.8
rperf é uma alternativa iperf baseada em Rust desenvolvida pela 3D-P, com o objetivo de evitar alguns problemas de confiabilidade e consistência encontrados em iperf3 , ao mesmo tempo que fornece dados de métricas mais ricos, com foco na operação em um ambiente mais tolerante a perdas e semelhante a IoT. Embora possa ser usado quase como um substituto imediato para iperf , e possa haver benefícios em fazê-lo, seu foco está na coleta periódica de dados em uma capacidade de monitoramento em uma rede fechada, o que significa que não é adequado para todos os domínios que o iperf pode servir.
rperf é uma implementação independente, referenciando os algoritmos de iperf3 e zapwireless para avaliar a correção e derivar correções adequadas, mas não copiando nenhum código de nenhum deles.
Em particular, as questões mais significativas abordadas no iperf3 são as seguintes:
Vários clientes simultâneos são suportados por qualquer servidor.
A implementação do RFC 1889 pelo rperf para cálculo de jitter de streaming começa assumindo um delta entre o primeiro e o segundo pacotes em uma sequência e as lacunas em uma sequência acionam uma redefinição da contagem. Comparativamente, iperf3 começa com 0, o que cria valores artificialmente baixos, e no caso de uma lacuna, continua ingenuamente, o que cria valores artificialmente altos.
Pacotes duplicados são contabilizados em trocas UDP e pacotes fora de ordem são contados como eventos independentes.
Todo o tráfego pode ser emitido proporcionalmente em intervalos regulares de menos de um segundo, permitindo configurações que refletem com mais precisão a transmissão real de dados e algoritmos de envio.
A configuração do fluxo e os resultados são trocados por meio de uma conexão dedicada e cada caminho de dados tem tempo limite, conclusão e semântica de falha claramente definidos, para que a execução não fique suspensa indefinidamente em nenhum dos lados de um teste quando os pacotes principais são perdidos.
A saída JSON de rperf é estruturalmente legal. Sem strings sem aspas, chaves repetidas ou vírgulas pendentes, que exigem pré-processamento antes do consumo ou causam erros inesperados.
Em contraste com o zapwireless , as seguintes melhorias são realizadas:
O rperf usa uma arquitetura cliente-servidor clássica, portanto não há necessidade de manter um processo em execução em dispositivos que aguardam uma solicitação de execução de teste.
O jitter é calculado.
IPv6 é suportado.
Vários fluxos podem ser executados em paralelo como parte de um teste.
Uma opção omit está disponível para descartar o tempo de aceleração do TCP dos resultados.
A saída está disponível em JSON para facilitar a coleta de telemetria.
rperf deve ser construído e funcionar em todas as principais plataformas, embora seu foco de desenvolvimento e uso seja em sistemas baseados em Linux, então é aí que ele terá mais recursos completos.
Solicitações pull para implementações de recursos equivalentes para outros sistemas são bem-vindas.
Tudo está descrito no resultado de --help e a maioria dos usuários familiarizados com ferramentas semelhantes devem se sentir confortáveis imediatamente.
rperf funciona como iperf3 , compartilhando muitos conceitos e até sinalizadores de linha de comando. Uma área importante em que isso difere é que o cliente conduz todo o processo de configuração, enquanto o servidor apenas cumpre o melhor que pode e fornece um fluxo de resultados. Isso significa que o servidor não apresentará os resultados dos testes diretamente através de sua interface e também que os testes TCP e UDP podem ser executados na mesma instância, potencialmente por vários clientes simultaneamente.
Em seu modo normal de operação, o cliente fará upload de dados para o servidor; quando o sinalizador reverse estiver definido, o cliente receberá dados.
Ao contrário de iperf3 , rperf não faz uso de um intervalo de portas reservado por padrão. Isto ocorre para que ele possa suportar um número arbitrário de clientes em paralelo, sem contenção de recursos no que pode ser praticamente apenas um pequeno número de portas contíguas. Na capacidade pretendida, isso não deve ser um problema, mas no que diz respeito a firewalls não permissivos e configurações de NAT, as opções --tcp[6]-port-pool e --udp[6]-port-pool podem ser usado para alocar portas não contínuas ao conjunto que será usado para receber tráfego.
Também não existe um conceito de teste de rendimento em relação a uma quantidade fixa de dados. Em vez disso, o único foco é medir o rendimento durante um período de tempo aproximadamente conhecido.
Também é relevante que, se o servidor estiver rodando no modo IPv6 e seu host suportar mapeamento IPv4 em uma configuração de pilha dupla, os clientes IPv4 e IPv6 poderão se conectar à mesma instância.
rperf usa carga . O processo típico será simplesmente cargo build --release .
cargo-deb também é suportado e produzirá um pacote Debian utilizável que instala um serviço rperf systemd desabilitado por padrão. Quando iniciado, ele é executado como nobody:nogroup , assumindo suporte IPv6 por padrão.
Como seus contemporâneos, o conceito central do rperf é disparar um fluxo de dados TCP ou UDP em um alvo IP a uma velocidade alvo pré-estabelecida. A quantidade de dados efetivamente recebidos é observada e utilizada para avaliar a capacidade de um link de rede.
Dentro desses domínios, dados adicionais sobre a qualidade do intercâmbio são recolhidos e disponibilizados para revisão.
Arquitetonicamente, o rperf faz com que os clientes estabeleçam uma conexão TCP com o servidor, após a qual o cliente envia detalhes sobre o teste a ser realizado e o servidor obedece, reportando os resultados da observação ao cliente durante todo o processo de teste.
O cliente pode solicitar que vários fluxos paralelos sejam usados para teste, o que é facilitado pelo estabelecimento de múltiplas conexões TCP ou soquetes UDP com seu próprio thread dedicado em cada lado, que pode ser ainda fixado em um único núcleo lógico da CPU para reduzir o impacto da página. -falhas na troca de dados.
O relacionamento cliente-servidor é tratado como um aspecto muito central deste design, em contraste com iperf3 , onde eles são mais parecidos com pares, e zapwireless , onde cada participante executa seu próprio daemon e um terceiro processo orquestra a comunicação.
Notavelmente, toda a coleta, cálculo e exibição de dados acontece no lado do cliente, com o servidor simplesmente retornando o que observou. Isso pode levar a algum desvio nas gravações, especialmente no que diz respeito ao tempo (intervalos de servidor sendo alguns milissegundos mais longos que seus valores de cliente correspondentes não são incomuns). Entretanto, supondo que a conexão não foi perdida, os totais dos dados observados serão iguais em todos os modos de operação.
O servidor utiliza três camadas de threading: uma para o thread principal, uma para cada cliente atendido e mais uma para cada fluxo que se comunica com o cliente. No lado do cliente, o thread principal é usado para se comunicar com o servidor e gera um thread adicional para cada fluxo que se comunica com o servidor.
Quando o servidor recebe uma solicitação de um cliente, ele gera um thread que trata da solicitação específica desse cliente; internamente, cada fluxo do teste produz um manipulador semelhante a um iterador em cada lado. Tanto o cliente quanto o servidor executam esses análogos do iterador um contra o outro de forma assíncrona até que o período de teste termine, momento em que o remetente indica a conclusão em seu fluxo.
Para lidar de forma confiável com a possibilidade de desconexões no nível do fluxo, um mecanismo de manutenção de atividade no fluxo cliente-servidor, através do qual os resultados dos testes são enviados do servidor em intervalos regulares, encerrará conexões pendentes após alguns segundos de inatividade.
Os mecanismos TCP e UDP do sistema operacional host são usados para todo o tráfego real trocado, com alguns parâmetros de ajuste expostos. Essa abordagem foi escolhida em vez de uma implementação de espaço do usuário na camada 2 ou na camada 3 porque representa com mais precisão a maneira como os aplicativos do mundo real se comportarão.
Os valores de "timestamp" visíveis nos dados de intervalo serializados JSON são relativos ao host, portanto, a menos que seu ambiente tenha uma precisão de relógio do sistema muito alta, os carimbos de data e hora de envio devem ser comparados apenas com outros carimbos de data e hora de envio e da mesma forma para carimbos de data e hora de recebimento. Em geral, entretanto, esses dados não são úteis fora da validação de correção.
Durante cada intervalo de troca, é feita uma tentativa de enviar bytes length por vez, até que a quantidade gravada no fluxo atinja ou exceda o alvo de largura de banda, momento em que o remetente fica em silêncio até o início do próximo intervalo; os dados enviados dentro de um intervalo devem ser distribuídos uniformemente ao longo do período.
Os índices de fluxo começam em 0 , não em 1 . Isso provavelmente não surpreenderá ninguém, mas ver o “fluxo 0” em um relatório não é motivo de preocupação.
rperf é distribuído pela Evtech Solutions, Ltd., dba 3D-P, sob a GNU GPL versão 3, cujo texto pode ser encontrado em COPYING .
Detalhes de autoria, especificações de direitos autorais e notas de transferibilidade estão presentes no próprio código-fonte.
