HTTP keep-alive y reutilización de conexiones: pools, timeouts de inactividad y la condición de carrera de la conexión obsoleta

Qué es

Según la RFC 9112, HTTP/1.1 usa conexiones persistentes por defecto: varias peticiones y respuestas viajan por una misma conexión. La conexión permanece abierta salvo que un mensaje incluya la opción de conexión close o que el otro extremo hable HTTP/1.0 sin keep-alive; un cliente o servidor que no admita persistencia debe enviar close en cada mensaje. Para que la conexión siga siendo persistente, cada mensaje necesita una longitud definida por sí mismo (Content-Length o codificación chunked). Los servidores suelen cerrar las conexiones inactivas tras un timeout cuya duración la especificación no restringe, las conexiones pueden cerrarse en cualquier momento y los clientes deberían limitar el número de conexiones simultáneas a un mismo servidor. MDN describe los mismos modelos y señala que el pipelining, aunque está definido, no está activado por defecto en los navegadores modernos.

Por qué importa

Cada conexión nueva cuesta un handshake TCP y, con TLS, un handshake criptográfico adicional, además de un socket en TIME_WAIT después. Un cliente que hace muchas peticiones pequeñas a un mismo host puede gastar más tiempo en establecer conexiones que en transferir datos, y un servidor puede dedicar más CPU a los handshakes TLS que a las peticiones. La reutilización elimina ese coste de cada petición posterior a la primera.

Cómo aplicarlo

• Mantén un único objeto cliente con un pool de conexiones durante toda la vida del proceso (requests.Session, httpx.Client, un Agent de Node con keep-alive) en lugar de crear uno por llamada. La documentación de Requests indica que el keep-alive es automático dentro de una sesión.
• Consume o cierra el cuerpo de cada respuesta. La misma documentación señala que las conexiones solo vuelven al pool cuando se han leído todos los datos del cuerpo; una respuesta en streaming sin leer ocupa una conexión.
• Fija el timeout de inactividad del cliente por debajo del del servidor y del proxy. Si no, el cliente elige una conexión que el servidor acaba de cerrar, y la primera petición tras un periodo de inactividad falla con un reset. La RFC 9112 dice que las implementaciones deberían anticipar estos cierres asíncronos y remite a la RFC 9110 para saber cuándo una petición puede reintentarse automáticamente; reintenta una sola vez y solo peticiones idempotentes.
• Limita el pool por host a lo que el servidor acepta, y recicla las conexiones tras cierto número de peticiones o una antigüedad máxima, para que las conexiones de larga duración no dejen a un cliente fijado a un único backend detrás de un balanceador de carga.
• Revisa las cabeceras de la respuesta: un servidor que responde Connection: close inutiliza el pool sin avisar.

Trampas

Los dispositivos intermedios descartan conexiones inactivas sin avisar a ninguno de los extremos; la pregunta abierta sobre los timeouts de inactividad de NAT trata este tema. Una conexión TLS autenticada con un certificado de cliente queda ligada a esa identidad; no compartas una conexión así entre tenants. HTTP/2 multiplexa muchos streams en una sola conexión, por lo que sus reglas de pooling difieren de las de HTTP/1.1.