Este es el comando flowgrind que se puede ejecutar en el proveedor de alojamiento gratuito de OnWorks utilizando una de nuestras múltiples estaciones de trabajo en línea gratuitas, como Ubuntu Online, Fedora Online, emulador en línea de Windows o emulador en línea de MAC OS.
PROGRAMA:
NOMBRE
flowgrind: generador de tráfico TCP avanzado para Linux, FreeBSD y Mac OS X
SINOPSIS
moler flujo [OPCIÓN] ...
DESCRIPCIÓN
molienda de flujo es un generador de tráfico TCP avanzado para probar y comparar Linux,
Pilas de FreeBSD y Mac OS X TCP / IP. A diferencia de otras herramientas de medición del desempeño,
presenta una arquitectura distribuida, donde se miden el rendimiento y otras métricas
entre procesos arbitrarios del servidor flowgrind, demonio flowgrind flujogrindd(1).
Flowgrind mide además del buen rendimiento (throughput), el tiempo entre llegadas de la capa de aplicación
(IAT) y tiempo de ida y vuelta (RTT), blockcount y transacciones de red. A diferencia de la mayoría
herramientas de prueba de plataforma, flowgrind recopila e informa las métricas de TCP devueltas por el
Opción de socket TCP_INFO, que generalmente son internos a la pila TCP / IP. En Linux y
FreeBSD esto incluye, entre otros, la estimación del kernel del RTT de extremo a extremo, el tamaño
de la ventana de congestión de TCP (CWND) y el umbral de inicio lento (SSTHRESH).
Flowgrind tiene una arquitectura distribuida. Se divide en dos componentes: el flowgrind
demonio, flujogrindd(1), y el molienda de flujo controlador. Usando el controlador, fluye entre
Se pueden configurar dos sistemas que ejecuten el demonio flowgrind (pruebas de terceros). En regular
intervalos durante la prueba, el controlador recopila y muestra los resultados medidos de
los demonios. Puede ejecutar varios flujos a la vez con la misma o diferente configuración y
programar individualmente cada uno. La conexión de prueba y control se puede desviar opcionalmente a
diferentes interfaces.
La generación de tráfico en sí es de transferencia masiva, de velocidad limitada o sofisticada.
pruebas de solicitud / respuesta. Flowgrind usa libpcap para volcar automáticamente el tráfico para
analisis cualitativo.
CAMPUS
Son dos grupos importantes de opciones: opciones de controlador y opciones de flujo. Como el
El nombre lo sugiere, las opciones del controlador se aplican globalmente y potencialmente afectan a todos los flujos, mientras que
Las opciones específicas de flujo solo se aplican al subconjunto de flujos seleccionados usando el -F .
Los argumentos obligatorios para las opciones largas es obligatorio para las opciones cortas.
General opciones
-h, --ayuda[=LO QUE HACEMOS]
mostrar ayuda y salir. QUÉ opcional puede ser 'enchufe' para ayuda en el enchufe
opciones o ayuda para la generación de tráfico de 'tráfico'
-v, --versión
imprimir la información de la versión y salir
Joystick opciones
-c, --mostrar dos puntos=TIPO[,TIPO] ...
mostrar la columna TIPO de informe de intervalo intermedio en la salida. Valores permitidos para
Los TIPOS son: 'intervalo', 'a través', 'transac', 'iat', 'kernel' (todos se muestran por defecto),
y 'blocks', 'rtt', 'delay' (opcional)
-d, --depurar
aumentar la verbosidad de la depuración. Agregue la opción varias veces para aumentar la verbosidad
-e, --dump-prefijo=PRE
anteponer el prefijo PRE para volcar el nombre del archivo (predeterminado: "flowgrind-")
-i, --report-interval =#.#
intervalo de informe, en segundos (predeterminado: 0.05 s)
--archivo de registro[=ARCHIVO]
escribir la salida en el archivo de registro ARCHIVO (predeterminado: flowgrind-'timestamp'.log)
-m informe de rendimiento en 2 ** 20 bytes / s (predeterminado: 10 ** 6 bit / s)
-n, --flujos =#
número de flujos de prueba (predeterminado: 1)
-o sobrescribir los archivos de registro existentes (predeterminado: no)
-p no imprima valores simbólicos (como INT_MAX) en lugar de números
-q, --tranquilo
estar en silencio, no iniciar sesión en la pantalla (predeterminado: apagado)
-s, --tcp-pila=TIPO
no determina la unidad de las pilas de TCP de origen automáticamente. Forzar la unidad a TIPO, donde
TYPE es 'segmento' o 'byte'
-w escribir la salida en el archivo de registro (igual que --archivo de registro)
Flujo opciones
Todos los flujos tienen dos puntos finales, un origen y un destino. La distinción entre fuente
y los puntos finales de destino solo afectan al establecimiento de la conexión. Al iniciar un flujo,
el punto final de destino escucha en un socket y el punto final de origen se conecta a él. Para el
prueba real esto no hace ninguna diferencia, ambos puntos finales tienen exactamente las mismas capacidades.
Los datos se pueden enviar en cualquier dirección y muchos ajustes se pueden configurar individualmente para
cada punto final.
Algunas de estas opciones toman el punto final del flujo como argumento, indicado por 'x' en la opción
sintaxis. 'x' debe reemplazarse con 's' para el punto final de origen, 'd' para el
punto final de destino o 'b' para ambos puntos finales. Para especificar diferentes valores para cada
puntos finales, sepárelos por comas. Por ejemplo -W s = 8192, d = 4096 establece el anunciado
ventana a 8192 en el origen y 4096 en el destino.
-A x utilizar el tamaño de respuesta mínimo necesario para el cálculo de RTT
(igual que -G s = p, C, 40)
-B x=# establecer el búfer de envío solicitado, en bytes
-C x Detenga el flujo si experimenta congestión local.
-D x=DSCP
Valor DSCP para byte de encabezado IP de tipo de servicio (TOS)
-E enumerar bytes en la carga útil en lugar de enviar ceros
-F #[,#] ...
Las opciones de flujo que siguen a esta opción se aplican solo a los ID de flujo dados. Útil en
combinación con -n para establecer opciones específicas para ciertos flujos. Comienza la numeración
con 0, entonces -F 1 se refiere al segundo flujo. Con -1 se puede referir todo el flujo
-G x=(q|p|g) :(C|U|E|N|L|P|W):#1:[#2]
activar la generación de tráfico estocástico y configurar los parámetros de acuerdo con el utilizado
distribución. Para obtener información adicional, consulte la sección 'Opción de generación de tráfico'
-H x=HOST[/CONTROL[:PORT]]
prueba desde / hacia HOST. El argumento opcional es la dirección y el puerto para CONTROL
conexión al mismo host. Se supone que un punto final que no se especifica es
localhost
-J # usar semilla aleatoria # (por defecto: leer / Dev / urandom)
-I habilitar el cálculo de retardo unidireccional (sin sincronización de reloj)
-L llame a connect () en el socket de prueba inmediatamente antes de comenzar a enviar datos (tarde
conectar). Si no se especifica, la conexión de prueba se establece en la preparación
fase antes de que comience la prueba
-M x volcar tráfico usando libpcap. flujogrindd(1) debe ejecutarse como root
-N shutdown () en cada dirección del enchufe después del flujo de prueba
-O x=OPT
establezca la opción de enchufe OPT en el enchufe de prueba. Para obtener información adicional, consulte la sección
'Opciones de socket'
-P x no iterar a través de select () para continuar enviando en caso de que el tamaño del bloque no lo hiciera
suficiente para llenar la cola de envío (agresivo)
-Q resumir solamente, no se calculan informes de intervalos intermedios (silencioso)
-R x=#.#(z|k|M|G)(b|B)
enviar a una velocidad especificada por segundo, donde: z = 2 ** 0, k = 2 ** 10, M = 2 ** 20, G =
2 ** 30 y b = bits / s (predeterminado), B = bytes / s
-S x=# establecer el tamaño del bloque (mensaje), en bytes (igual que -G s = q, C, #)
-T x=#.#
establecer la duración del flujo, en segundos (predeterminado: s = 10, d = 0)
-U # establecer el tamaño del búfer de la aplicación, en bytes (predeterminado: 8192) trunca los valores si se usa con
generación de tráfico estocástico
-W x=# establecer el búfer del receptor solicitado (ventana anunciada), en bytes
-Y x=#.#
establecer la demora inicial antes de que el host comience a enviar, en segundos
TRÁFICO GENERACION OPCIÓN
Vía opción -G flowgrind admite la generación de tráfico estocástico, lo que permite realizar
además de las transferencias de datos masivas normales, también avanzadas transferencias de datos de solicitud-respuesta y con velocidad limitada.
La opción de generación de tráfico estocástico -G toma el punto final del flujo como argumento, denotado
por 'x' en la sintaxis de la opción. 'x' debe reemplazarse con 's' para la fuente
punto final, 'd' para el punto final de destino o 'b' para ambos puntos finales. Sin embargo, tenga en cuenta
que la generación de tráfico bidireccional puede conducir a resultados inesperados. Para especificar diferentes
valores para cada punto final, sepárelos por comas.
-G x=(q|p|g) :(C|U|E|N|L|P|W):#1:[#2]
Parámetro de flujo:
q tamaño de la solicitud (en bytes)
p tamaño de respuesta (en bytes)
g solicitar espacio entre paquetes (en segundos)
Distribuciones:
C constante#1: valor, #2: no utilizado)
U uniforme#1: mín., #2: máx.)
E exponencial#1: lamba - de por vida, #2: no utilizado)
N normal (#1: mu - valor medio, #2: sigma_square - varianza)
L lognormal#1: zeta - significa, #2: sigma - desarrollo estándar)
P pareto#1: k - forma, #2: x_min - escala)
W weibull#1: lambda - escala, #2: k - forma)
Las distribuciones avanzadas como weibull solo están disponibles si se compila flowgrind
con soporte libgsl.
-U # especificar un límite para los valores calculados para los tamaños de solicitud y respuesta, necesario
porque los valores distribuidos avanzados son ilimitados, pero necesitamos saber el
tamaño de búfer (no es necesario para valores constantes o distribución uniforme). Valores
fuera de los límites se recalculan hasta que se obtiene un resultado válido, pero como máximo 10
veces (entonces se usa el valor límite)
TOMA OPCIÓN
Flowgrind permite configurar las siguientes opciones de enchufes estándar y no estándar a través de la opción
-O.
Todas las opciones de socket toman el punto final del flujo como argumento, indicado por 'x' en la opción
sintaxis. 'x' debe reemplazarse con 's' para el punto final de origen, 'd' para el
punto final de destino o 'b' para ambos puntos finales. Para especificar diferentes valores para cada
puntos finales, sepárelos por comas. Además, es posible pasar repetidamente el mismo
endpoint para especificar múltiples opciones de socket.
Estándar enchufe opciones
-O x= TCP_CONGESTION =ALG
establecer el algoritmo de control de congestión ALG en el enchufe de prueba
-O x= TCP_CORK
establecer TCP_CORK en el socket de prueba
-O x= TCP_NODELAY
deshabilitar el algoritmo nagle en el socket de prueba
-O x= SO_DEBUG
establecer SO_DEBUG en el socket de prueba
-O x= IP_MTU_DISCOVER
establecer IP_MTU_DISCOVER en el socket de prueba si aún no está habilitado por defecto del sistema
-O x= ROUTE_RECORD
establecer ROUTE_RECORD en el enchufe de prueba
No estándar enchufe opciones
-O x= TCP_MTCP
establecer TCP_MTCP (15) en el socket de prueba
-O x= TCP_ELCN
establecer TCP_ELCN (20) en el socket de prueba
-O x= TCP_LCD
establecer TCP_LCD (21) en el socket de prueba
EJEMPLOS
molienda de flujo
probar el rendimiento de localhost IPv4 TCP con la configuración predeterminada, igual que flowgrind -H
b = 127.0.0.1 -T s = 10, d = 0. El demonio flowgrind debe ejecutarse en localhost
molienda de flujo -H b = :: 1 / 127.0.0.1
igual que el anterior, pero probando el rendimiento de TCP IPv6 localhost con la configuración predeterminada
molienda de flujo -H s = host1, d = host2
transferencia TCP masiva entre host1 y host2. Host1 actúa como fuente, host2 como
punto final de destino. Ambos extremos deben ejecutar el demonio flowgrind. los
Se utilizan las opciones de flujo predeterminadas, con una duración de flujo de 10 segundos y un flujo de datos.
de host1 a host2
molienda de flujo -H s = host1, d = host2 -T s = 0, d = 10
igual que el anterior, pero en su lugar con un flujo de envío de datos durante 10 segundos desde host2 a
host1
molienda de flujo -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 dos flujos paralelos, el primer flujo entre 192.168.0.1 y 192.168.0.69, segundo
flujo entre 10.0.0.1 a 10.0.0.2
molienda de flujo -p -H s = 10.0.0.100 / 192.168.1.100, d = 10.0.0.101 / 192.168.1.101 -A s
configurar un flujo entre 10.0.0.100 y 10.0.0.101 y usar direcciones IP 192.168.1.x
para control de tráfico. Activar la respuesta mínima para el cálculo de RTT
molienda de flujo -i 0.001 -T s = 1 | egrep ^S | parcela gnuplot -persistir -e 'trama "-" usando 3:5 líneas
título "Rendimiento" '
configurar un dispositivo de flujo sobre loopback y trazar los datos del remitente con la ayuda
de gnuplot
molienda de flujo -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: use un tamaño de solicitud constante de 400 bytes
-G s = p, N, 2000,50: use un tamaño de respuesta distribuido normal con una media de 2000 bytes y
varianza 50
-G s = g, U, 0.005,0.01: use un espacio entre paquetes distribuido uniformemente con un mínimo de 0.005 sy
y máximo 10ms
-U 32000: tamaño de bloque truncado a 32 kbytes (necesario para la distribución normal)
TRÁFICO ESCENARIOS
Los siguientes ejemplos demuestran cómo la capacidad de generación de tráfico de flowgrind puede ser
usó. Estos han sido incorporados en diferentes pruebas de flowgrind y han sido probados
significativo. Sin embargo, como el tráfico de Internet es diverso, no hay garantía de que sean
apropiado en cada situación.
SOLICITUD Respuesta Estilo (HTTP)
Este escenario se basa en el trabajo en
http://www.3gpp2.org/Public_html/specs/C.R1002-0_v1.0_041221.pdf.
molienda de flujo -M s -G s = q, C, 350 -G s = p, L, 9055,115.17 -U 100000
-M s: volcar tráfico en el lado del remitente
-G s = q, C, 350: usa solicitudes constantes de tamaño 350 bytes
-G s = p, L, 9055,115: use distribución logarítmica normal con media 9055 y varianza 115 para
tamaño de respuesta
-U 100000: Respuesta truncada a 100 kbytes
Para este escenario, recomendamos enfocarnos en RTT (los valores más bajos son mejores) y Network
Transacciones / s como métrica (los valores más altos son mejores).
Formulario Sesión (Telnet)
Este escenario emula una sesión de telnet.
molienda de flujo -G s = q, U, 40,10000 XNUMX XNUMX -G s = q, U, 40,10000 XNUMX XNUMX -O b = TCP_NODELAY
-G s = q, U, 40,10000 -G s = q, U, 40,10000: use solicitud y respuesta distribuidas uniformemente
tamaño entre 40B y 10kB
-O b = TCP_NODELAY: establece las opciones de socket TCP_NODELAY como las usan las aplicaciones telnet
Para este escenario, RTT (más bajo es mejor) y Transacciones de red son métricas útiles
(más alto es mejor).
Rate Limitada (Transmisión Medios de comunicación)
Este escenario emula una transferencia de flujo de video con una tasa de bits de 800 kbit / s.
molienda de flujo -G s = q, C, 800 -G s = g, N, 0.008,0.001
Utilice una brecha entre paquetes distribuida normal con una media de 0.008 y una pequeña variación
(0.001). En conjunto con el tamaño de la solicitud 800 bytes, una tasa de bits promedio de aproximadamente 800
se alcanza kbit / s. La varianza se agrega para emular una tasa de bits variable como si fuera
utilizado en los códecs de vídeo actuales.
Para este escenario, el IAT (más bajo es mejor) y el rendimiento mínimo (más alto es mejor) son
métricas interesantes.
SALIDA COLUMNAS
Flujo / punto final Identificadores
# punto final de flujo, ya sea 'S' para origen o 'D' para destino
ID identificador de flujo numérico
comenzar y final
límites del intervalo de medición en segundos. El tiempo que se muestra es el transcurrido
tiempo desde la recepción del mensaje RPC para iniciar la prueba desde el punto de daemons de
view
Aplicación . métrica
a
transmitir un buen rendimiento del punto final de flujo durante este intervalo de medición,
medido en Mbit / s (predeterminado) o MB / s (-m)
transacción
número de bloques de respuesta recibidos con éxito por segundo (lo llamamos red
transacciones / s)
requ / resp
número de bloque de solicitud y respuesta enviado durante este intervalo de medición (columna
deshabilitado por defecto)
IAT bloquear el tiempo entre llegadas (IAT). Junto con el mínimo y máximo el
Se muestra la media aritmética para ese intervalo de medición específico. Si no hay bloque
recibido durante el intervalo de informe, se muestra 'inf'.
DLY y RTT
Retardo de bloque unidireccional y bidireccional, respectivamente, la latencia del bloque y el viaje de ida y vuelta del bloque
tiempo (RTT). Para ambos retrasos, los valores mínimos y máximos encontrados en ese
el intervalo de medición se muestra junto con la media aritmética. Si no hay bloque,
respectivamente, el acuse de recibo del bloque llega durante ese intervalo de informe, 'inf' es
desplegado. Tanto el retardo de bloqueo de 1 vía como el de 2 vías están desactivados de forma predeterminada (consulte
opción -I y -A).
Núcleo métrica (TCP_INFO)
Todas las siguientes métricas específicas de TCP se obtienen del kernel a través de TCP_INFO
opción de enchufe en el final de cada intervalo de informe. La frecuencia de muestreo se puede cambiar mediante
opción -i.
Cwnd (tcpi_cwnd)
tamaño de la ventana de congestión TCP (CWND) en número de segmentos (Linux) o bytes
(BSD libre)
algo (tcpi_snd_sshtresh)
tamaño del umbral de inicio lento en número de segmentos (Linux) o bytes (FreeBSD)
uack (tcpi_unacked)
número de segmentos actualmente no reconocidos, es decir, número de segmentos en vuelo
(FlightSize) (solo Linux)
saco (tcpi_sacados)
número de segmentos reconocidos selectivamente (solo Linux)
perdido (tcpi_perdido)
número de segmentos que se supone perdidos (solo Linux)
recuperar (tcpi_retrans)
número de segmentos retransmitidos no reconocidos (solo Linux)
salvo (tcpi_retransmite)
número de retransmisiones activadas por un tiempo de espera de retransmisión (RTO) (solo Linux)
fack (tcpi_fackets)
número de segmentos entre SND.UNA y el más alto reconocido selectivamente
número de secuencia (SND.FACK) (solo Linux)
reor (tcpi_reordering)
métrica de reordenamiento de segmentos. El kernel de Linux puede detectar y hacer frente al reordenamiento
sin pérdida significativa de rendimiento si la distancia que se desplaza un segmento no
no exceda la métrica de reordenamiento (solo Linux)
rtt (tcpi_rtt) y rtvar (tcpi_rttvar)
Tiempo de ida y vuelta del TCP y su varianza expresado en ms
rto (tcpi_rto)
el tiempo de espera de retransmisión dado en ms
bkof (tcpi_backoff)
número de retrocesos de RTO (solo Linux)
ca estado (tcpi_ca_estado)
estado interno de la máquina de estado de control de congestión TCP como se implementó en el
Kernel de Linux. Puede ser uno de habiertos, trastorno, cwr, recuperación or de (Solo Linux)
Abierto es el estado normal. Indica que no hay acuse de recibo duplicado (ACK).
recibido y ningún segmento se considera perdido
Trastorno
se ingresa al recibir el primer ACK duplicado consecutivo o
reconocimiento selectivo (SACK)
CWR se ingresa cuando una notificación de Notificación de congestión explícita (ECN)
Esta recibido
Recuperación
se ingresa cuando se ingresan tres ACK duplicados o un número equivalente de SACK
recibió. En este estado procedimientos de control de congestión y recuperación de pérdidas como
Se ejecutan la retransmisión rápida y la recuperación rápida (RFC 5861)
Pérdida se ingresa si el RTO expira. Nuevamente control de congestión y recuperación de pérdidas.
se ejecutan los procedimientos
SMS y pmtu
tamaño máximo del segmento del remitente y unidad de transmisión máxima de la ruta en bytes
Interno molienda de flujo estado (solamente facilita in depurar construye)
estado estado del flujo dentro de flowgrind con fines de diagnóstico. Es una tupla de dos
valores, el primero para enviar y el segundo para recibir. Idealmente, los estados de
Tanto el punto final de origen como el de destino de un flujo deben ser simétricos, pero dado que
no están sincronizados, es posible que no cambien al mismo tiempo. Los posibles valores
son:
c Dirección completada envío / recepción
d Esperando el retraso inicial
f Estado de avería
l Estado activo, aún no se ha transmitido ni recibido nada
n Actividad normal, algunos datos se transmitieron o recibieron
o El flujo tiene una duración cero en esa dirección, no se intercambiarán datos
AUTORES
Flowgrind fue iniciado originalmente por Daniel Schaffrath. La medida distribuida
La arquitectura y la generación avanzada de tráfico fueron añadidas más tarde por Tim Kosse y
Christian Samsel. Actualmente, flowgrind se desarrolla y mantiene Arnd Hannemann y
Alejandro Zimmerman.
Use flowgrind en línea usando los servicios de onworks.net
