En el modelo de conexión clásico, una gran cantidad de clientes se traduce en un número igualmente grande de conexiones TCP o TLS en el lado del backend. Cada nueva conexión conlleva un handshake TCP de tres vías, un handshake TLS, gestión de sockets y un coste de cierre. A medida que crece el tráfico, los backends dedican más tiempo a la sobrecarga de conexiones que a la lógica real de la aplicación.
Las solicitudes de API cortas y frecuentes hacen el problema más visible. Las aplicaciones móviles, las llamadas B2B, los microservicios y los flujos de checkout generan muchas solicitudes pequeñas. Cuando cada solicitud se convierte en una nueva conexión, la CPU, la memoria, los sockets y los recursos de red se consumen innecesariamente.
El comportamiento HTTP/1.1 en el frontend añade otra restricción. Una solicitud lenta en una conexión dada puede bloquear a las demás; la capacidad de streams paralelos es limitada. El tráfico moderno de clientes se mueve de forma más eficiente con HTTP/2 y HTTP/3, y la gestión de conexiones del backend debe seguir el ritmo.
El enfoque correcto no es duplicar las conexiones de cliente una a una en los backends. Es hacer un pool y reutilizar las conexiones, y ajustar el comportamiento de multiplexación por tipo de servicio. Las operaciones no idempotentes requieren modos de reutilización más seguros; las APIs de alto volumen se benefician de modos más agresivos.
TR7 Connection Multiplexing ofrece este modelo: multiplexación de streams moderna en el frontend, un pool keepalive en el backend y una política de reutilización de conexiones gestionable por servicio.
TR7 implementa la multiplexación de conexiones mediante un pool keepalive backend, un modo de reutilización por servicio, soporte de protocolo HTTP/2 y HTTP/3, y TLS session resumption.
Las conexiones abiertas al backend no se cierran inmediatamente cuando se completa una solicitud — se devuelven al pool para su reutilización. Esto reduce la sobrecarga de handshakes TCP y TLS en el lado del backend.
La reutilización de conexiones puede gestionarse mediante cuatro modos: never, safe, aggressive y always. Los operadores seleccionan el comportamiento correcto para cada servicio equilibrando los requisitos de seguridad, las restricciones de idempotencia y los objetivos de rendimiento.
Con HTTP/2 ALPN, múltiples streams paralelos se transportan sobre una única conexión. Esto es especialmente eficaz para grandes cantidades de solicitudes de API cortas, mejorando la eficiencia de conexión en el lado del cliente.
TLS session resumption permite a los clientes recurrentes saltarse el handshake completo. En servicios con mucho TLS, esto reduce el consumo de CPU y la latencia de establecimiento de conexiones.
Connection Multiplexing reduce la sobrecarga de conexiones backend mediante la reutilización por servicio, keepalive, HTTP/2, HTTP/3 y perfiles de timeout.
TR7 gestiona la reutilización de conexiones como una acción a nivel de pool. El modo never se comporta cerca de un modelo de nueva conexión por solicitud. safe proporciona una reutilización más controlada. aggressive y always apuntan a un mayor ahorro de conexiones para servicios de alto volumen. Los operadores eligen el modo que refleja las necesidades de rendimiento y seguridad de cada servicio.
Con el keepalive habilitado en el lado del backend, las conexiones regresan al pool cuando se completa una solicitud. La siguiente solicitud toma una conexión lista en lugar de abrir una nueva. Esto reduce significativamente el coste de establecimiento de conexiones para solicitudes cortas y da a los backends un perfil de conexión más estable y predecible.
TR7 soporta HTTP/2 ALPN en el lado del cliente, transportando múltiples streams sobre una única conexión. Esto reduce el número de conexiones que los navegadores y clientes móviles necesitan abrir. La latencia y el consumo de recursos se vuelven más predecibles. El soporte HTTP/2 es la capa base de rendimiento para el tráfico web y de API moderno.
HTTP/2 en el lado del backend es opcional a nivel de servicio. Cuando un backend soporta HTTP/2, ALPN negocia h2 o http/1.1 en consecuencia. Los servicios que no soportan HTTP/2 caen automáticamente a HTTP/1.1. Esto permite que los backends modernos se beneficien de HTTP/2 sin romper los servicios legacy.
TR7 transporta el tráfico moderno de clientes sobre HTTP/3/QUIC en el frontend. En redes móviles y con pérdidas, el establecimiento de conexiones y la continuidad de streams mejoran. El fallback a HTTP/2 preserva la compatibilidad hacia atrás. El lado del backend se gestiona de forma independiente según sus propias capacidades de protocolo.
El modo de reutilización safe aplica un comportamiento más conservador para operaciones arriesgadas o no idempotentes. En APIs bancarias, de pago o de escritura intensiva, la optimización del rendimiento no debe ir en detrimento de la integridad de datos. Este modo mantiene la reutilización dentro de límites seguros. Los operadores pueden seleccionar safe en lugar de aggressive para servicios de alta sensibilidad.
La reutilización de sesión TLS permite al mismo cliente reconectarse sin repetir el handshake completo. Los mecanismos de session tickets de TLS 1.2 y PSK de TLS 1.3 soportan este comportamiento. Bajo tráfico HTTPS intenso, el uso de CPU del ADC se reduce significativamente. Esto es especialmente valioso en escenarios móviles y de API con muchas conexiones de corta duración.
Los valores de timeout HTTP keepalive, client-fin, server-fin, tunnel, connect, server, client y queue determinan cómo se comporta el pool de conexiones. Los timeouts demasiado cortos agotan el pool y reducen la reutilización. Los timeouts demasiado largos elevan el recuento de conexiones inactivas y el consumo de memoria. TR7 hace que este equilibrio sea gestionable por perfil de servicio.
Los límites de conexión pueden definirse a nivel de pool y backend. Estos límites ayudan a proteger los servicios backend de ráfagas repentinas de conexiones. Son especialmente importantes para aplicaciones con capacidad de conexión menor o con licencia. Cuando se combina con la multiplexación de conexiones, los límites maxconn proporcionan un comportamiento de capacidad más predecible.
La tasa de nuevas conexiones por segundo puede limitarse con un techo. Esto evita que los servicios backend se vean desbordados por olas de bots, tormentas de reconexión móvil o picos repentinos de tráfico. El pool keepalive gestiona la reutilización mientras la tasa de nuevas conexiones se gestiona por separado. Los equipos de operaciones pueden restringir el comportamiento de conexión no solo por recuento total sino también por tasa.
Las señales de TCP keepalive en los lados del cliente y del backend pueden evitar que los dispositivos de red intermedios cierren silenciosamente las conexiones inactivas. Las conexiones de larga duración son vulnerables a los timeouts de firewall y NAT. Keepalive ayuda a mantener esas conexiones. Esto importa más en servicios con sesiones largas o tráfico de baja frecuencia.
Cuando cambia la configuración, las conexiones existentes se drenan mientras las nuevas conexiones son aceptadas por el nuevo worker bajo la configuración actualizada. Esto evita la interrupción abrupta de los pools de conexiones. Los operadores pueden cambiar los valores de timeout, los modos de reutilización o los ajustes ALPN mientras preservan la continuidad del servicio. Los cambios en producción conllevan un menor riesgo operacional.
La multiplexación de conexiones se opera junto con el equilibrio del timeout keepalive, el comportamiento de drain, el dimensionamiento de la caché TLS, la concurrencia de streams, el puente de protocolos y las métricas de monitorización.
Si el timeout keepalive es demasiado corto, las conexiones se cierran antes de poder reutilizarse y la utilización del pool cae. Si es demasiado largo, el recuento de conexiones inactivas crece y el consumo de memoria aumenta. El valor debe ajustarse para adaptarse a la densidad del tráfico y la capacidad del backend.
Durante un soft reload, el worker antiguo drena las conexiones existentes de forma controlada mientras el nuevo worker acepta conexiones bajo la nueva configuración. Esto es crítico para los cambios sin interrupción en servicios que dependen de la multiplexación de conexiones. La duración del drenado debe planificarse por separado para las conexiones de larga duración.
El tamaño de la caché de sesión TLS importa para los clientes que se reconectan con frecuencia bajo tráfico HTTPS intenso. Una caché demasiado pequeña reduce la tasa de resumption. Una caché muy grande debe tenerse en cuenta en la planificación de memoria.
TCP keepalive a nivel del SO señala a las capas intermedias que la conexión sigue activa. Esto reduce la posibilidad de que los dispositivos NAT, firewalls o appliances de seguridad con estado cierren prematuramente las conexiones inactivas. El ajuste es más valioso para las conexiones de larga duración.
El número de streams paralelos sobre una única conexión HTTP/2 puede limitarse. Un valor demasiado bajo reduce el beneficio de la multiplexación; un valor demasiado alto arriesga sobrecargar una única conexión. El ajuste correcto depende de la mezcla de tráfico.
Cuando el lado del cliente usa HTTP/2 pero el backend ejecuta HTTP/1.1, el comportamiento de streams en el lado del backend no refleja el mismo paralelismo. Algunas solicitudes pueden serializarse según el modelo de conexión del backend. Si el backend soporta HTTP/2, debería considerarse habilitar el toggle correspondiente.
Cuando TR7 termina TLS en lugar del backend, la carga de handshakes TLS del backend desaparece. El ADC asume el coste de procesamiento TLS. TLS session resumption y el pool de conexiones juntos ayudan a compensar ese coste.
Los totales de solicitudes, la profundidad de cola, el recuento de conexiones, el comportamiento de reutilización y las métricas de error reflejan el estado del pool de conexiones. Una reutilización baja justifica una revisión de los ajustes de timeout o el comportamiento del backend. Una cola en crecimiento indica que la capacidad de conexión del backend o los límites maxconn pueden necesitar ajuste.
Las APIs SaaS generan volúmenes de solicitudes cortas y densas. La multiplexación de conexiones reduce el número de conexiones al backend y elimina el coste repetido de establecimiento TCP/TLS.
Los clientes móviles abren y cierran conexiones con frecuencia. Keepalive, HTTP/2 y TLS resumption reducen el coste de reconexión en el lado del cliente.
Para backends que soportan HTTP/2, el toggle ALPN puede habilitarse para evaluar la multiplexación de streams. Esto produce un uso más eficiente de conexiones en llamadas inter-servicio de alta frecuencia.
El tráfico de edge o de clientes denso puede usar conexiones de un pool hacia el backend de origen en lugar de abrir nuevas de forma continua. Esto reduce la CPU del origen y la presión sobre los sockets.
Para operaciones financieras no idempotentes, se prefiere el modo safe frente a la reutilización agresiva. Esto persigue ganancias de rendimiento mientras preserva la integridad de las transacciones.
Los servicios B2B suelen transportar solicitudes de alto valor y baja frecuencia que aún incurren en un coste TLS significativo. Un pool de conexiones y session resumption reducen la sobrecarga de establecimiento de conexiones seguras.
Pool keepalive, modos http-reuse, HTTP/2, HTTP/3 y TLS session resumption — toda la optimización de conexiones en una única política ADC. Permítanos mostrarle una configuración en vivo sobre sus propios servicios.