¿Por qué las conexiones cortas sobrecargan un servidor autoalojado ocupado?

Las conexiones cortas sobrecargan un servidor autoalojado ocupado cuando el trabajo de configuración y desmontaje es mayor que el trabajo útil de la solicitud. Cada nueva sesión puede requerir un apretón de manos TCP, negociación TLS, asignación de socket, autenticación, registro y limpieza, incluso si la respuesta contiene solo unos pocos bytes.

Una transferencia de archivos larga paga esos costos una vez y luego mueve una cantidad sustancial de datos. Las comprobaciones de estado, paneles de control, clientes móviles, recursos web y llamadas API mal agrupadas pueden crear cientos de sesiones pequeñas, obligando al servidor a repetir costos fijos mientras mantiene el estado de conexiones recientemente cerradas.

La causa principal: cada nueva conexión repite trabajo fijo

Una conexión TCP comienza con un apretón de manos antes de que los datos de la aplicación puedan fluir. HTTPS añade negociación criptográfica, y la aplicación puede entonces crear una sesión, verificar credenciales, abrir una conexión a la base de datos o cargar el estado del usuario. Para una respuesta pequeña, estas etapas de configuración pueden dominar tanto la latencia como el tiempo de CPU.

La sobrecarga de conexiones de corta duración se vuelve significativa cuando el servidor la repite a una alta tasa. El resultado visible puede ser un aumento en la carga promedio y respuestas más lentas, aunque el rendimiento de la red permanezca muy por debajo de la velocidad del enlace.

La reutilización de conexiones cambia esa proporción. Varias solicitudes pueden compartir un transporte establecido y, donde se soporte, una sesión cifrada. El servidor pasa más tiempo realizando trabajo de aplicación y menos tiempo asignando y retirando el estado de la conexión.

Keep-Alive reduce los apretones de manos pero necesita límites sensatos

HTTP keep-alive permite que múltiples solicitudes usen una conexión TCP en lugar de abrir una nueva conexión para cada objeto o llamada API. Esto reduce los viajes de ida y vuelta y evita que la configuración repetida se multiplique a medida que una página o panel carga muchos recursos.

Las conexiones HTTP keepalive reducen la latencia reutilizando transportes establecidos. El límite es el estado inactivo: los tiempos de espera excesivamente largos pueden dejar muchos sockets sin usar ocupando memoria y ranuras de conexión, por lo que la reutilización necesita un tiempo de espera y un límite de solicitudes que coincidan con el patrón del cliente.

El agrupamiento debe existir en ambos lados de una llamada de servicio interna. Un proxy inverso puede reutilizar conexiones de cliente mientras abre una conexión nueva hacia arriba para cada solicitud, moviendo la rotación en lugar de eliminarla. Los controladores de base de datos y clientes API pueden crear la misma dispersión oculta dentro de una aplicación autoalojada.

Las conexiones cerradas pueden dejar estado en el kernel

Cerrar una sesión TCP no siempre borra su estado inmediatamente. El punto final que cierra activamente puede mantener una entrada TIME_WAIT para que los paquetes retrasados de la conexión antigua no se confundan con una conexión posterior que use la misma tupla de dirección y puerto.

Una gran población TIME_WAIT por lo tanto señala una rotación frecuente de conexiones en lugar de un servidor roto automáticamente. A altas tasas puede consumir memoria, complicar la observabilidad o agotar los puertos efímeros de un cliente antes de que las entradas antiguas expiren.

Modificar los temporizadores del kernel rara vez es el primer paso. Identifique qué cliente o servicio está abriendo conexiones, confirme si la reutilización está habilitada y verifique si los reintentos o las sondas de salud están multiplicando la tasa. Cambios agresivos en los temporizadores pueden ocultar el patrón mientras debilitan la protección TCP contra paquetes retrasados.

La automatización puede crear rotación de conexiones en un servidor aparentemente inactivo

Un servidor doméstico puede recibir solicitudes de comprobaciones de salud de contenedores, agentes de monitoreo, pestañas del navegador, widgets de teléfono, clientes multimedia y proxies inversos incluso cuando ninguna persona lo está usando activamente. Si cada sonda abre una nueva conexión cifrada, un intervalo corto convierte una comprobación ligera en trabajo continuo de configuración.

Las mediciones de conexiones TCP de corta duración muestran cómo los clientes automatizados y scripts pueden favorecer sesiones nuevas repetidas sobre las mantenidas. En un servidor autoalojado pequeño, el mismo comportamiento es visible a menor escala porque los límites de CPU, memoria y trabajadores son menores.

Cuente conexiones aceptadas por segundo, CPU usada en el apretón de manos, sockets abiertos, entradas TIME_WAIT y solicitudes por conexión. Si la tasa de conexiones aumenta mucho más rápido que el volumen de solicitudes, inspeccione el agrupamiento y el comportamiento de reintentos. Si el servicio está expuesto a internet, primero confirme el límite de exposición con una verificación de exposición del servidor doméstico para que los escaneos no deseados no se confundan con clientes normales.

Preguntas frecuentes

¿Son siempre un problema muchas conexiones cortas?

No. Los servidores modernos pueden manejar muchas conexiones, y las sesiones cortas pueden ser apropiadas para clientes poco frecuentes. Se convierten en un problema cuando la tasa de conexiones consume CPU, puertos, trabajadores o memoria más rápido de lo que el servidor puede reciclarlos.

¿El HTTP/2 elimina la sobrecarga de conexiones?

HTTP/2 puede multiplexar muchas solicitudes sobre menos conexiones, lo que reduce la rotación. Los clientes, proxies y servicios ascendentes deben realmente negociar y reutilizarlo; los saltos internos pueden seguir usando conexiones HTTP/1.1 separadas.

¿Debería reducir el tiempo de espera TIME_WAIT?

No antes de identificar la fuente de la rotación. TIME_WAIT es un comportamiento normal del protocolo. El agrupamiento de conexiones, transportes persistentes, intervalos de sondas y límites de reintentos suelen abordar la carga de trabajo más directamente que acortar los temporizadores de seguridad del kernel.