Uw PostgreSQL-verbindingspool retourneert plotseling "server heeft de verbinding onverwacht gesloten". Uw WebSocket-client maakt elke tien minuten opnieuw verbinding. Uw gRPC API werkt lokaal, maar in productie achter een load balancer worden lange streams afgesloten zonder applicatielogboeken.
De boosdoener is niet altijd een codefout. Vaak maakte een tussenliggend apparaat een inactieve TCP-sessie kapot, en niemand merkte het – tot de volgende schrijfbeurt.
Time-out bij inactiviteit: wie onderbreekt het, en wanneer
| Laag | Typische time-out voor inactiviteit | Gevolg |
|---|---|---|
| NAT-box / 4G | 30 sec – 5 min | “Zombie”-verbinding aan de appzijde |
| Load balancer-cloud | Jaren 60 – 3500 | Stille uitschakeling halverwege verzoek |
| Stateful firewall | Varieert | Drop zonder eigen RST |
| DB-server | uur | Minder vaak voorkomend bij wanbetaling |
Zonder verkeer verdwijnt de sessie uit de statustabel van de tussenpersoon. Je proces denkt nog steeds dat het verband houdt.
Keepalive is er om vroegtijdig te detecteren dat het pad dood is – niet om een architectuur te vervangen die nuttig verkeer onderhoudt.
TCP keepalive op kernelniveau
Linux verzendt lege TCP-tests na een periode van inactiviteit (tcp_keepalive_time, standaard ~7200 s - vaak te lang voor internet).
Handige instellingen:
sysctl -w net.ipv4.tcp_keepalive_time=600
sysctl -w net.ipv4.tcp_keepalive_intvl=30
sysctl -w net.ipv4.tcp_keepalive_probes=5
Schakel SO_KEEPALIVE in op kritieke server-sockets (PostgreSQL tcp_keepalives_*, Redis, proxy's).
Beperking: keepalive passeert niet altijd HTTP-proxy's die TCP beëindigen. Stel achter nginx ook proxy_read_timeout en proxy_send_timeout in.
Applicatiehartslag: wanneer TCP niet genoeg is
Voor WebSocket-, SSE- of DB-verbindingen via pooler:
- WebSocket: RFC 6455 ping/pong of periodiek JSON-bericht (< NAT-interval).
- ORM Pools:
pool_pre_ping(SQLAlchemy), queryvalidatie bij het afrekenen. - Berichtenwachtrijen: AMQP-hartslag, reguliere consumentenbevestiging.
Kalibreer het interval onder de kortste time-out in de keten (NAT < LB < app).
Load balancer en cloudhost
Beheerde aanbiedingen hebben vaste time-outs:
- AWS ALB inactief: tot 4000 s configureerbaar.
- nginx standaard: 60 s op proxy.
- Cloudflare: 100 s op klassieke HTTP-verbindingen.
Lees het document voor uw laag en stel vervolgens keepalive + hartslag dienovereenkomstig in. Open een hostondersteuningsticket als de standaardtime-out niet compatibel is met uw lange stromen.
De bovenkant: een “open” verbinding is mogelijk al dood
De uiteindelijke robuustheid blijft in uw code voor opnieuw proberen en opnieuw verbinden.
Beslis en ga vooruit zonder blinde vlek
- Maak de time-outs van NAT, LB, proxy en DB in een diagram.
- SO_KEEPALIVE inschakelen + aangepaste sysctl-instellingen op servers.
- Voeg applicatiehartslag toe voor WebSocket en long-live-pools.
- Belastingstest met opzettelijke inactieve verbindingen.
Vergelijk hosts en hun netwerklimieten in onze overzicht.
Veelgestelde vragen
Wat is het verschil tussen TCP keepalive en applicatiehartslag?
Keepalive = kernelsondes om een dode peer te detecteren. Heartbeat = zakelijke boodschap die ook de latentie kan meten of een sessie kan vernieuwen.
Waarom vallen mijn DB-verbindingen na 5 of 15 minuten weg?
NAT, firewall of load balancer sluit inactieve sessies; de client denkt dat de verbinding open is.
Welke Linux-instellingen moet ik aanpassen?
tcp_keepalive_time, tcp_keepalive_intvl, tcp_keepalive_probes — lagere tijd bij korte tussentijdse time-outs.
Verbruikt keepalive veel bandbreedte?
Nee – een paar bytes per probe; vermijd een te agressief interval op duizenden verbindingen.
Een nuttige verbinding is niet een verbinding die open blijft in een tabel; het is een verbinding die stille NAT's overleeft tussen twee daadwerkelijke verzoeken.