Su grupo de conexiones PostgreSQL de repente devuelve "el servidor cerró la conexión inesperadamente". Su cliente WebSocket se vuelve a conectar cada diez minutos. Su API gRPC funciona localmente, pero en producción detrás de un balanceador de carga, las transmisiones largas se cortan sin registros de la aplicación.
El culpable no siempre es un error de código. A menudo, un dispositivo intermedio cancelaba una sesión TCP inactiva y nadie se daba cuenta, hasta la siguiente escritura.
Tiempo de inactividad: quién lo corta y cuándo
| Capa | Tiempo de espera de inactividad típico | Consecuencia |
|---|---|---|
| Caja NAT / 4G | 30 segundos – 5 minutos | Conexión “zombi” del lado de la aplicación |
| Nube de equilibrador de carga | 60 – 3500 | Apagado silencioso a mitad de solicitud |
| Cortafuegos con estado | Varía | Caída sin RST propio |
| Servidor de base de datos | horas | Menos común en default |
Sin tráfico, la sesión desaparece de la tabla de estados del intermediario. Su proceso todavía cree que está conectado.
Keepalive existe para detectar tempranamente que la ruta está muerta, no para reemplazar una arquitectura que mantiene el tráfico útil.
TCP keepalive a nivel de kernel
Linux envía sondas TCP vacías después de un período de inactividad (tcp_keepalive_time, valor predeterminado ~7200 s, a menudo demasiado largo para la web).
Configuraciones útiles:
sysctl -w net.ipv4.tcp_keepalive_time=600
sysctl -w net.ipv4.tcp_keepalive_intvl=30
sysctl -w net.ipv4.tcp_keepalive_probes=5
Habilite SO_KEEPALIVE en sockets de servidor críticos (PostgreSQL tcp_keepalives_*, Redis, proxies).
Limitación: keepalive no siempre atraviesa servidores proxy HTTP que terminan TCP. Detrás de nginx, configure también proxy_read_timeout y proxy_send_timeout.
Latido del corazón de la aplicación: cuando TCP no es suficiente
Para conexiones WebSocket, SSE o DB mediante pooler:
- WebSocket: ping/pong RFC 6455 o mensaje JSON periódico (< intervalo NAT).
- ORM Pools:
pool_pre_ping(SQLAlchemy), validación de consultas al finalizar la compra. - Colas de mensajes: latido AMQP, reconocimiento regular del consumidor.
Calibre el intervalo bajo el tiempo de espera más corto de la cadena (NAT < LB < aplicación).
Equilibrador de carga y host en la nube
Las ofertas administradas tienen tiempos de espera fijos:
- AWS ALB inactivo: hasta 4000 s configurables.
- Valor predeterminado de nginx: 60 s en proxy.
- Cloudflare: 100 s en conexiones HTTP clásicas.
Lea el documento de su capa y luego configure keepalive + heartbeat en consecuencia. Abra un ticket de soporte del host si el tiempo de espera predeterminado es incompatible con sus flujos largos.
La parte superior: es posible que una conexión "abierta" ya esté muerta
La solidez final permanece en su código de reintento y reconexión.
Decide y avanza sin puntos ciegos
- Asigne los tiempos de espera de NAT, LB, proxy y DB en un diagrama.
- Habilite SO_KEEPALIVE + configuración de sysctl adaptada en los servidores.
- Agregue latidos de la aplicación para WebSocket y grupos de larga duración.
- Prueba de carga con conexiones inactivas deliberadas.
Compare los hosts y sus límites de red en nuestro directorio.
Preguntas frecuentes
¿Cuál es la diferencia entre TCP keepalive y latido de la aplicación?
Keepalive = sondeos del kernel para detectar un par muerto. Heartbeat = mensaje comercial que también puede medir la latencia o actualizar una sesión.
¿Por qué mis conexiones de base de datos se caen después de 5 o 15 minutos?
NAT, firewall o balanceador de carga cierran las sesiones inactivas; el cliente cree que la conexión está abierta.
¿Qué configuración de Linux debo ajustar?
tcp_keepalive_time, tcp_keepalive_intvl, tcp_keepalive_probes: tiempo más bajo si los tiempos de espera intermedios son cortos.
¿Keepalive consume mucho ancho de banda?
No: unos pocos bytes por sonda; Evite un intervalo demasiado agresivo en miles de conexiones.
Una conexión útil no es aquella que permanece abierta en una tabla, sino aquella que sobrevive a NAT silenciosas entre dos solicitudes reales.