flowgrind - online na nuvem

PROGRAMA:

NOME

flowgrind - gerador de tráfego TCP avançado para Linux, FreeBSD e Mac OS X

SINOPSE

moagem de fluxo [OPÇÃO] ...

DESCRIÇÃO

triturador é um gerador de tráfego TCP avançado para teste e benchmarking do Linux,
FreeBSD e pilhas TCP / IP do Mac OS X. Em contraste com outras ferramentas de medição de desempenho,
apresenta uma arquitetura distribuída, onde o rendimento e outras métricas são medidos
entre processos arbitrários do servidor flowgrind, daemon flowgrind fluxogrindd(1).

Flowgrind mede além do goodput (throughput), o tempo entre chegadas da camada de aplicação
(IAT) e tempo de ida e volta (RTT), contagem de blocos e transações / s de rede. Ao contrário da maioria dos
ferramentas de teste de plataforma, flowgrind coleta e relata as métricas de TCP retornadas pelo
Opção de soquete TCP_INFO, que geralmente são internos à pilha TCP / IP. No Linux e
FreeBSD inclui, entre outros, a estimativa do kernel do RTT de ponta a ponta, o tamanho
da janela de congestionamento TCP (CWND) e limite de início lento (SSTHRESH).

Flowgrind possui uma arquitetura distribuída. É dividido em dois componentes: o flowgrind
demônio, fluxogrindd(1), e o triturador controlador. Usando o controlador, flui entre
quaisquer dois sistemas executando o daemon flowgrind podem ser configurados (testes de terceiros). Em regular
intervalos durante o teste, o controlador coleta e exibe os resultados medidos de
os demônios. Ele pode executar vários fluxos de uma vez com as mesmas configurações ou configurações diferentes e
agende individualmente cada um. A conexão de teste e controle pode, opcionalmente, ser desviada para
interfaces diferentes.

A geração de tráfego em si é transferência em massa, taxa limitada ou sofisticada
testes de solicitação / resposta. Flowgrind usa libpcap para despejar automaticamente o tráfego para
análise qualitativa.

OPÇÕES

Eles são dois grupos importantes de opções: opções de controlador e opções de fluxo. Como o
o nome sugere, as opções do controlador se aplicam globalmente e potencialmente afetam todos os fluxos, enquanto
opções específicas de fluxo se aplicam apenas ao subconjunto de fluxos selecionados usando o -F opção.

Os argumentos obrigatórios para as opções longas é obrigatória para curtas opções também.

Geral opções
-h, --Socorro[=O QUE]
exibir ajuda e sair. Opcional O QUE pode ser 'soquete' para ajuda no soquete
opções ou ajuda de geração de tráfego de 'tráfego'

-v, --versão
imprimir informações da versão e sair

Responsável pelo Tratamento opções
-c, --mostrar dois pontos=TIPO[,TIPO] ...
exibe a coluna TYPE do relatório de intervalo intermediário na saída. Valores permitidos para
TYPE are: 'interval', 'through', 'transac', 'iat', 'kernel' (todos mostram por padrão),
e 'bloqueia', 'rtt', 'atraso' (opcional)

-d, --depurar
aumentar o detalhamento de depuração. Adicione a opção várias vezes para aumentar o detalhamento

-e, - dump-prefix=ARTE
prefixo prefixo PRE para despejar o nome do arquivo (padrão: "flowgrind-")

-i, --report-interval =#.#
intervalo de relatório, em segundos (padrão: 0.05s)

--arquivo de log[=ARQUIVO]
gravar a saída no arquivo de log FILE (padrão: flowgrind-'timestamp'.log)

-m taxa de transferência do relatório em 2 ** 20 bytes / s (padrão: 10 ** 6 bits / s)

-n, --flows =#
número de fluxos de teste (padrão: 1)

-o sobrescrever arquivos de registro existentes (padrão: não)

-p não imprima valores simbólicos (como INT_MAX) em vez de números

-q, --quieto
fique quieto, não faça login na tela (padrão: desligado)

-s, --tcp-stack=TIPO
não determine a unidade de pilhas TCP de origem automaticamente. Força a unidade para TYPE, onde
TYPE é 'segmento' ou 'byte'

-w escrever a saída para o arquivo de log (o mesmo que --arquivo de log)

