Conexión persistente HTTP

La conexión persistente HTTP, también llamada HTTP keep-alive o reutilización de la conexión HTTP (HTTP connection reuse), es la idea de usar una única conexión TCP para enviar y recibir múltiples solicitudes/respuestas HTTP, en lugar de abrir una nueva conexión para cada par de solicitudes/respuestas. El protocolo HTTP/2 más nuevo usa la misma idea y la lleva más allá para permitir que múltiples solicitudes/respuestas simultáneas se multiplexen a través de una sola conexión.

Operación

HTTP 1.0

Bajo HTTP 1.0, el servidor siempre debe cerrar las conexiones después de enviar la respuesta.

Desde finales de 1996, los desarrolladores de productos populares (navegadores, servidores web, etc.) que utilizan HTTP/1.0 comenzaron a agregar una extensión no oficial (al protocolo) llamada "keep-alive" para permitir la reutilización de una conexión para múltiples solicitudes/respuestas.

Si el cliente admite keep-alive, agrega un encabezado adicional a la solicitud:

Conexión: mantener vivo

Cuando el servidor recibe esta solicitud y genera una respuesta, si es compatible con keep-alive, también agrega el mismo encabezado anterior a la respuesta. Después de esto, la conexión no se interrumpe, sino que se mantiene abierta. Cuando el cliente envía otra solicitud, utiliza la misma conexión.

Esto continuará hasta que el cliente o el servidor decidan que la conversación ha terminado y en este caso omiten el "Connection:"encabezado del último mensaje enviado o, mejor, le agregan la palabra clave "cerrar":

Conexión: cerrar

Después de eso, la conexión se cierra siguiendo las reglas especificadas.

Desde 1997, las diversas versiones de las especificaciones HTTP/1.1 reconocieron el uso de esta extensión no oficial e incluyeron algunas advertencias sobre la interoperabilidad entre los clientes/servidores HTTP/1.0 (keep-alive) y HTTP/1.1.

HTTP 1.1

En HTTP 1.1, todas las conexiones se consideran persistentes a menos que se declare lo contrario. Las conexiones persistentes de HTTP no usan mensajes de mantenimiento separados, solo permiten múltiples solicitudes para usar una sola conexión. Sin embargo, el tiempo de espera de conexión predeterminado de Apache httpd 1.3 y 2.0 es de tan solo 15 segundos y solo 5 segundos para Apache httpd 2.2 y superior. La ventaja de un tiempo de espera corto es la capacidad de entregar múltiples componentes de una página web rápidamente sin consumir recursos para ejecutar varios procesos o subprocesos del servidor durante demasiado tiempo.

Keepalive con codificación de transferencia fragmentada

Keepalive hace que sea difícil para el cliente determinar dónde termina una respuesta y comienza la siguiente, en particular durante la operación HTTP canalizada. Este es un problema grave cuando Content-Lengthno se puede usar debido a la transmisión. Para resolver este problema, HTTP 1.1 introdujo una codificación de transferencia fragmentada que define un last-chunkbit. El last-chunkbit se establece al final de cada respuesta para que el cliente sepa dónde comienza la siguiente respuesta.

Ventajas

• Latencia reducida en solicitudes posteriores (sin protocolo de enlace ni inicio lento).
• Reducción del uso de CPU y viajes de ida y vuelta debido a menos conexiones nuevas y protocolos de enlace TLS.
• Habilita la canalización HTTP de solicitudes y respuestas.
• Reducción de la congestión de la red (menos conexiones TCP).
• Los errores se pueden informar sin la penalización de cerrar la conexión TCP.

De acuerdo con RFC 7230, sección 6.4, "un cliente debe limitar la cantidad de conexiones abiertas simultáneas que mantiene con un servidor determinado". La versión anterior de la especificación HTTP/1.1 establecía valores máximos específicos pero, en palabras de RFC 7230, "se descubrió que esto no era práctico para muchas aplicaciones... en cambio... sea conservador al abrir varias conexiones". Estas pautas están destinadas a mejorar los tiempos de respuesta de HTTP y evitar la congestión. Si la canalización HTTP se implementa correctamente, no se obtendrá ningún beneficio de rendimiento de las conexiones adicionales, mientras que las conexiones adicionales pueden causar problemas de congestión.

Desventajas

Si el cliente no cierra la conexión cuando se han recibido todos los datos que necesita, los recursos necesarios para mantener abierta la conexión en el servidor no estarán disponibles para otros clientes. La medida en que esto afecta la disponibilidad del servidor y el tiempo que los recursos no están disponibles dependen de la arquitectura y la configuración del servidor.

También puede ocurrir una condición de carrera donde el cliente envía una solicitud al servidor al mismo tiempo que el servidor cierra la conexión TCP. Un servidor debe enviar un código de estado de tiempo de espera de solicitud 408 al cliente inmediatamente antes de cerrar la conexión. Cuando un cliente recibe el código de estado 408, después de haber enviado la solicitud, puede abrir una nueva conexión con el servidor y volver a enviar la solicitud. No todos los clientes volverán a enviar la solicitud, y muchos de los que lo hacen solo lo harán si la solicitud tiene un método HTTP idempotente.

Uso en navegadores web

Todos los navegadores web modernos, incluidos Google Chrome, Firefox, Internet Explorer (desde 4.01), Opera (desde 4.0) y Safari, utilizan conexiones persistentes.

De manera predeterminada, las versiones 6 y 7 de Internet Explorer usan dos conexiones persistentes, mientras que la versión 8 usa seis. Las conexiones persistentes caducan después de 60 segundos de inactividad, lo que se puede cambiar a través del Registro de Windows.

En Firefox, la cantidad de conexiones simultáneas se puede personalizar (por servidor, por proxy, total). Las conexiones persistentes caducan después de 115 segundos (1,92 minutos) de inactividad, que se puede cambiar a través de la configuración.