Cuando un timeout está configurado incorrectamente, el fallo no siempre es obvio. Si un serverTimeout se fija en 30 segundos, las solicitudes de long-polling devuelven 504. Si el connectTimeout es demasiado largo, los clientes que esperan llegar a un backend caído se bloquean durante segundos antes de reintentar — desencadenando cascadas de reintentos. Si el tunnelTimeout es demasiado corto, las conexiones WebSocket se caen sin motivo y los usuarios experimentan desconexiones fantasma.
La mayoría de los sistemas presentan la configuración de timeout como una lista plana. Los operadores no pueden distinguir claramente qué valor controla la fase de solicitud HTTP, cuál gobierna el tiempo de respuesta del backend, cuál aplica a los túneles WebSocket y cuál afecta a la espera FIN. El resultado es que todos los valores se establecen demasiado altos — creando fugas de conexión — o todos demasiado bajos, cortando el tráfico legítimo de usuarios.
WebSocket y las conexiones de larga duración son donde este problema es más visible. El HTTP keepalive es significativo en el rango de 30–120 segundos, pero una sesión WebSocket puede permanecer abierta durante horas. Sin un tunnelTimeout gestionado por separado, las aplicaciones en tiempo real están restringidas por el comportamiento de inactividad HTTP ordinario.
El comportamiento de teardown TCP también importa. Cuando clientFIN y serverFIN no están controlados, las conexiones semi-cerradas pueden agotar el pool de descriptores de archivo. En los servicios de cara al público, esto se combina con patrones de ataque slow-close y se convierte en un problema de agotamiento de recursos.
TR7 Perfiles de Timeout reúne 9 ejes de timeout independientes en un único perfil con nombre, asegurando que cada pool aplique el comportamiento de espera, drain y cierre de conexión correcto para su tipo de tráfico.
TR7 gestiona los timeouts a través de perfiles reutilizables con nombre en lugar de dispersar configuraciones individuales entre pools.
Un operador define un nombre de perfil y agrupa 9 valores de timeout dentro de él. El mismo perfil puede vincularse a múltiples pools, dando a los pools web, API o WebSocket un estándar de timeout compartido consistente.
HTTP request, keepalive, connect, server, client, queue, tunnel, clientFIN y serverFIN se gestionan cada uno como un campo distinto. Cada campo se ajusta según su propia semántica de tráfico; ningún valor de timeout se usa como sustituto de otro.
Las conexiones de larga duración como WebSocket y HTTP CONNECT se gestionan a través de tunnelTimeout de forma separada. Las conexiones de chat, live-streaming y event-stream no se ven restringidas por el temporizador de inactividad HTTP y no se cerrarán innecesariamente.
El tiempo que se mantiene una conexión después de una señal de cierre TCP se configura de forma independiente para los lados del cliente y del servidor. Esto reduce el riesgo de consumo de recursos estilo FIN-WAIT y permite políticas de drain más agresivas en los servicios de cara al público.
Los Perfiles de Timeout permiten a los operadores ajustar con precisión la duración de la conexión y el comportamiento de espera en 9 campos independientes para adaptarse a cada tipo de tráfico.
httpKeepaliveTimeout define cuánto tiempo permanece abierta una conexión keep-alive HTTP/1.1 entre solicitudes. El valor predeterminado es 120 segundos. Establecerlo demasiado alto desperdicia recursos en conexiones inactivas; demasiado bajo aumenta el coste de reconexión. Se ajusta según el presupuesto de conexiones inactivas del backend.
httpRequestTimeout es el tiempo permitido para que el cliente complete la línea de solicitud y los headers. El valor predeterminado es 30 segundos. Los clientes que envían headers muy lentamente pueden cortarse en este umbral. Es un punto de defensa importante contra los patrones de estilo slowloris en los servicios de cara al público.
connectTimeout define cuánto tiempo espera TR7 al establecer una conexión TCP a un backend. El valor predeterminado es 20 segundos. Si se establece demasiado largo, un backend caído o inalcanzable bloquea a los clientes innecesariamente. Los escenarios de API que requieren respuestas de fallo rápido se benefician de un connectTimeout más bajo.
serverTimeout es el tiempo permitido para que el backend produzca una respuesta. El valor predeterminado es 90 segundos. Puede establecerse bajo para APIs rápidas y elevarse para endpoints de reporting pesado, long-polling o consultas lentas. Un valor incorrectamente bajo causa que solicitudes funcionando pero lentas reciban 504.
clientTimeout es el tiempo de espera para que los datos lleguen del cliente. Se aplica a la carga del cuerpo de solicitud, las solicitudes en pipeline y los escenarios de cliente lento. El valor predeterminado es 90 segundos. Puede elevarse para cargas de archivos grandes y bajarse para reducir el riesgo de clientes lentos en APIs públicas.
queueTimeout define cuánto tiempo espera una solicitud en la cola del pool cuando la capacidad de conexión está llena. El valor predeterminado es 60 segundos. Cuando se supera, la solicitud se devuelve con un error y el cliente no queda retenido indefinidamente. Este valor debe considerarse junto con los límites maxconn y los SLA de la aplicación.
tunnelTimeout define el tiempo de inactividad para las conexiones de túnel WebSocket y HTTP CONNECT. El valor predeterminado es 120 segundos; para aplicaciones en tiempo real esto puede elevarse a 3600 segundos o más. Dado que este timeout es independiente del HTTP keepalive, las conexiones de larga duración no se ven restringidas por la configuración de tráfico web. Es crítico para aplicaciones de chat, notificaciones en vivo y stream.
clientFIN establece cuánto tiempo se mantiene la conexión después de una señal FIN del cliente. El valor predeterminado es 3 segundos. Los valores más bajos evitan que las conexiones semi-cerradas consuman descriptores de archivo. Esto es especialmente importante en los servicios de cara al público para reducir la presión de recursos FIN-WAIT.
serverFIN limita el comportamiento de la conexión después de una señal FIN del backend. El valor predeterminado es 6 segundos. Mantener serverFIN más alto que clientFIN permite más tolerancia para el drain elegante durante el cierre del backend. Esta configuración afecta directamente la calidad del cierre de conexión en pools de backend de alto tráfico.
El modelo de vinculación perfil-pool permite compartir el mismo estándar de timeout entre múltiples pools. Todos los pools web pueden apuntar al perfil web, los pools de API al perfil api y los pools WebSocket al perfil websocket. Un único cambio de perfil actualiza de forma centralizada el comportamiento de timeout de cada pool vinculado a él, reduciendo la duplicación y la deriva de la configuración.
Los 9 campos del perfil se convierten en las directivas de timeout en tiempo de ejecución correspondientes — connect, server, client, queue, tunnel, http-keep-alive, http-request, client-fin y server-fin. Los operadores gestionan los valores a través del perfil en lugar de escribir directivas individuales, creando un puente consistente entre la GUI y el comportamiento en tiempo de ejecución.
El timing de comprobación de salud se gestiona a través de su propio campo de timeout y es independiente del perfil de timeout de tráfico. Esta separación importa: la latencia de sonda y el comportamiento de espera del tráfico de producción no se mezclan. Una comprobación de salud del backend puede mantenerse corta mientras el serverTimeout del endpoint real permanece largo, permitiendo monitorear la salud del servicio y el tráfico de usuarios con diferentes semánticas.
Los perfiles de timeout se operan junto con su rango de valores, valores predeterminados, soporte decimal, semántica de túneles, balance FIN y modelo de vinculación de pools.
Los campos de timeout son configurables de 0 a 60.000 segundos. Este rango abarca desde configuraciones defensivas de subsegundo hasta sesiones superiores a 16 horas, proporcionando suficiente flexibilidad para los requisitos de long-poll y conexiones persistentes.
httpKeepaliveTimeout acepta valores decimales. Un valor como 0,5 segundos permite un comportamiento de keepalive inactivo más preciso. Los 8 campos de timeout restantes se tratan como segundos en números enteros.
Los valores predeterminados proporcionan un punto de partida seguro adecuado para la mayoría del tráfico web y de API. httpKeepaliveTimeout 120, httpRequestTimeout 30, connectTimeout 20, serverTimeout 90, clientTimeout 90, queueTimeout 60, tunnelTimeout 120, clientFIN 3 y serverFIN 6 segundos son líneas base apropiadas. Para tipos de tráfico especializados, estos valores deben ajustarse por perfil.
tunnelTimeout aplica a conexiones de túnel como WebSocket y HTTP CONNECT. No es lo mismo que el timeout de solicitud HTTP o de keepalive. Establecerlo demasiado bajo en conexiones de larga duración produce problemas de desconexión.
En el modelo predeterminado, serverFIN es más tolerante que clientFIN. Esto deja más margen para el drain elegante durante el cierre del backend. En los servicios de cara al público, ambos valores pueden establecerse de forma más agresiva para reducir el consumo de recursos de conexiones semi-cerradas.
TR7 no impone presets predefinidos. Los operadores crean sus propios perfiles con nombre según su escenario — web, api, websocket, longpoll o upload pueden definirse para adaptarse a los estándares de la organización. Se prefiere vincular un pool al perfil apropiado sobre las anulaciones individuales por servicio.
Puede crearse un perfil web cercano a los valores predeterminados. El keepalive preserva la experiencia del usuario mientras los valores de timeout de request y FIN limitan las conexiones lentas o semi-cerradas. El mismo perfil puede vincularse a múltiples pools web.
Las aplicaciones de chat necesitan que las conexiones WebSocket permanezcan abiertas sin caídas frecuentes. Dentro de un perfil websocket, tunnelTimeout se establece en un valor largo como 3600 segundos mientras los demás timeouts HTTP permanecen en sus valores predeterminados. Las conexiones de larga duración ya no se ven restringidas por la ventana de HTTP keepalive.
Un endpoint de long-polling puede esperar varios minutos para que el backend responda. Establecer serverTimeout a 300 segundos en un perfil longpoll soporta una ventana de espera de 5 minutos. Sin esto, un timeout de API estándar corta las solicitudes demasiado pronto.
Los datos del cliente pueden llegar lentamente durante el tráfico de cuerpo POST grande o de carga de archivos. En un perfil upload, clientTimeout y, si es necesario, httpRequestTimeout pueden elevarse a 600 segundos. Esto evita que las operaciones de carga legítimas pero lentas sean cortadas.
Cuando una API bancaria espera una respuesta rápida del backend, pueden usarse valores estrictos como connectTimeout 2 segundos y serverTimeout 5 segundos. Un backend lento o caído no bloquea a los clientes por mucho tiempo. El comportamiento de reintento y failover se activa antes.
Un perfil defensivo puede usar valores bajos como httpRequestTimeout 5 segundos y clientFIN/serverFIN 1 segundo. Esta estructura limita la entrega lenta de headers y los patrones de consumo de conexiones semi-cerradas. Reduce la superficie de ataque en los servicios de cara al público.
Perfiles de timeout de 9 ejes con nombre para sus pools web, API, WebSocket y de carga. Déjenos guiarle por una configuración en vivo con su propia configuración.