Wenn ein Timeout falsch eingestellt ist, ist der Fehler nicht immer offensichtlich. Wenn ein serverTimeout auf 30 Sekunden festgelegt wird, geben Long-Polling-Anfragen 504 zurück. Wenn connectTimeout zu lang ist, warten Clients, die ein ausgefallenes Backend erreichen wollen, Sekunden lang, bevor sie einen erneuten Versuch unternehmen — was Wiederholungskaskaden auslöst. Wenn tunnelTimeout zu kurz ist, fallen WebSocket-Verbindungen ohne Grund ab und Benutzer erleben Geister-Trennungen.
Die meisten Systeme präsentieren Timeout-Einstellungen als flache Liste. Operatoren können nicht klar erkennen, welcher Wert die HTTP-Anfragephase steuert, welcher die Backend-Antwortzeit regelt, welcher für WebSocket-Tunnel gilt und welcher den FIN-Wait beeinflusst. Das Ergebnis ist entweder, dass alle Werte zu hoch eingestellt werden — was Verbindungslecks erzeugt — oder alle zu niedrig, was legitimen Benutzer-Traffic abbricht.
WebSocket- und langlebige Verbindungen sind, wo dieses Problem am sichtbarsten ist. HTTP-Keepalive ist im Bereich von 30–120 Sekunden sinnvoll, aber eine WebSocket-Sitzung kann stundenlang offen bleiben. Ohne einen separat verwalteten tunnelTimeout werden Echtzeit-Anwendungen durch normales HTTP-Idle-Verhalten eingeschränkt.
TCP-Teardown-Verhalten ist ebenfalls wichtig. Wenn clientFIN und serverFIN nicht kontrolliert werden, können halb-geschlossene Verbindungen den File-Descriptor-Pool erschöpfen. Bei öffentlich zugänglichen Services verstärkt sich dies mit langsam-schließenden Angriffsmustern und wird zu einem Ressourcenerschöpfungsproblem.
TR7 Timeout-Profile sammeln 9 unabhängige Timeout-Achsen in einem einzigen benannten Profil und stellen sicher, dass jeder Pool das korrekte Warte-, Drain- und Verbindungsschluss-Verhalten für seinen Traffic-Typ anwendet.
TR7 verwaltet Timeouts durch wiederverwendbare benannte Profile, anstatt individuelle Einstellungen über Pools zu verstreuen.
Ein Operator definiert einen Profilnamen und gruppiert 9 Timeout-Werte darin. Dasselbe Profil kann an mehrere Pools gebunden werden, was Web-, API- oder WebSocket-Pools einen konsistenten gemeinsamen Timeout-Standard gibt.
HTTP-Request, Keepalive, Connect, Server, Client, Queue, Tunnel, clientFIN und serverFIN werden jeweils als separates Feld verwaltet. Jedes Feld wird gemäß seiner eigenen Traffic-Semantik abgestimmt; kein Timeout-Wert wird als Ersatz für einen anderen verwendet.
Langlebige Verbindungen wie WebSocket und HTTP CONNECT werden durch tunnelTimeout separat verwaltet. Chat-, Live-Streaming- und Event-Stream-Verbindungen werden nicht durch den HTTP-Idle-Timer eingeschränkt und schließen nicht unnötig.
Wie lange eine Verbindung nach einem TCP-Close-Signal gehalten wird, ist unabhängig für Client- und Server-Seiten konfigurierbar. Dies reduziert das Risiko des FIN-WAIT-artigen Ressourcenverbrauchs und ermöglicht aggressivere Drain-Richtlinien bei öffentlich zugänglichen Services.
Timeout-Profile ermöglichen Operatoren, Verbindungslebensdauer und Warteverhalten präzise über 9 unabhängige Felder abzustimmen, um jeden Traffic-Typ zu unterstützen.
httpKeepaliveTimeout definiert, wie lange eine HTTP/1.1-Keep-Alive-Verbindung zwischen Anfragen offen bleibt. Der Standard ist 120 Sekunden. Zu hoch eingestellt, verschwendet es Ressourcen bei Idle-Verbindungen; zu niedrig erhöht es die Wiederverbindungskosten. Es wird gegen das Idle-Verbindungsbudget des Backends abgestimmt.
httpRequestTimeout ist die Zeit, die dem Client erlaubt wird, die Anfragzeile und Header abzuschließen. Der Standard ist 30 Sekunden. Clients, die Header sehr langsam senden, können an diesem Schwellenwert abgebrochen werden. Es ist ein wichtiger Verteidigungspunkt gegen Slowloris-ähnliche Muster bei öffentlich zugänglichen Services.
connectTimeout definiert, wie lange TR7 beim Aufbau einer TCP-Verbindung zu einem Backend wartet. Der Standard ist 20 Sekunden. Wenn zu lang eingestellt, blockiert ein ausgefallenes oder unerreichbares Backend Clients unnötig. API-Szenarien, die schnelle Fehlerantworten erfordern, profitieren von einem niedrigeren connectTimeout.
serverTimeout ist die Zeit, die dem Backend erlaubt wird, eine Antwort zu produzieren. Der Standard ist 90 Sekunden. Er kann bei schnellen APIs niedrig und bei schweren Berichten, Long-Polling oder Slow-Query-Endpoints hoch eingestellt werden. Ein falsch niedriger Wert führt dazu, dass funktionierende, aber langsame Anfragen 504 erhalten.
clientTimeout ist die Wartezeit für Daten vom Client. Er gilt für Request-Body-Upload, Pipelined-Requests und Slow-Client-Szenarien. Der Standard ist 90 Sekunden. Er kann bei großen Datei-Uploads erhöht und zum Reduzieren des Slow-Client-Risikos bei öffentlichen APIs gesenkt werden.
queueTimeout definiert, wie lange eine Anfrage in der Pool-Queue wartet, wenn die Verbindungskapazität voll ist. Der Standard ist 60 Sekunden. Wenn überschritten, wird die Anfrage mit einem Fehler zurückgegeben und der Client wird nicht unbegrenzt gehalten. Dieser Wert sollte neben maxconn-Limits und Anwendungs-SLAs berücksichtigt werden.
tunnelTimeout definiert die Idle-Zeit für WebSocket- und HTTP-CONNECT-Tunnel-Verbindungen. Der Standard ist 120 Sekunden; bei Echtzeit-Anwendungen kann er auf 3600 Sekunden oder mehr erhöht werden. Da dieser Timeout unabhängig vom HTTP-Keepalive ist, werden langlebige Verbindungen nicht durch Web-Traffic-Einstellungen eingeschränkt. Er ist kritisch für Chat-, Live-Benachrichtigungs- und Stream-Anwendungen.
clientFIN legt fest, wie lange die Verbindung nach einem FIN-Signal vom Client gehalten wird. Der Standard ist 3 Sekunden. Niedrigere Werte verhindern, dass halb-geschlossene Verbindungen File-Descriptor verbrauchen. Dies ist besonders bei öffentlich zugänglichen Services wichtig, um FIN-WAIT-Ressourcendruck zu reduzieren.
serverFIN begrenzt das Verbindungsverhalten nach einem FIN-Signal vom Backend. Der Standard ist 6 Sekunden. serverFIN höher als clientFIN zu halten ermöglicht mehr Toleranz für graceful Drain beim Backend-Shutdown. Diese Einstellung beeinflusst direkt die Qualität des Verbindungsschlusses bei Traffic-reichen Backend-Pools.
Das Profil-Pool-Bindungsmodell ermöglicht es, denselben Timeout-Standard über mehrere Pools zu teilen. Alle Web-Pools können auf das Web-Profil zeigen, API-Pools auf das API-Profil und WebSocket-Pools auf das WebSocket-Profil. Eine einzige Profiländerung aktualisiert zentral das Timeout-Verhalten jedes daran gebundenen Pools und reduziert Konfigurationsduplikation und -drift.
Die 9 Profilfelder werden in die entsprechenden Laufzeit-Timeout-Direktiven konvertiert — connect, server, client, queue, tunnel, http-keep-alive, http-request, client-fin und server-fin. Operatoren verwalten Werte über das Profil, anstatt individuelle Direktiven zu schreiben, und schaffen so eine konsistente Brücke zwischen GUI und Laufzeitverhalten.
Health-Check-Timing wird durch sein eigenes Timeout-Feld verwaltet und ist unabhängig vom Traffic-Timeout-Profil. Diese Trennung ist wichtig: Probe-Latenz und Produktions-Traffic-Warteverhalten mischen sich nicht. Ein Backend-Health-Check kann kurz gehalten werden, während der tatsächliche Endpoint-serverTimeout lang bleibt, sodass Service-Gesundheit und Benutzer-Traffic mit unterschiedlicher Semantik überwacht werden können.
Timeout-Profile werden zusammen mit ihrem Wertebereich, Standardwerten, Dezimalunterstützung, Tunnel-Semantik, FIN-Balance und Pool-Bindungsmodell betrieben.
Timeout-Felder sind von 0 bis 60.000 Sekunden konfigurierbar. Dieser Bereich erstreckt sich von sub-sekunden-defensiven Einstellungen bis zu Sitzungen von über 16 Stunden, was genug Flexibilität für Long-Poll- und persistente Verbindungsanforderungen bietet.
httpKeepaliveTimeout akzeptiert Dezimalwerte. Ein Wert wie 0,5 Sekunden ermöglicht ein präziseres Idle-Keepalive-Verhalten. Die verbleibenden 8 Timeout-Felder werden als ganzzahlige Sekunden behandelt.
Standardwerte bieten einen sicheren Ausgangspunkt, der für die meisten Web- und API-Traffic-Typen geeignet ist. httpKeepaliveTimeout 120, httpRequestTimeout 30, connectTimeout 20, serverTimeout 90, clientTimeout 90, queueTimeout 60, tunnelTimeout 120, clientFIN 3 und serverFIN 6 Sekunden sind angemessene Basislinien. Für spezialisierte Traffic-Typen sollten diese Werte pro Profil angepasst werden.
tunnelTimeout gilt für getunnelte Verbindungen wie WebSocket und HTTP CONNECT. Es ist nicht dasselbe wie der HTTP-Request- oder Keepalive-Timeout. Es zu niedrig bei langlebigen Verbindungen einzustellen erzeugt Trennungsprobleme.
Im Standardmodell ist serverFIN toleranter als clientFIN. Dies lässt mehr Raum für graceful Drain beim Backend-Shutdown. Bei öffentlich zugänglichen Services können beide Werte aggressiver eingestellt werden, um den Ressourcenverbrauch durch halb-geschlossene Verbindungen zu reduzieren.
TR7 erzwingt keine fertigen Vorlagen. Operatoren erstellen ihre eigenen benannten Profile gemäß ihrem Szenario — web, api, websocket, longpoll oder upload können definiert werden, um den Standards der Organisation zu entsprechen. Das Binden eines Pools an das entsprechende Profil wird gegenüber pro-Service-individuellen Overrides bevorzugt.
Ein Web-Profil kann nahe an den Standardwerten erstellt werden. Keepalive erhält die Benutzererfahrung, während Request- und FIN-Timeout-Werte langsame oder halb-geschlossene Verbindungen begrenzen. Dasselbe Profil kann an mehrere Web-Pools gebunden werden.
Chat-Anwendungen benötigen WebSocket-Verbindungen, die ohne häufige Trennungen offen bleiben. Innerhalb eines WebSocket-Profils wird tunnelTimeout auf einen langen Wert wie 3600 Sekunden eingestellt, während andere HTTP-Timeouts bei ihren Standardwerten bleiben. Langlebige Verbindungen werden nicht mehr durch das HTTP-Keepalive-Fenster eingeschränkt.
Ein Long-Polling-Endpoint kann mehrere Minuten warten, bis das Backend antwortet. Das Setzen von serverTimeout auf 300 Sekunden in einem Longpoll-Profil unterstützt ein 5-Minuten-Wartefenster. Ohne dies bricht ein Standard-API-Timeout die Anfragen zu früh ab.
Daten vom Client können bei großem POST-Body- oder Datei-Upload-Traffic langsam ankommen. In einem Upload-Profil können clientTimeout und bei Bedarf httpRequestTimeout auf 600 Sekunden erhöht werden. Dies verhindert, dass legitime, aber langsame Upload-Operationen abgebrochen werden.
Wenn eine Banking-API eine schnelle Backend-Antwort erwartet, können enge Werte wie connectTimeout 2 Sekunden und serverTimeout 5 Sekunden verwendet werden. Ein langsames oder ausgefallenes Backend blockiert Clients nicht lange. Retry- und Failover-Verhalten wird früher ausgelöst.
Ein defensives Profil kann niedrige Werte wie httpRequestTimeout 5 Sekunden und clientFIN/serverFIN 1 Sekunde verwenden. Diese Struktur begrenzt Muster langsamer Header-Lieferung und halb-geschlossenen Verbindungsverbrauchs. Es reduziert die Angriffsfläche bei öffentlich zugänglichen Services.
9-Achsen-benannte Timeout-Profile für Ihre Web-, API-, WebSocket- und Upload-Pools. Lassen Sie uns ein Live-Setup mit Ihrer eigenen Konfiguration durchgehen.