En las aplicaciones modernas, los problemas de capacidad no se miden solo por conteo de solicitudes. Las descargas de archivos grandes, el streaming de vídeo, las exportaciones de API, el tráfico de backup o las extracciones masivas de datos impulsadas por bots pueden consumir un alto ancho de banda incluso con tasas de solicitud bajas. En estos casos, un límite de tasa de solicitudes por sí solo no es suficiente.
En entornos multi-tenant el problema se hace más visible. Cuando un tenant ejecuta una transferencia de datos pesada, la latencia para otros tenants puede aumentar. Sin un límite de capacidad entre los clientes que comparten el mismo vService, una política de uso justo no puede aplicarse técnicamente.
El traffic shaping convencional típicamente requiere complejas estructuras de encolado y clases a nivel de red. Ese modelo es potente, pero trabajar directamente con señales L7 como path, tenant, usuario, claims JWT o IP de origen en la capa de entrega de aplicaciones es difícil. La depuración y la gestión de cambios para los equipos de operaciones también se vuelven más pesadas.
El enfoque correcto es aplicar un techo de ancho de banda basado en conexión y clave a nivel de ADC. Deben poderse definir límites diferentes para un vService, usuario, tenant o grupo de tráfico de riesgo, y las direcciones de carga y descarga deben ser gestionables de forma independiente.
TR7 Traffic Shaping y QoS por vService controla el consumo de ancho de banda en la capa de entrega de aplicaciones con los modos stream, per-key y shared.
TR7 aplica el control de ancho de banda como una política de tres modos a través de vService, clave de tráfico y distribución de alta disponibilidad.
El tráfico de carga de clientes al backend y el tráfico de descarga del backend a los clientes pueden limitarse por separado para cada vService. Esto pone la capacidad de la aplicación bajo control a nivel de servicio.
En modo stream, cada conexión opera bajo su propio techo de ancho de banda. El consumo de recursos de una única conexión puede acotarse en descargas, cargas o streams de estilo WebSocket de larga duración.
En modo per-key, el límite se aplica según una clave producida por una expresión FX. La IP de origen, el usuario, el ID de tenant o un valor de claim JWT pueden servir todos como clave de ancho de banda.
En modo shared, el presupuesto de ancho de banda en una configuración de dos nodos no se confina a un único dispositivo. Un límite total para el mismo tenant o servicio puede aplicarse de forma más consistente a nivel de clúster.
El traffic shaping convierte los límites de ancho de banda por conexión, por clave y compartidos en una política a nivel de vService.
El modo stream aplica un techo separado a cada conexión. El modo per-key aplica un límite compartido a una IP, usuario, tenant o cualquier otra clave FX. El modo shared ayuda a que el mismo límite se distribuya entre nodos en una configuración de alta disponibilidad. Una única funcionalidad cubre por lo tanto la limitación simple de conexiones, la gestión de cuotas de tenants y el control de capacidad compartida a nivel de clúster.
En algunos servicios el tráfico de descarga es dominante; en otros la carga consume capacidad crítica. TR7 puede limitar la dirección de carga de clientes al backend y la dirección de descarga del backend a clientes por separado. Por ejemplo, la carga puede controlarse más estrictamente en un servicio de subida de archivos mientras la descarga es más estricta en un servicio de vídeo. Esta separación alinea la política de ancho de banda con el comportamiento real del tráfico.
En modo per-key, la clave de ancho de banda se construye usando el motor de expresión FX. La IP de origen, la información de usuario JWT, el ID de tenant, un valor de header o cualquier combinación de estos puede servir como clave. Por ejemplo, todos los usuarios pertenecientes al mismo tenant pueden compartir un techo de capacidad común. Este es un mecanismo potente para la aplicación de uso justo en modelos SaaS multi-tenant.
En modo per-key, cada clave se rastrea como un estado de uso separado. Las claves que han estado en silencio durante un período definido se eliminan; las claves activas permanecen sujetas a la política de límite. Este modelo proporciona control de capacidad centralizado para miles de usuarios o tenants. El operador aplica límites contra un propietario lógico de tráfico en lugar de conexiones individuales.
En configuraciones activo-activo o activo-pasivo, el tráfico puede distribuirse entre dos nodos. El modo shared ayuda a que el presupuesto de ancho de banda se aplique como un comportamiento de servicio compartido en lugar de confinarse a un único nodo. Cuando un tenant se mueve de un nodo a otro, la lógica de límite no se interrumpe. Esto es particularmente importante para los escenarios de SLA y cuotas empresariales.
Las reglas de traffic shaping pueden operar condicionalmente. Un tenant premium puede ser ilimitado, un tenant gratuito limitado a 100 Kbps y una IP sospechosa restringida a 1 Mbps. Las condiciones pueden construirse a partir de path, usuario, header, claim JWT, IP de origen o cualquier expresión FX. La política de ancho de banda ya no es una única configuración global.
Diferentes segmentos de tráfico dentro del mismo vService pueden tener diferentes reglas de límite. Por ejemplo, el path `/download` puede tener su propio límite, `/api/export` otro y las llamadas de API estándar otro distinto. Esto descompone el control de capacidad en segmentos alineados con el comportamiento de la aplicación. El operador aplica shaping sensible al contexto en lugar de un único techo contundente.
Las conexiones WebSocket, de descarga de archivos grandes o de streaming de larga duración pueden eludir los límites clásicos basados en solicitudes. El modo stream aplica un techo de ancho de banda a cada uno de estos flujos. Se evita que una única conexión larga agote la capacidad del servicio. Este modelo es importante para escenarios de medios, transferencia de archivos y streaming en tiempo real.
Los límites de ancho de banda pueden actualizarse mediante un cambio de configuración. Los nuevos límites se aplican al tráfico de producción de forma controlada. Esto permite una respuesta rápida durante campañas, eventos de DDoS sospechosos, cambios de cuota de tenant o restricciones de capacidad temporales. Los equipos de operaciones no necesitan esperar un cambio en un dispositivo de red separado.
En modo per-key, el estado de uso de cada usuario, IP o tenant puede observarse. El operador puede ver qué clave está aproximándose a su techo de cuota. Esta información es valiosa para soporte al cliente, análisis de seguridad y planificación de capacidad. Los eventos de superación del límite pueden conectarse a logs y pipelines SIEM.
No todo flujo sospechoso debe bloquearse por completo. TR7 puede aplicar un límite de ancho de banda bajo a IPs de riesgo, ASNs, paths o grupos de comportamiento. Esto reduce el impacto de un ataque mientras se evita un corte completo de los usuarios legítimos en situaciones de falsos positivos. El enfoque encaja en un modelo de defensa graduada.
Esta funcionalidad no es un sistema complejo de encolado a nivel de red ni un mecanismo de hardware QoS. TR7 aplica un techo de ancho de banda a nivel de conexión y flujo. Este límite es sencillo de gestionar a nivel de vService, clave y condición. El operador define claramente cuánta capacidad recibe cada servicio o usuario.
El traffic shaping debe planificarse junto con el modo de límite, el diseño de claves, la dirección de carga y descarga, los flujos de larga duración, la distribución en clúster y la visibilidad de auditoría.
El modo stream es adecuado para límites por conexión, el modo per-key para límites por usuario o por tenant, y el modo shared para un límite común en el clúster. Elegir el modo equivocado puede romper el comportamiento de capacidad esperado. El objetivo de la política debe clarificarse primero.
La clave usada en modo per-key determina a quién pertenece realmente el límite. La IP de origen es suficiente en algunos entornos; la información de tenant o usuario puede proporcionar un modelo de cuota más preciso. Para múltiples usuarios detrás de NAT, solo la IP puede no ser equitativa.
Las direcciones de carga y descarga tienen diferentes impactos en los recursos. Las cargas grandes de archivos consumen capacidad de entrada del backend; las descargas consumen capacidad de salida. Estas dos direcciones deben limitarse por separado.
Las conexiones WebSocket, de stream y de transferencia de archivos grandes pueden permanecer abiertas durante un período prolongado. Los límites por conexión hacen que el consumo de recursos sea más predecible en estos flujos. La configuración de timeout y límite de ancho de banda debe evaluarse conjuntamente.
El modo shared puede usarse para el comportamiento de presupuesto común en configuraciones de dos nodos. El objetivo es que la política de límite permanezca consistente a medida que la distribución de tráfico cambia entre nodos. Este comportamiento es importante para los SLA críticos de tenants.
Las claves que alcanzan un umbral de límite pueden registrarse. Las alertas en el SIEM pueden configurarse para superaciones de cuota por tenant, por usuario o por IP. Esta información es útil tanto para las operaciones de seguridad como para el soporte al cliente.
En un entorno SaaS multi-tenant puede definirse un techo de capacidad separado para cada tenant. El ID de tenant se usa como clave, y todos los usuarios pertenecientes al mismo tenant comparten el límite común.
Puede darse un límite de ancho de banda mayor a los clientes premium y uno menor a los usuarios gratuitos. La diferencia de nivel se gestiona en la política del ADC sin incrustar lógica en el código de la aplicación.
Los diferentes niveles de calidad en servicios de vídeo o medios requieren diferentes anchos de banda. TR7 puede aplicar un techo de descarga basado en path o nivel de suscripción del usuario.
Durante un evento de DDoS o bot sospechoso, el tráfico puede colocarse bajo un límite de tasa bajo en lugar de cortarse por completo. Esto reduce el impacto del ataque mientras se evita una desconexión completa para los usuarios reales en casos de falsos positivos.
Las llamadas de API internas pueden dejarse ilimitadas mientras el tráfico de internet se limita. La separación se hace de forma centralizada usando condiciones de IP de origen, path o header.
Ciertos endpoints pueden recibir picos de tráfico repentinos durante campañas de e-commerce. TR7 aplica un techo de ancho de banda temporal a las APIs de checkout o campaña para mantener la estabilidad del servicio.
Traslade la gestión de ancho de banda al ADC. Establezca políticas de capacidad con los modos stream, per-key y shared — sin appliance de red separado ni arquitectura de encolado compleja.