En el desarrollo de software, garantizar la robustez de las aplicaciones frente a fluctuaciones o degradaciones en la conectividad de red es un desafío constante. Muchos errores críticos solo se manifiestan cuando los usuarios operan bajo condiciones de red adversas, las cuales son difíciles de replicar en entornos de desarrollo locales optimizados. Para anticipar y mitigar estos problemas, es fundamental implementar estrategias de limitación de ancho de banda (network throttling) que permitan evaluar el comportamiento del servicio y optimizar la experiencia del usuario.

Existen tres enfoques principales para emular redes inestables:

1. Proxies de capa de aplicación o transporte: Herramientas como Fiddler o Charles interceptan el tráfico y aplican reglas de retardo.
2. Controladores a nivel de kernel: Soluciones como ipfw con dummynet manipulan directamente la interfaz de red.
3. Gateways configurables: Uso de utilitarias como netem en Linux para alterar los paquetes en un nodo de enrutamiento.

A continuación, se detalla el primer enfoque, centrado en el uso de Fiddler para interceptar y degradar tráfico HTTP/HTTPS, ofreciendo una solución rápida y visual para pruebas de rendimiento web.

Fundamentos de Fiddler como Proxy de Depuración

Fiddler opera como un proxy de depuración web gratuito y multiplataforma. Al enrutar el tráfico HTTP a través de su motor, permite inspeccionar peticiones y respuestas, establecer puntos de interrupción, modificar datos en tránsito y reproducir sesiones. Esta capacidad de interceptación es la base para inyectar latencia artificial en las comunicaciones.

Activación de la Limitación de Velocidad Básica

La herramienta incluye una configuración predeterminada para emular conexiones de módem telefónico. Esta opción se encuentra en el menú superior bajo Rules -> Performance -> Simulate Modem Speeds.

Al activar esta función, el throughput de las peticiones proxy se reduce drásticamente. Si se evalúa el rendimiento mediante herramientas de diagnóstico en el navegador, se observará una caída severa en las velocidades de carga y descarga. Además, los indicadores de latencia (Ping) mostrarán un incremento notable. Es importante aclarar que los navegadores no envían paquetes ICMP para calcular este Ping; en su lugar, estiman la latencia midiendo el tiempo de respuesta (RTT) de pequeñas peticiones HTTP GET. Por lo tanto, la latencia reportada refleja directamente el retardo artificial inyectado por el proxy.

Ajuste Fino de los Parámetros de Retardo

La emulación de módem de 56k suele ser excesivamente restrictiva para los estándares móviles actuales. Para definir escenarios más realistas, es necesario personalizar los parámetros de limitación. Esto se logra editando el script de reglas personalizadas, accesible desde Rules -> Customize Rules.... Este archivo, denominado CustomRules.js, está escrito en JScript.NET.

Dentro del script, la limitación se controla mediante una varible de estado que modifica las propiedades de la sesión activa:

if (isModemSimulationEnabled) {
    // Retardo aplicado por cada KB enviado en la petición
    var uploadDelayPerKb = "250"; 
    // Retardo aplicado por cada KB recibido en la respuesta
    var downloadDelayPerKb = "100";
    
    oSession["request-trickle-delay"] = uploadDelayPerKb;
    oSession["response-trickle-delay"] = downloadDelayPerKb;
}

Las propiedades request-trickle-delay y response-trickle-delay dictan los milisegundos de pausa por cada kilobyte transmitido. Teóricamente, el ancho de banda simulado puede calcularse mediante la fórmula:

Ancho de banda (Mbps) = (1 * 8 / 1000) / (Retardo en segundos)

Sin embargo, debido a optimizaciones internas en el procesamiento de buffers del proxy, el rendimiento real suele duplicar el valor teórico. Por ello, se recomienda aplicar un factor de corrección empírico de 2.0 al realizar los cálculos de capacidad esperada.

Implementación de Jitter (Variación de Latencia) mediante Scripts

Las redes reales rara vez mantienen una velocidad de transferencia constante; sufren de jitter o variaciones en la latencia. Para replicar este comportamiento, podemos extender la lógica del archivo de configuración utilizando funciones matemáticas que generen valores aleatorios para los retardos:

static function generateRandomLatency(lowerBound, upperBound) {
    var randomValue = Math.random() * (upperBound - lowerBound) + lowerBound;
    return Math.floor(randomValue).toString();
}

if (isModemSimulationEnabled) {
    var minLatency = 20;
    var maxLatency = 80;
    
    // Aplicar variación aleatoria a la subida y bajada
    oSession["request-trickle-delay"] = generateRandomLatency(minLatency, maxLatency);
    oSession["response-trickle-delay"] = generateRandomLatency(minLatency, maxLatency);
}

Con esta implementación, las herramientas de diagnóstico mostrarán fluctuaciones continuas en el throughput, proporcionando un entorno de pruebas mucho más fiel a las condiciones de redes móviles inestables. Para escenarios que requieran una lógica de interceptación más compleja, es posible desarrollar extensiones nativas en C# que se integren directamente con el pipeline del proxy.

Limitaciones del Enfoque Basado en Proxy HTTP

Aunque la manipulación de tráfico mediante proxies de capa de aplicación es ágil y no requiere privilegios de administrador a nivel de sistema operativo, presenta limitaciones inherentes. Al operar exclusivamente sobre HTTP/HTTPS, no puede simular anomalías de la capa de transporte o de red, como la pérdida de paquetes TCP, retransmisiones, duplicación de paquetes o comportamientos específicos de protocolos no basados en web (como UDP o WebSockets nativos). Para cubrir estos vectores de fallo, es necesario complementar las pruebas con herramientas de emulación a nivel de kernel o de gateway.