Fluxo opções
Todos os fluxos têm dois pontos finais, uma origem e um destino. A distinção entre a fonte
e os pontos de extremidade de destino afetam apenas o estabelecimento da conexão. Ao iniciar um fluxo, o
o ponto de extremidade de destino escuta em um soquete e o ponto de extremidade de origem se conecta a ele. Para o
teste real, isso não faz diferença, ambos os terminais têm exatamente os mesmos recursos.
Os dados podem ser enviados em qualquer direção e muitas configurações podem ser definidas individualmente para
cada ponto de extremidade.

Algumas dessas opções levam o ponto final do fluxo como argumento, denotado por 'x' na opção
sintaxe. 'x' deve ser substituído por 's' para o ponto de extremidade de origem, 'd' para o
endpoint de destino ou 'b' para ambos os endpoints. Para especificar valores diferentes para cada
terminais, separe-os por vírgula. Por exemplo -W s = 8192, d = 4096 define o anunciado
janela para 8192 na origem e 4096 no destino.

-A x use o tamanho mínimo de resposta necessário para o cálculo do RTT
(igual a -G s = p, C, 40)

-B x=# definir o buffer de envio solicitado, em bytes

-C x pare o fluxo se estiver enfrentando congestionamento local

-D x=DSCP
Valor DSCP para byte de cabeçalho IP de tipo de serviço (TOS)

-E enumere bytes na carga útil em vez de enviar zeros

-F #[,#] ...
as opções de fluxo após esta opção aplicam-se apenas aos IDs de fluxo fornecidos. Útil em
combinação com -n para definir opções específicas para determinados fluxos. A numeração começa
com 0, então -F 1 refere-se ao segundo fluxo. Com -1 todo o fluxo pode ser referenciado

-G x=(q|p|g) :(C|U|E|N|L|P|W):#1:[#2]
ativar geração de tráfego estocástico e definir parâmetros de acordo com o
distribuição. Para obter informações adicionais, consulte a seção 'Opção de Geração de Tráfego'

-H x=HOST[/CONTROLE[:PORT]]
teste de / para HOST. O argumento opcional é o endereço e a porta para o CONTROLE
conexão com o mesmo host. Um endpoint que não é especificado é considerado
localhost

-J # use semente aleatória # (padrão: ler / Dev / urandom)

-I habilitar cálculo de atraso unilateral (sem sincronização de relógio)

-L chame connect () no soquete de teste imediatamente antes de começar a enviar dados (tarde
conectar). Se não for especificado, a conexão de teste é estabelecida na preparação
fase antes do início do teste

-M x despejar o tráfego usando libpcap. fluxogrindd(1) deve ser executado como root

-N desligar () cada direção do soquete após o fluxo de teste

-O x=OPT
definir a opção de soquete OPT no soquete de teste. Para obter informações adicionais, consulte a seção
'Opções de Soquete'

-P x não itere através de select () para continuar a enviar, caso o tamanho do bloco não
é suficiente para preencher a fila de envio (pushy)

-Q resumir apenas, nenhum relatório de intervalo intermediário é calculado (silencioso)

-R x=#.#(z|k|M|G)(b|B)
enviar na taxa especificada por segundo, onde: z = 2 ** 0, k = 2 ** 10, M = 2 ** 20, G =
2 ** 30 e b = bits / s (padrão), B = bytes / s

-S x=# definir o tamanho do bloco (mensagem), em bytes (igual a -G s = q, C, #)

-T x=#.#
definir a duração do fluxo, em segundos (padrão: s = 10, d = 0)

-U # definir o tamanho do buffer do aplicativo, em bytes (padrão: 8192) trunca os valores se usado com
geração de tráfego estocástico

-W x=# definir o buffer do receptor solicitado (janela anunciada), em bytes

-Y x=#.#
definir o atraso inicial antes que o host comece a enviar, em segundos

TRÁFEGO GERAÇÃO OPÇÃO

Por opção -G flowgrind suporta geração de tráfego estocástico, o que permite conduzir
além do volume normal, também transferências de dados com limite de taxa avançada e de solicitação-resposta.

A opção de geração de tráfego estocástico -G toma o ponto final do fluxo como argumento, denotado
por 'x' na sintaxe da opção. 'x' deve ser substituído por 's' para a fonte
endpoint, 'd' para o endpoint de destino ou 'b' para ambos os endpoints. No entanto, observe
que a geração de tráfego bidirecional pode levar a resultados inesperados. Para especificar diferente
valores para cada terminal, separe-os por vírgula.

