Speedbump - proxy TCP con latencia variable

• Un proxy TCP escrito en Go que permite simular distintas latencias de red variables

Ejemplos básicos de uso

• Crear una nueva instancia que escuche en el puerto 2000 para hacer proxy del tráfico TCP hacia localhost:80, con una latencia base de 100ms, amplitud de onda sinusoidal de 100ms (latencia adicional máxima de 200ms, mínima de 0) y un período de 1 minuto:

  speedbump --latency=100ms --sine-amplitude=100ms --sine-period=1m --port=2000 localhost:80  
  

• O bien, al ejecutar speedbump usando la imagen de contenedor kffl/speedbump:

  docker run --net=host kffl/speedbump:latest --latency=100ms --sine-amplitude=100ms \  
    --sine-period=1m --port=2000 localhost:80  
  

• Crear una nueva instancia con una latencia base de 300ms y una latencia en forma de diente de sierra con amplitud de 200ms y período de 2 minutos, como se muestra en el gráfico de abajo:

  speedbump --latency=300ms --saw-amplitude=200ms --saw-period=2m --port=2000 localhost:80  
  

• Es posible ejecutar simultáneamente la suma de varias latencias.
• Speedbump puede usarse como biblioteca de Go mediante el paquete lib.

---

Opinión de GN⁺:

• Speedbump es una herramienta útil para simular latencias de red y puede ayudar a probar y optimizar el rendimiento de aplicaciones basadas en red.
• Al estar escrito en Go, resulta familiar para desarrolladores de Go y ofrece funciones para simular fácilmente diversos patrones de latencia.
• Es de código abierto y se distribuye bajo la licencia Apache 2.0, por lo que podría seguir mejorando con contribuciones de la comunidad.

[GN⁺]

Comentarios en Hacker News

• Estuve investigando trabajos similares para probar implementaciones de ActivityPub en distintos tamaños y condiciones de red. Aprendí a usar el comando tc para agregar latencia a una interfaz específica, y también funciona bien en contenedores Docker. Puede que ya venga instalado en muchos sistemas.
  • Comando de ejemplo: tc qdisc add dev eth0 root netem delay 100ms
• En Netflix desarrollaron una herramienta llamada "latency monkey". Detectar que un servicio aguas abajo se está volviendo lento es mucho más difícil que detectar cuando un servicio no está disponible. Esta herramienta descarta paquetes en una cierta proporción para forzar retransmisiones, lo que hace que los paquetes se retrasen o lleguen fuera de orden. Encontraron muchos problemas en el código de manejo de errores para acceso a red.
• Todo ingeniero de software que trabaje en aplicaciones de internet debería usar herramientas como esta de forma rutinaria. Se necesitan tanto QUIC como TCP, y debería poder capturarse todo UDP, incluido DNS. Estoy convencido de que el 90% de las webapps desaparecerían si sus desarrolladores no usaran entornos de cómputo de alto rendimiento.
• Muchas apps funcionan mal con conectividad de red intermitente. Los desarrolladores de apps pueden ayudar a otros probando conectividad intermitente simulada. A muchas apps les falta una función de "bandeja de salida" como la de los clientes de correo. Se plantea la pregunta de quién podría desarrollar un "mutador de casos de prueba" de toxiproxy de referencia para simular problemas de conectividad comunes en situaciones de ayuda ante desastres.
• En Mac también se puede hacer algo parecido usando herramientas integradas. Se proporcionó un ejemplo de comando para simular la velocidad de una conexión de red.
• Cuando quise simular una red lenta en Mac, encontré Network Link Conditioner. Se puede usar sin configuración de proxy ni otros ajustes, y hay que instalarlo desde las herramientas adicionales de Xcode.
• Hace mucho que no estoy activo, pero el nombre "comcast" ya dice bastante.
• Una herramienta similar que he usado en Windows es "clumsy".
• En FreeBSD también existe una función llamada "dummynet", que como parte de ipfw permite inyectar latencia, limitación de ancho de banda, tamaño de cola y pérdida de paquetes. Es la misma funcionalidad que en macOS.
• Nunca podré olvidar que en mi primer trabajo mi gerente configuró el firewall IPFW de FreeBSD para hacer más lentas las respuestas ICMP. Cada vez que alguien hacía ping, el tiempo de respuesta parecía ser el más alto. Ese gerente era un bromista.