Ir al contenido 
TCP Keepalive determina la rapidez con la que un servidor reconoce y finaliza las sesiones TCP inactivas, una palanca de control que tiene un impacto directo en el consumo de recursos, la latencia y el comportamiento del tiempo de inactividad en el alojamiento. Con valores de inactividad, intervalo y sonda adecuados, reduzco los puntos muertos de conexión, evito caídas de NAT y mantengo las aplicaciones web en Configuraciones de alojamiento accesible de forma fiable.
Puntos centrales
- ParámetrosFijar ralentí, intervalo, sondas de forma selectiva
- DemarcaciónTCP Keepalive vs. HTTP Keep-Alive
- Por tomaAnulaciones por servicio/podo Kubernetes
- Cortafuegos/NATConsidera activamente los tiempos muertos
- MonitoreoMedición, pruebas de carga, ajuste iterativo
Cómo funciona TCP Keepalive
Activo Keepalive a nivel de socket o de sistema para que la pila envíe pequeñas sondas a intervalos definidos cuando está inactiva. Tras un tiempo de espera ajustable (inactividad), el sistema envía la primera comprobación; a continuación, le siguen otras sondas en el intervalo definido hasta alcanzar el número de intentos. Si la estación remota permanece muda, finalizo la conexión y devuelvo los descriptores de archivo y las memorias intermedias en el archivo Núcleo libre. La lógica es claramente diferente a la de las retransmisiones, porque Keepalive comprueba el estado de liveness de un flujo que, de otro modo, estaría inactivo. Especialmente en entornos de alojamiento con muchas sesiones simultáneas, este comportamiento evita las fugas sigilosas, que de otro modo sólo notaría con alta liveness. Carga sentir.
Por qué Keepalive cuenta en el alojamiento
Los clientes defectuosos, las redes móviles y las pasarelas NAT agresivas suelen dejar atrás Conexiones zombis, que permanecen abiertos durante mucho tiempo sin keepalive. Esto cuesta sockets abiertos, RAM y CPU en los procesos accept, worker y proxy, lo que alarga los tiempos de respuesta. Utilizo valores adecuados para eliminar estos cuerpos muertos desde el principio y mantener abiertos listeners, backends y upstreams. receptivo. El efecto es especialmente notable durante los picos de carga porque menos conexiones muertas llenan las colas. Por lo tanto, planifico Keepalive junto con los tiempos de espera HTTP y TLS y aseguro un armonioso Interacción en todas las capas.
Parámetros Sysctl: valores prácticos
Linux proporciona valores por defecto muy largos que se utilizan en productivos Entornos de alojamiento rara vez encajan. Para los servidores web, suelo fijar el tiempo de inactividad mucho más corto para poder borrar a tiempo las sesiones colgadas. Mantengo moderado el intervalo entre sondas para reconocer rápidamente los fallos pero sin inundar la red con comprobaciones. Equilibro el número de sondas entre las falsas alarmas y el tiempo de detección; menos sondas acortan el tiempo hasta que el Recursos. Para IPv6, presto atención a las respectivas variables net.ipv6 y mantengo la coherencia entre ambos protocolos.
| Parámetros | Estándar (Linux) | Recomendación de alojamiento | Beneficio |
|---|---|---|---|
| tcp_keepalive_time | 7200s | 600-1800s | Cuando se envía la primera muestra después de Idle |
| tcp_keepalive_intvl | 75s | 10-60s | Distancia entre sondas individuales |
| tcp_keepalive_probes | 9 | 3-6 | Máximo de intentos fallidos antes de cerrar |
Establezco los valores de base en todo el sistema y los aplico permanentemente a través de sysctl para que los reinicios no descarten el trabajo de ajuste. Además, documento los valores iniciales y mido los efectos sobre Tasas de error y latencias. Esto me permite mantener un equilibrio entre detección rápida y tráfico de red adicional. A menudo utilizo las siguientes líneas como punto de partida y las ajusto posteriormente para cada carga de trabajo:
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 5
sysctl -p
Ajuste por socket y plataforma
Los valores globales por defecto rara vez son suficientes para mí; yo los establezco por servicio Por toma-para que los backends sensibles vivan más tiempo mientras que los frontends se limpian rápidamente. En Python, Go o Java, configuro SO_KEEPALIVE y las opciones TCP específicas directamente en el socket. En Linux, controlo a través de TCP_KEEPIDLE, TCP_KEEPINTVL y TCP_KEEPCNT, mientras que Windows funciona a través de claves de registro (KeepAliveTime, KeepAliveInterval). En Kubernetes, sobrescribo la configuración en un pod o despliegue específico para tratar las puertas de enlace API de corta duración de forma diferente a las de larga duración. Base de datos-proxies. Para las configuraciones de contenedores, también compruebo las tablas NAT del host y los plugins CNI porque los flujos inactivos a menudo se eliminan antes de lo que me gustaría.
# Ejemplo (Python, Linux)
importar socket
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPIDLE, 60)
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPINTVL, 30)
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPCNT, 5)
HTTP Keep-Alive frente a TCP Keepalive
HTTP Keep-Alive mantiene las conexiones abiertas para múltiples peticiones, mientras que TCP Keepalive proporciona comprobaciones puras de liveness a nivel de transporte. Ambos mecanismos se complementan, pero funcionan con objetivos y temporizadores diferentes. En HTTP/2 y HTTP/3, las tramas PING asumen en parte el papel de Keepalive, pero sigo asegurando adicionalmente la capa TCP. Establezco el tiempo de espera HTTP según la vista de la aplicación, mientras que establezco los valores TCP basándome en la liberación económica de Recursos alinear. Si desea profundizar en la página HTTP, puede encontrar una guía útil en Tiempo de espera HTTP Keep-Alive.
Ajuste del tiempo de espera de la red: práctico
Para los frontales de alojamiento web clásicos, suelo trabajar con 300s de inactividad, 30-45s de intervalo y 4-6 sondas para terminar las sesiones inactivas rápidamente y Colas magra. Las conexiones a bases de datos tienen más paciencia para que las fases cortas de ocupación no provoquen desconexiones innecesarias. En las pasarelas de borde o API, también acorto los tiempos de espera porque hay muchas conexiones de corta duración. Armonizo los valores con los tiempos de espera del protocolo TLS, los tiempos de espera de lectura/escritura y los límites de tiempo del flujo ascendente para que no haya contradicciones en los límites de las capas. Para la optimización paso a paso, se ha creado una compacta Flujo de ajuste, que utilizo en las ventanas de mantenimiento.
Cortafuegos, NAT y tiempos de espera en la nube
Muchos cortafuegos y pasarelas NAT cortan los flujos inactivos después de 300-900 segundos, por lo que me Keepalive para que mi intervalo sea menor que este. De lo contrario, la aplicación no reconocerá la terminación hasta la siguiente petición y provocará reintentos innecesarios. En los balanceadores de carga en la nube, compruebo los parámetros TCP o de conexión inactiva y los comparo con los valores de sysctl y proxy. En configuraciones anycast o multi-AZ, compruebo si los cambios de ruta conducen a estaciones remotas aparentemente muertas y aumento específicamente el número de muestras para estas zonas. Documento la cadena de cliente, proxy, cortafuegos y backend para poder Causas para gotas rápidamente.
Integración en la configuración del servidor web
Apache, Nginx y HAProxy organizan la persistencia HTTP a nivel de aplicación, mientras que el sistema operativo TCP Keepalive cumple. En Apache, activo KeepAlive, limito KeepAliveRequests y mantengo KeepAliveTimeout corto para que los trabajadores sean liberados rápidamente. Utilizo Nginx con un KeepAliveTimeout corto y un KeepAliveRequests moderado para una reutilización eficiente. En HAProxy, utilizo opciones de socket como tcpka o valores predeterminados del sistema para que los tiempos de espera de transporte coincidan con la política del proxy. Para aspectos más profundos del servidor web, se puede consultar la página Guía de ajuste del servidor web, que combino con mis personalizaciones TCP.
Supervisión, pruebas y métricas
Mido el efecto de cada ajuste y no me baso en Intuición. ss, netstat y lsof me muestran cuántas conexiones ESTABLISHED, FIN_WAIT y TIME_WAIT hay y si las fugas están creciendo. En métricas, controlo abortos, RST, retransmisiones, latencia P95/P99 y longitudes de cola; si un valor alcanza sus límites, paso específicamente a Idle, Interval o Probes. Utilizo pruebas de carga sintéticas (por ejemplo, ab, wrk, Locust) para simular patrones de uso reales y verificar si el ajuste cumple las métricas objetivo. Despliego los cambios por etapas y comparo las series temporales antes de global Distribuir los valores por defecto en todos los hosts.
Imágenes de errores y resolución de problemas
Si fijo intervalos demasiado cortos, inflo el Tráfico de red y aumentan el riesgo de que los fallos temporales se interpreten como fallos. Si hay muy pocas sondas, cierro conexiones activas en redes lentas, lo que los usuarios perciben como un mensaje de error esporádico. Por otro lado, los tiempos de espera demasiado largos provocan la congestión de los sockets y el aumento de los retrasos en la aceptación. Compruebo los registros de RST de cliente/servidor, ECONNRESET y ETIMEDOUT para reconocer la dirección. Si afecta principalmente a los usuarios móviles, ajusto las sondas y los intervalos, porque hay Puntos muertos y las afecciones del sueño se producen con mayor frecuencia.
Valores predeterminados seguros para varias cargas de trabajo
Empiezo con valores conservadores pero compatibles con la producción y los refino tras medir el Carga de trabajo. Las API web suelen requerir tiempos de inactividad cortos, las bases de datos bastante más largos. Los proxies entre zonas o proveedores se benefician de un número ligeramente superior de sondas para hacer frente a la fluctuación de la ruta. Para las aplicaciones interactivas, reduzco el intervalo y aumento el número de sondas, de modo que advierto los errores más rápidamente, pero no los cierro antes de tiempo. La tabla me proporciona una orientación compacta, que ajusto durante el funcionamiento.
| Tipo de servidor | Ocioso | Intervalo | Probes | Nota |
|---|---|---|---|---|
| Alojamiento web frontend | 300-600s | 30-45s | 4-6 | Sesiones cortas, gran volumen |
| Pasarela API | 180-300s | 20-30s | 5-6 | Muchas fases de inactividad, se despejan rápidamente |
| Proxy de base de datos | 900-1800s | 45-60s | 3-5 | Establecer una conexión es costoso, demuestre paciencia |
| Pod Kubernetes | 600-900s | 30-45s | 4–5 | Sincronización con los tiempos de espera de CNI/LB |
TCP_USER_TIMEOUT y retransmisión backoff
Además de Keepalive, utilizo específicamente lo siguiente para las conexiones que transportan datos TCP_USER_TIMEOUT, para controlar el tiempo que los datos no confirmados pueden permanecer en el socket antes de que la conexión se cancele activamente. Esto es particularmente importante para proxies y APIs, que no deben hacer bucles de datos colgados durante minutos y minutos. A diferencia de Keepalive (que comprueba la liveness durante la inactividad), TCP_USER_TIMEOUT tiene efecto cuando los datos están fluyendo pero no se devuelven ACKs - por ejemplo en caso de fallos asimétricos. Yo lo configuro por toma ligeramente por debajo de los tiempos de espera de lectura/escritura de la aplicación para que el nivel de transporte no espere más que la lógica de la aplicación en caso de error.
# Ejemplo (Go, Linux) - Keepalive y TCP_USER_TIMEOUT
d := net.Marcador{
Tiempo de espera: 5 * tiempo.Segundo,
KeepAlive: 30 * time.Second,
Control: func(red, dirección cadena, c syscall.RawConn) error {
var err error
c.Control(func(fd uintptr) {
// se permiten 20s de datos no confirmados
err = syscall.SetsockoptInt(int(fd), syscall.IPPROTO_TCP, 0x12, 20000) // TCP_USER_TIMEOUT
})
return err
},
}
conn, _ := d.Dial("tcp", "ejemplo:443")
No olvido que el backoff TCP (extensión RTO) y los reintentos (tcp_retries2) también influyen en el comportamiento en caso de pérdida de paquetes. Los tiempos de espera de usuario demasiado cortos pueden provocar caídas en redes difíciles, aunque la estación remota sea accesible. Por lo tanto, sólo los establezco de forma estricta cuando busco deliberadamente una detección rápida de errores (por ejemplo, en el proxy de borde).
IPv6 y funciones del sistema operativo
Las mismas opciones por socket (TCP_KEEPIDLE, TCP_KEEPINTVL, TCP_KEEPCNT) se aplican para IPv6. Dependiendo de la versión del kernel, los valores globales por defecto para v4 y v6 se aplican conjuntamente; yo lo compruebo con ss -o a conexiones reales. En Windows, personalizo los valores por defecto a través del registro (KeepAliveTime, KeepAliveInterval) y uso SIO_KEEPALIVE_VALS para sockets individuales. Las opciones a veces se llaman de forma diferente en los derivados de BSD, pero la semántica sigue siendo la misma. Es importante verificar para cada plataforma si las anulaciones de la aplicación realmente superan los valores predeterminados del sistema y si los tiempos de ejecución del contenedor heredan los espacios de nombres correctamente.
WebSockets, gRPC y streaming
Los flujos de larga duración (WebSocket, gRPC, eventos enviados por el servidor) se benefician especialmente de una buena dosificación de los keepalives. Empiezo en dos niveles: La aplicación envía pings/PONGs periódicos (por ejemplo, a nivel de WebSocket), mientras que la capa TCP asegura con intervalos moderados. Esto evita que los NAT eliminen flujos silenciosamente. Para los clientes móviles, aumento el número de sondas y selecciono intervalos más largos para tener en cuenta los modos de ahorro de energía. Para gRPC/HTTP-2, coordino HTTP/2 PINGs con TCP Keepalive para no sondear dos veces de forma demasiado agresiva y agotar las baterías.
Tablas Conntrack, kernel y NAT
En hosts Linux con seguimiento activo de la conexión, una conexión demasiado corta nf_conntrack-timeout puede provocar una caída prematura, aunque la aplicación piense más tiempo. Por ello, sincronizo los temporizadores correspondientes (por ejemplo. nf_conntrack_tcp_timeout_established) con mis intervalos keepalive para que una muestra llegue con seguridad antes de la fecha límite conntrack. En nodos con NAT fuerte (NodePort, egress NAT) planifico el tamaño de la tabla conntrack y los hash buckets para evitar presión global bajo carga. Los ajustes limpios de keepalive alivian estas tablas de forma apreciable.
Ejemplo: unidades proxy y servidor web
En HAProxy, activo específicamente transport-side keepalive y mantengo los tiempos de espera HTTP consistentes:
Extracto # (HAProxy)
por defecto
timeout cliente 60s
timeout servidor 60s
timeout connect 5s
option http-keep-alive
option tcpka # Habilitar TCP keepalive (utilizar valores predeterminados del sistema operativo)
aplicación backend
server s1 10.0.0.10:8080 check inter 2s fall 3 rise 2
En Nginx, creo que la reutilización es eficiente sin atar a los trabajadores:
# extracto (Nginx)
keepalive_timeout 30s;
keepalive_requests 1000;
proxy_read_timeout 60s;
proxy_send_timeout 60s;
Me aseguro de que los tiempos de espera de transporte y aplicación encajen de forma lógica: Evitar las „líneas muertas“ es tarea de TCP/Keepalive, mientras que los tiempos de espera de las aplicaciones se corresponden con la lógica empresarial y las expectativas de los usuarios.
Observabilidad en la práctica
Verifico el trabajo de Keepalive en directo en el host:
- ss:
ss -tin 'sport = :443'espectáculos con-oel temporizador (por ejemplo. timer:(keepalive,30seg,0)), número de reintentos y Q de envío/recepción. - tcpdumpFiltro una conexión inactiva y veo periódicamente pequeños paquetes/ACKs durante las fases de inactividad. Esto me permite reconocer si las sondas activan el NAT a tiempo.
- Registros/MétricasCorrelaciono los picos de RST/timeout con los cambios en idle/interval/probes. Una caída en los sockets abiertos a carga constante muestra un ordenamiento exitoso.
Para realizar pruebas reproducibles, simulo fallos de conexión (por ejemplo, caída de la interfaz, iptables DROP) y observo con qué rapidez los trabajadores/procesos liberan recursos y si los reintentos funcionan correctamente.
Planificación de recursos y capacidades
Keepalive es sólo una parte del equilibrio. Me aseguro de que ulimit/nofile, fs.archivo-max, net.core.somaxconn y tcp_max_syn_backlog coinciden con mi número de conexión. Los tiempos de inactividad demasiado largos ocultan aquí déficits, mientras que los valores demasiado cortos aportan una supuesta estabilidad pero golpean duramente a los usuarios. Planifico los buffers (Recv-/Send-Q) y las reservas de FD con escenarios de carga y mido cuántas conexiones inactivas simultáneas pueden soportar realmente mis nodos antes de que la GC/Worker y las colas de aceptación se resientan.
Cuando no confío (sólo) en TCP Keepalive
Para el tráfico puramente interno sin NAT, un bajo número de conexiones y tiempos de espera de aplicación claros, a veces prescindo de keepalives agresivos y dejo la detección a la aplicación (por ejemplo, heartbeats a nivel de protocolo). Por el contrario, en escenarios edge y móviles, priorizo intervalos cortos, pocas sondas y añado HTTP/2 PINGs o WebSocket pings. Es importante que nunca sintonice de forma aislada: Los valores de Keepalive deben armonizar con los reintentos, los disyuntores y las estrategias de backoff, de modo que pueda detectar errores rápidamente pero sin que el sistema se tambalee.
Estrategia de despliegue y validación
Introduzco los nuevos valores por defecto paso a paso: Primero los hosts Canary, luego una AZ/zona, luego toda la flota. Las comparaciones antes/después incluyen conexiones abiertas, CPU en modo kernel, latencia P95/P99, tasas de error y retransmisiones. En Kubernetes, hago pruebas mediante anotaciones pod o contenedores init que establecen espacios de nombres sysctl antes de cambiar en todo el nodo. De este modo minimizo el riesgo y garantizo resultados reproducibles, no solo mejoras percibidas.
Brevemente resumido
Con un TCP Con la configuración de Keepalive, elimino antes las conexiones inactivas, reduzco la presión sobre los recursos y estabilizo los tiempos de respuesta. Elijo tiempos de espera cortos para el frontend, valores más largos para los backends con estado y me aseguro con intervalos moderados y pocas o medianas sondas. Armonizo los valores con los tiempos de espera de HTTP, TLS y proxy y los mantengo por debajo de los límites de inactividad de cortafuegos y NAT. Después de cada ajuste, mido los efectos notables sobre la latencia, los errores y la CPU en lugar de confiar en mi instinto. Así es como consigo un fiable Plataforma que soporta mejor los picos de carga y sirve los flujos de usuarios de manera uniforme.
