Me gustaría simular el retraso y la pérdida de paquetes para UDP
y TCP
en Linux para medir el rendimiento de una aplicación. ¿Hay una manera simple de hacer esto?
Me gustaría simular el retraso y la pérdida de paquetes para UDP
y TCP
en Linux para medir el rendimiento de una aplicación. ¿Hay una manera simple de hacer esto?
Respuestas:
Netem aprovecha la funcionalidad ya integrada en Linux y las utilidades de espacio de usuario para simular redes. Esto es en realidad a lo que se refiere la respuesta de Mark, con un nombre diferente.
Los ejemplos en su página de inicio ya muestran cómo puede lograr lo que ha pedido:
Ejemplos
Emulando retrasos en la red de área amplia
Este es el ejemplo más simple, solo agrega una cantidad fija de retraso a todos los paquetes que salen de la Ethernet local.
# tc qdisc add dev eth0 root netem delay 100ms
Ahora, una simple prueba de ping para alojar en la red local debería mostrar un aumento de 100 milisegundos. El retraso está limitado por la resolución del reloj del núcleo (Hz). En la mayoría de los sistemas 2.4, el reloj del sistema funciona a 100 Hz, lo que permite retrasos en incrementos de 10 ms. En 2.6, el valor es un parámetro de configuración de 1000 a 100 Hz.
Los ejemplos posteriores solo cambian los parámetros sin volver a cargar qdisc
Las redes de área amplia reales muestran variabilidad, por lo que es posible agregar una variación aleatoria.
# tc qdisc change dev eth0 root netem delay 100ms 10ms
Esto hace que el retraso agregado sea de 100 ± 10 ms. La variación del retraso de la red no es puramente aleatoria, por lo que para emular también existe un valor de correlación.
# tc qdisc change dev eth0 root netem delay 100ms 10ms 25%
Esto hace que la demora agregada sea de 100 ± 10 ms con el siguiente elemento aleatorio dependiendo del 25% del último. Esto no es una correlación estadística verdadera, sino una aproximación.
Distribución diferida
Típicamente, el retraso en una red no es uniforme. Es más común usar algo como una distribución normal para describir la variación en el retraso. La disciplina netem puede tomar una tabla para especificar una distribución no uniforme.
# tc qdisc change dev eth0 root netem delay 100ms 20ms distribution normal
Las tablas reales (normal, pareto, paretonormal) se generan como parte de la compilación iproute2 y se colocan en / usr / lib / tc; Por lo tanto, es posible con cierto esfuerzo hacer su propia distribución basada en datos experimentales.
Paquete perdido
La pérdida aleatoria de paquetes se especifica en el comando 'tc' en porcentaje. El valor distinto de cero más pequeño posible es:
2 −32 = 0.0000000232%
# tc qdisc change dev eth0 root netem loss 0.1%
Esto hace que se descarte aleatoriamente una décima parte de los paquetes porcentuales (es decir, 1 de cada 1000).
También se puede agregar una correlación opcional. Esto hace que el generador de números aleatorios sea menos aleatorio y se puede usar para emular las pérdidas de ráfaga de paquetes.
# tc qdisc change dev eth0 root netem loss 0.3% 25%
Esto hará que se pierda el 0.3% de los paquetes, y cada probabilidad sucesiva depende en un cuarto del último.
Prob n = 0.25 × Prob n-1 + 0.75 × Aleatorio
Tenga en cuenta que debe usarlo tc qdisc add
si no tiene reglas para esa interfaz o tc qdisc change
si ya tiene reglas para esa interfaz. Intentar usar tc qdisc change
en una interfaz sin reglas dará el error RTNETLINK answers: No such file or directory
.
tc -p qdisc ls dev eth0
habrá una lista de reglas definidas actuales, y tc qdisc del dev eth0 root
los eliminará
Para los paquetes descartados, simplemente usaría iptables y el módulo estadístico .
iptables -A INPUT -m statistic --mode random --probability 0.01 -j DROP
Arriba caerá un paquete entrante con una probabilidad del 1%. Tenga cuidado, cualquier cosa por encima de 0.14 y la mayoría de sus conexiones tcp probablemente se bloqueará por completo.
Eche un vistazo a man iptables y busque "estadística" para obtener más información.
DROP
en cuenta que en las conexiones de salida hace que las send()
operaciones regresen de forma bastante ridícula EPERM
, en lugar de simplemente descartar paquetes (como debería).
iptables -D INPUT -m statistic --mode random --probability 0.01 -j DROP
Uno de mis colegas usa tc para hacer esto. Consulte la página del manual para obtener más información. Puede ver un ejemplo de su uso aquí .
Este tutorial sobre simulaciones físicas de redes contiene una clase de C ++ en el código de muestra para simular la latencia y la pérdida de paquetes en una conexión UDP y puede ser una guía. Vea la latencia pública y las variables packetLoss de la clase Connection que se encuentran en el archivo Connection.h del código fuente descargable .
No lo he intentado yo mismo, pero esta página tiene una lista de módulos de complemento que se ejecutan en el sistema de filtrado IP integrado de Linux 'iptables'. Uno de los módulos se llama "enésimo" y le permite configurar una regla que eliminará una velocidad configurable de los paquetes. Podría ser un buen lugar para comenzar, al menos.
Puede probar http://snad.ncsl.nist.gov/nistnet/ Es un proyecto NIST bastante antiguo (última versión 2005), pero funciona para mí.
Una herramienta de inyección de fallas de red fácil de usar es Saboteur . Puede simular:
- Partición de red total
- Servicio remoto inactivo (no escucha en el puerto esperado)
- Retrasos
- Pérdida de paquetes: tiempo de espera de conexión TCP (como suele suceder cuando dos sistemas están separados por un firewall con estado)
Una de las herramientas más utilizadas en la comunidad científica para ese fin es DummyNet . Una vez que haya instalado el ipfw
módulo del núcleo, para introducir un retraso de propagación de 50 ms entre 2 máquinas, simplemente ejecute estos comandos:
./ipfw pipe 1 config delay 50ms
./ipfw add 1000 pipe 1 ip from $IP_MACHINE_1 to $IP_MACHINE_2
Para introducir también el 50% de las pérdidas de paquetes, debe ejecutar:
./ipfw pipe 1 config plr 0.5
Aquí más detalles.