-G x=(q|p|g) :(C|U|E|N|L|P|W):#1:[#2]

Parâmetro de fluxo:

q tamanho da solicitação (em bytes)

p tamanho da resposta (em bytes)

g solicitar intervalo entre pacotes (em segundos)

Distribuições:

C constante (#1: valor, #2: não usado)

U uniforme (#1: min, #2: máx.)

E exponencial (#1: lamba - vitalício, #2: não usado)

N normal (#1: mu - valor médio, #2: sigma_square - variância)

L log normal (#1: zeta - quer dizer, #2: sigma - desenvolvimento padrão)

P Pareto (#1: k - forma, #2: x_min - escala)

W weibull (#1: lambda - escala, #2: k - forma)

Distribuições avançadas como weibull só estão disponíveis se o flowgrind for compilado
com suporte a libgsl.

-U # especifique um limite para os valores calculados para tamanhos de solicitação e resposta, necessários
porque os valores distribuídos avançados são ilimitados, mas precisamos saber o
buffersize (não é necessário para valores constantes ou distribuição uniforme). Valores
fora dos limites são recalculados até que um resultado válido ocorra, mas no máximo 10
vezes (então o valor limite é usado)

SOQUETE OPÇÃO

O Flowgrind permite definir as seguintes opções de soquete padrão e não padrão via opção
-O.

Todas as opções de soquete levam o ponto final do fluxo como argumento, denotado por 'x' na opção
sintaxe. 'x' deve ser substituído por 's' para o ponto de extremidade de origem, 'd' para o
endpoint de destino ou 'b' para ambos os endpoints. Para especificar valores diferentes para cada
terminais, separe-os por vírgula. Além disso, é possível passar repetidamente o mesmo
endpoint para especificar várias opções de soquete.

Padrão soquete opções
-O x= TCP_CONGESTION =ALG
definir algoritmo de controle de congestionamento ALG no soquete de teste

-O x= TCP_CORK
definir TCP_CORK no soquete de teste

-O x= TCP_NODELAY
desabilitar algoritmo nagle no soquete de teste

-O x= SO_DEBUG
definir SO_DEBUG no soquete de teste

-O x= IP_MTU_DISCOVER
definir IP_MTU_DISCOVER no soquete de teste se ainda não estiver habilitado por padrão do sistema

-O x= ROUTE_RECORD
definir ROUTE_RECORD no soquete de teste

Não-padrão soquete opções
-O x= TCP_MTCP
definir TCP_MTCP (15) no soquete de teste

-O x= TCP_ELCN
definir TCP_ELCN (20) no soquete de teste

-O x= TCP_LCD
definir TCP_LCD (21) no soquete de teste

EXEMPLOS

triturador
testando o desempenho de TCP IPv4 localhost com configurações padrão, o mesmo que flowgrind -H
b = 127.0.0.1 -Ts = 10, d = 0. O daemon flowgrind precisa ser executado no localhost

triturador -H b = :: 1 / 127.0.0.1
o mesmo que acima, mas testando o desempenho do TCP IPv6 do localhost com as configurações padrão

triturador -H s = host1, d = host2
transferência TCP em massa entre host1 e host2. Host1 atua como fonte, host2 como
endpoint de destino. Ambos os terminais precisam ser executados no daemon flowgrind. o
opções de fluxo padrão são usadas, com uma duração de fluxo de 10 segundos e um fluxo de dados
de host1 a host2

triturador -H s = host1, d = host2 -T s = 0, d = 10
igual ao anterior, mas em vez disso com um fluxo enviando dados por 10 segundos do host2 para
host1

triturador -n 2 -F 0 -H s = 192.168.0.1, d = 192.168.0.69 -F 1 -H s = 10.0.0.1, d = 10.0.0.2
configurar dois fluxos paralelos, primeiro fluxo entre 192.168.0.1 e 192.168.0.69, segundo
fluxo entre 10.0.0.1 a 10.0.0.2

triturador -p -H s = 10.0.0.100 / 192.168.1.100, d = 10.0.0.101 / 192.168.1.101 -A s
configurar um fluxo entre 10.0.0.100 e 10.0.0.101 e usar endereços IP 192.168.1.x
para controlar o tráfego. Ative a resposta mínima para o cálculo do RTT

triturador -i 0.001 -T s = 1 | egrep ^S | gnuplot -persistir -e 'enredo "-" utilização 3:5 com linhas
título "Taxa de transferência" '
configurar um dispositivo de fluxo sobre loopback e traçar os dados do remetente com a ajuda
de gnuplot

triturador -G s = q, C, 400 -G s = p, N, 2000,50 -G s = g, U, 0.005,0.01 -U 32000
-G s = q, C, 400: usa tamanho de solicitação constante de 400 bytes
-G s = p, N, 2000,50: use o tamanho de resposta distribuída normal com média de 2000 bytes e
variância 50
-G s = g, U, 0.005,0.01: usar lacuna entre pacotes uniformemente distribuída com mínimo 0.005s e
e no máximo 10ms
-U 32000: trunca tamanhos de bloco em 32 kbytes (necessário para distribuição normal)

TRÁFEGO CENÁRIOS

Os exemplos a seguir demonstram como a capacidade de geração de tráfego do flowgrind pode ser
usado. Estes foram incorporados em diferentes testes para flowgrind e foram comprovados
significativo. No entanto, como o tráfego da Internet é diverso, não há garantia de que sejam
apropriado em cada situação.

SOLICITAÇÃO Resposta Style (HTTP)
Este cenário é baseado no trabalho em
http://www.3gpp2.org/Public_html/specs/C.R1002-0_v1.0_041221.pdf.

triturador -M s -G s = q, C, 350 -G s = p, L, 9055,115.17 -U 100000
-M s: despeja o tráfego no lado do remetente
-G s = q, C, 350: usa solicitações constantes de tamanho de 350 bytes
-G s = p, L, 9055,115: use distribuição lognormal com média 9055 e variância 115 para
tamanho da resposta
-U 100000: Resposta truncada em 100 kbytes

Para este cenário, recomendamos focar no RTT (valores mais baixos são melhores) e na rede
Transações / s como métricas (valores mais altos são melhores).

interativo Número da (Telnet)
Este cenário emula uma sessão telnet.

triturador -G s = q, U, 40,10000 -G s = q, U, 40,10000 -O b = TCP_NODELAY
-G s = q, U, 40,10000 -G s = q, U, 40,10000: usar solicitação e resposta distribuídas uniformes
tamanho entre 40B e 10kB
-O b = TCP_NODELAY: definir opções de soquete TCP_NODELAY como usado por aplicativos telnet

Para este cenário, RTT (quanto menor, melhor) e transações / s de rede são métricas úteis
(mais alto é melhor).

Taxa Limitado (Transmissão Média)
Este cenário emula uma transferência de fluxo de vídeo com uma taxa de bits de 800 kbit / s.

triturador -G s = q, C, 800 -G s = g, N, 0.008,0.001
Use o intervalo normal distribuído entre pacotes com média 0.008 e uma pequena variância
(0.001). Em conjunto com o tamanho da solicitação de 800 bytes, uma taxa de bits média de aproximadamente 800
kbit / s é alcançado. A variação é adicionada para emular uma taxa de bits variável como se fosse
usado nos codecs de vídeo de hoje.

Para este cenário, o IAT (quanto menor é melhor) e o rendimento mínimo (quanto maior, melhor) são
métricas interessantes.

SAÍDA COLUNAS

Fluxo / ponto final Identificadores
# ponto final de fluxo, 'S' para origem ou 'D' para destino

ID identificador numérico de fluxo

começar e final
limites do intervalo de medição em segundos. O tempo mostrado é o decorrido
tempo desde o recebimento da mensagem RPC para iniciar o teste do ponto de daemons de
view

Aplicação camada métrica
NFT`s
transmitir goodput do ponto final de fluxo durante este intervalo de medição,
medido em Mbit / s (padrão) ou MB / s (-m)

transação
número de blocos de resposta recebidos com sucesso por segundo (nós o chamamos de rede
transações / s)

requ / resp
número de solicitações e blocos de resposta enviados durante este intervalo de medição (coluna
desabilitado por padrão)

IAT bloco de tempo entre chegadas (IAT). Juntamente com o mínimo e máximo, o
a média aritmética para esse intervalo de medição específico é exibida. Se nenhum bloco é
recebido durante o intervalo de relatório, 'inf' é exibido.

ATRASO e RTT
Atraso de bloco unilateral e bidirecional, respectivamente, a latência do bloco e a viagem de ida e volta do bloco
tempo (RTT). Para ambos os atrasos, os valores mínimo e máximo encontrados naquele
intervalo de medição são exibidos junto com a média aritmética. Se nenhum bloco,
respectivamente, a confirmação do bloco é recebida durante esse intervalo de relatório, 'inf' é
exibido. Ambos, o retardo de bloqueio unilateral e bidirecional são desabilitados por padrão (consulte
opção -I e -A).

Núcleo métrica (TCP_INFO)
Todas as seguintes métricas específicas de TCP são obtidas do kernel por meio do TCP_INFO
opção de soquete no final de cada intervalo de relatório. A taxa de amostragem pode ser alterada via
opção -i.

cwnd (tcpi_cwnd)
tamanho da janela de congestionamento de TCP (CWND) em número de segmentos (Linux) ou bytes
(FreeBSD)

sst (tcpi_snd_sshtresh)
tamanho do limite de início lento em número de segmentos (Linux) ou bytes (FreeBSD)

uau (tcpi_unacked)
número de segmentos atualmente não reconhecidos, ou seja, número de segmentos em voo
(FlightSize) (somente Linux)

saco (tcpi_sack)
número de segmentos reconhecidos seletivamente (somente Linux)

perdido (tcpi_lost)
número de segmentos considerados perdidos (somente Linux)

retr (tcpi_retrans)
número de segmentos retransmitidos não confirmados (somente Linux)

tret (tcpi_retransmits)
número de retransmissões disparado por um tempo limite de retransmissão (RTO) (somente Linux)

maluco (tcpi_fackets)
número de segmentos entre SND.UNA e o mais alto reconhecido seletivamente
número de sequência (SND.FACK) (somente Linux)

reor (tcpi_reordenação)
métrica de reordenamento de segmento. O kernel do Linux pode detectar e lidar com a reordenação
sem perda significativa de desempenho se a distância em que um segmento é deslocado
não exceda a métrica de reordenamento (somente Linux)

rtt (tcpi_rtt) e rtvar (tcpi_rttvar)
Tempo de ida e volta do TCP e sua variação dada em ms

rto (tcpi_rto)
o tempo limite de retransmissão dado em ms

bkof (tcpi_backoff)
número de backoffs RTO (somente Linux)

ca estado (tcpi_ca_state)
estado interno da máquina de estado de controle de congestionamento TCP, conforme implementado no
Kernel do Linux. Pode ser um de aberto, desordem, cwr, recuperação or fora (Apenas Linux)

Abra é o estado normal. Isso indica que nenhuma confirmação duplicada (ACK) é
recebido e nenhum segmento é considerado perdido

Desordem
é inserido na recepção do primeiro ACK duplicado consecutivo ou
reconhecimento seletivo (SACK)

CWR é inserido quando uma notificação de Notificação Explícita de Congestionamento (ECN)
é recebido

Recuperacao
é inserido quando três ACKs duplicados ou um número equivalente de SACKs são
recebido. Neste estado de controle de congestionamento e procedimentos de recuperação de perdas, como
Retransmissão rápida e recuperação rápida (RFC 5861) são executados

Perda é inserido se o RTO expirar. Mais uma vez, controle de congestionamento e recuperação de perdas
procedimentos são executados

sms e pmtu
tamanho máximo do segmento do remetente e unidade máxima de transmissão do caminho em bytes

Interno triturador estado (só habilitado in depurar constrói)
estado estado do fluxo dentro do flowgrind para fins de diagnóstico. É uma tupla de dois
valores, o primeiro para envio e o segundo para recebimento. Idealmente, os estados de
ambos os pontos de extremidade de origem e destino de um fluxo devem ser simétricos, mas desde
eles não estão sincronizados, eles não podem ser alterados ao mesmo tempo. Os valores possíveis
são:

c Direção concluída envio / recebimento

d Esperando pelo atraso inicial

f Estado de falha

l Estado ativo, nada ainda transmitido ou recebido

n Atividade normal, alguns dados foram transmitidos ou recebidos

o O fluxo tem duração zero nessa direção, nenhum dado será trocado

AUTORES

Flowgrind foi originalmente iniciado por Daniel Schaffrath. A medição distribuída
arquitetura e geração avançada de tráfego foram posteriormente adicionadas por Tim Kosse e
Christian Samsel. Atualmente, flowgrind é desenvolvido e mantido por Arnd Hannemann e
Alexandre Zimmermann.

Use flowgrind online usando serviços onworks.net