Lorsqu'un timeout est mal configuré, l'échec n'est pas toujours évident. Si un serverTimeout est fixé à 30 secondes, les requêtes long-polling retournent 504. Si connectTimeout est trop long, les clients attendant d'atteindre un backend hors service restent bloqués pendant plusieurs secondes avant de réessayer — déclenchant des cascades de retry. Si tunnelTimeout est trop court, les connexions WebSocket se coupent sans raison et les utilisateurs connaissent des déconnexions fantômes.
La plupart des systèmes présentent les paramètres de timeout comme une liste plate. Les opérateurs ne peuvent pas clairement distinguer quelle valeur contrôle la phase de requête HTTP, laquelle régit le temps de réponse du backend, laquelle s'applique aux tunnels WebSocket et laquelle affecte l'attente FIN. Le résultat est soit toutes les valeurs définies trop haut — créant des fuites de connexion — soit toutes définies trop bas, coupant le trafic utilisateur légitime.
WebSocket et les connexions de longue durée sont là où ce problème est le plus visible. HTTP keepalive est significatif dans la plage 30-120 secondes, mais une session WebSocket peut rester ouverte pendant des heures. Sans un tunnelTimeout géré séparément, les applications temps réel sont contraintes par le comportement HTTP idle ordinaire.
Le comportement de démantèlement TCP compte également. Lorsque clientFIN et serverFIN ne sont pas contrôlés, les connexions à moitié fermées peuvent épuiser le pool de descripteurs de fichiers. Sur les services exposés au public, cela se conjugue avec des patterns d'attaque de fermeture lente et se transforme en problème d'épuisement des ressources.
Les Profils de Timeout de TR7 regroupent 9 axes de timeout indépendants dans un seul profil nommé, garantissant que chaque pool applique le bon comportement d'attente, de drain et de fermeture de connexion pour son type de trafic.
TR7 gère les timeouts via des profils nommés réutilisables plutôt que de disperser des paramètres individuels à travers les pools.
Un opérateur définit un nom de profil et regroupe 9 valeurs de timeout à l'intérieur. Le même profil peut être lié à plusieurs pools, donnant aux pools web, API ou WebSocket un standard de timeout partagé cohérent.
La requête HTTP, le keepalive, le connect, le serveur, le client, la queue, le tunnel, le clientFIN et le serverFIN sont chacun gérés comme un champ distinct. Chaque champ est ajusté selon sa propre sémantique de trafic ; aucune valeur de timeout n'est utilisée comme substitut d'une autre.
Les connexions de longue durée telles que WebSocket et HTTP CONNECT sont gérées via tunnelTimeout séparément. Les connexions de chat, live-streaming et event-stream ne sont pas contraintes par le timer d'inactivité HTTP et ne se fermeront pas inutilement.
La durée pendant laquelle une connexion est maintenue après un signal de fermeture TCP est configurée indépendamment pour les côtés client et serveur. Cela réduit le risque de consommation de ressources de type FIN-WAIT et permet des politiques de drain plus agressives sur les services exposés au public.
Les Profils de Timeout permettent aux opérateurs d'ajuster précisément la durée de vie des connexions et le comportement d'attente à travers 9 champs indépendants pour correspondre à chaque type de trafic.
httpKeepaliveTimeout définit la durée pendant laquelle une connexion HTTP/1.1 keep-alive reste ouverte entre les requêtes. La valeur par défaut est 120 secondes. Le définir trop haut gaspille des ressources sur les connexions inactives ; trop bas augmente le coût de reconnexion. Il est ajusté par rapport au budget de connexion inactive du backend.
httpRequestTimeout est le temps accordé au client pour compléter la ligne de requête et les headers. La valeur par défaut est 30 secondes. Les clients qui envoient des headers très lentement peuvent être coupés à ce seuil. C'est un point de défense important contre les patterns de type slowloris sur les services exposés au public.
connectTimeout définit le temps que TR7 attend lors de l'établissement d'une connexion TCP à un backend. La valeur par défaut est 20 secondes. Si défini trop long, un backend hors service ou inaccessible bloque inutilement les clients. Les scénarios API nécessitant des réponses d'échec rapide bénéficient d'un connectTimeout plus bas.
serverTimeout est le temps accordé au backend pour produire une réponse. La valeur par défaut est 90 secondes. Il peut être défini bas pour les API rapides et augmenté pour les endpoints de reporting lourd, long-polling ou requête lente. Une valeur incorrectement basse cause des requêtes fonctionnant mais lentes à recevoir un 504.
clientTimeout est le temps d'attente pour que des données arrivent du client. Il s'applique à l'upload du corps de requête, aux requêtes pipeline et aux scénarios de client lent. La valeur par défaut est 90 secondes. Il peut être augmenté pour les grands uploads de fichiers et diminué pour réduire le risque de client lent sur les API publiques.
queueTimeout définit la durée pendant laquelle une requête attend dans la queue du pool lorsque la capacité de connexion est pleine. La valeur par défaut est 60 secondes. Lorsqu'elle est dépassée, la requête est retournée avec une erreur et le client n'est pas maintenu indéfiniment. Cette valeur doit être considérée conjointement avec les limites maxconn et les SLA applicatifs.
tunnelTimeout définit le temps d'inactivité pour les connexions WebSocket et tunnel HTTP CONNECT. La valeur par défaut est 120 secondes ; pour les applications temps réel, cela peut être augmenté à 3 600 secondes ou plus. Parce que ce timeout est indépendant du HTTP keepalive, les connexions de longue durée ne sont pas contraintes par les paramètres de trafic web. C'est critique pour les applications de chat, de notification en direct et de streaming.
clientFIN définit la durée pendant laquelle la connexion est maintenue après un signal FIN du client. La valeur par défaut est 3 secondes. Des valeurs plus basses empêchent les connexions à moitié fermées de consommer des descripteurs de fichiers. C'est particulièrement important sur les services exposés au public pour réduire la pression de ressources FIN-WAIT.
serverFIN limite le comportement de connexion après un signal FIN du backend. La valeur par défaut est 6 secondes. Maintenir serverFIN plus élevé que clientFIN permet plus de tolérance pour le drain gracieux lors de l'arrêt du backend. Ce paramètre affecte directement la qualité de fermeture des connexions dans les pools backend à fort trafic.
Le modèle de liaison profil-pool permet au même standard de timeout d'être partagé entre plusieurs pools. Tous les pools web peuvent pointer vers le profil web, les pools API vers le profil api et les pools WebSocket vers le profil websocket. Un seul changement de profil met à jour de manière centralisée le comportement de timeout de chaque pool lié à lui, réduisant la duplication de configuration et la dérive.
Les 9 champs de profil sont convertis vers les directives de timeout runtime correspondantes — connect, server, client, queue, tunnel, http-keep-alive, http-request, client-fin et server-fin. Les opérateurs gèrent les valeurs via le profil plutôt qu'en écrivant des directives individuelles, créant un pont cohérent entre l'interface graphique et le comportement runtime.
Le timing des contrôles de santé est géré via son propre champ de timeout et est indépendant du profil de timeout de trafic. Cette séparation est importante : la latence des sondes et le comportement d'attente du trafic de production ne se mélangent pas. Un contrôle de santé du backend peut être maintenu court pendant que le serverTimeout réel de l'endpoint reste long, permettant de surveiller la santé du service et le trafic utilisateur avec des sémantiques différentes.
Les profils de timeout sont opérés conjointement avec leur plage de valeurs, les valeurs par défaut, la prise en charge des décimales, la sémantique des tunnels, l'équilibre FIN et le modèle de liaison aux pools.
Les champs de timeout sont configurables de 0 à 60 000 secondes. Cette plage s'étend des paramètres défensifs sub-seconde aux sessions dépassant 16 heures, offrant suffisamment de flexibilité pour les exigences de long-poll et de connexion persistante.
httpKeepaliveTimeout accepte des valeurs décimales. Une valeur telle que 0,5 seconde permet un comportement de keepalive inactif plus précis. Les 8 autres champs de timeout sont traités comme des secondes en nombre entier.
Les valeurs par défaut fournissent un point de départ sûr adapté à la plupart du trafic web et API. httpKeepaliveTimeout 120, httpRequestTimeout 30, connectTimeout 20, serverTimeout 90, clientTimeout 90, queueTimeout 60, tunnelTimeout 120, clientFIN 3 et serverFIN 6 secondes sont des bases de référence appropriées. Pour les types de trafic spécialisés, ces valeurs doivent être ajustées par profil.
tunnelTimeout s'applique aux connexions tunnélisées telles que WebSocket et HTTP CONNECT. Ce n'est pas la même chose que le timeout de requête HTTP ou de keepalive. Le définir trop bas sur les connexions de longue durée produit des problèmes de déconnexion.
Dans le modèle par défaut, serverFIN est plus tolérant que clientFIN. Cela laisse plus de place pour le drain gracieux lors de l'arrêt du backend. Sur les services exposés au public, les deux valeurs peuvent être définies de manière plus agressive pour réduire la consommation de ressources des connexions à moitié fermées.
TR7 n'impose pas de préréglages prêts à l'emploi. Les opérateurs créent leurs propres profils nommés selon leur scénario — web, api, websocket, longpoll ou upload peuvent être définis pour correspondre aux standards de l'organisation. Lier un pool au profil approprié est préféré aux surcharges individuelles par service.
Un profil web peut être créé proche des valeurs par défaut. Le keepalive préserve l'expérience utilisateur pendant que les valeurs de timeout de requête et FIN limitent les connexions lentes ou à moitié fermées. Le même profil peut être lié à plusieurs pools web.
Les applications de chat ont besoin que les connexions WebSocket restent ouvertes sans coupures fréquentes. Dans un profil websocket, tunnelTimeout est défini à une longue valeur telle que 3 600 secondes pendant que les autres timeouts HTTP restent à leurs valeurs par défaut. Les connexions de longue durée ne sont plus contraintes par la fenêtre HTTP keepalive.
Un endpoint long-polling peut attendre plusieurs minutes que le backend réponde. Définir serverTimeout à 300 secondes dans un profil longpoll prend en charge une fenêtre d'attente de 5 minutes. Sans cela, un timeout d'API standard coupe les requêtes trop tôt.
Les données du client peuvent arriver lentement lors des grands uploads de corps POST ou de fichiers. Dans un profil upload, clientTimeout et, si nécessaire, httpRequestTimeout peuvent être augmentés à 600 secondes. Cela empêche les opérations d'upload légitimes mais lentes d'être coupées.
Lorsqu'une API bancaire attend une réponse rapide du backend, des valeurs serrées telles que connectTimeout 2 secondes et serverTimeout 5 secondes peuvent être utilisées. Un backend lent ou hors service ne bloque pas longtemps les clients. Le comportement de retry et de failover est déclenché plus tôt.
Un profil défensif peut utiliser des valeurs basses telles que httpRequestTimeout 5 secondes et clientFIN/serverFIN 1 seconde. Cette structure limite les patterns de livraison lente des headers et de consommation de connexions à moitié fermées. Elle réduit la surface d'attaque sur les services exposés au public.
Profils de timeout nommés à 9 axes pour vos pools web, API, WebSocket et upload. Laissez-nous vous présenter une mise en place en direct avec votre propre configuration.