La conexión persistente HTTP , también llamada HTTP keep-alive o reutilización de conexión HTTP , es la idea de utilizar una únicaconexión TCP para enviar y recibir múltiples solicitudes /respuestas HTTP, en lugar de abrir una nueva conexión para cada par de solicitud/respuesta. El protocolo más reciente HTTP/2 utiliza la misma idea y la lleva más allá para permitir que múltiples solicitudes/respuestas simultáneas se multiplexen en una única conexión.
Según HTTP 1.0, el servidor siempre debe cerrar las conexiones después de enviar la respuesta. [1]
Desde al menos finales de 1995, [2] 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. [3] [4]
Si el cliente admite keep-alive, agrega un encabezado adicional a la solicitud:
Conexión: mantener viva
Cuando el servidor recibe esta solicitud y genera una respuesta, si admite la función 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 "close":
Conexión:cerrada
Después de esto, la conexión se cierra siguiendo las reglas especificadas.
Desde 1997, las distintas versiones de las especificaciones HTTP/1.1 reconocieron el uso de esta extensión no oficial e incluyeron algunas advertencias respecto de la interoperabilidad entre los clientes/servidores HTTP/1.0 (keep-alive) y HTTP/1.1. [5]
En HTTP 1.1, todas las conexiones se consideran persistentes a menos que se declare lo contrario. [5] Las conexiones persistentes HTTP no utilizan mensajes keepalive separados, solo permiten que múltiples solicitudes utilicen 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 [6] [7] y solo 5 segundos para Apache httpd 2.2 y posteriores. [8] [9] 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 múltiples procesos o subprocesos del servidor durante demasiado tiempo. [10]
Keepalive dificulta que el cliente determine dónde termina una respuesta y comienza la siguiente, particularmente durante la operación HTTP segmentada. [11] Este es un problema grave cuando Content-Lengthno se puede usar debido a la transmisión. [12] Para resolver este problema, HTTP 1.1 introdujo una codificación de transferencia fragmentada que define un last-chunkbit. [13] El last-chunkbit se establece al final de cada respuesta para que el cliente sepa dónde comienza la siguiente respuesta.
Según la RFC 7230, sección 6.4, "un cliente debe limitar el número 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 la RFC 7230 "se consideró que esto era poco práctico para muchas aplicaciones... en su lugar... sea prudente al abrir múltiples conexiones". Estas pautas tienen como objetivo mejorar los tiempos de respuesta HTTP y evitar la congestión. Si la canalización HTTP se implementa correctamente, no se obtendrá ningún beneficio de rendimiento con conexiones adicionales, mientras que las conexiones adicionales pueden causar problemas de congestión. [14]
Si el cliente no cierra la conexión cuando ha 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 afecte a la disponibilidad del servidor y el tiempo durante el cual los recursos no estén disponibles dependerá de la arquitectura y la configuración del servidor.
También puede producirse una condición de carrera cuando el cliente envía una solicitud al servidor al mismo tiempo que el servidor cierra la conexión TCP. [15] Un servidor debe enviar un código de estado 408 Request Timeout 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. [16] 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 .
Todos los navegadores web modernos, incluidos Google Chrome , Firefox , Internet Explorer (desde 4.01), Opera (desde 4.0) [17] y Safari, utilizan conexiones persistentes.
De manera predeterminada, las versiones 6 y 7 de Internet Explorer utilizan dos conexiones persistentes, mientras que la versión 8 utiliza seis. [18] Las conexiones persistentes caducan después de 60 segundos de inactividad, lo que se puede modificar a través del Registro de Windows. [19]
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, lo que se puede modificar mediante la configuración. [20]
La biblioteca de Python requestscontiene requests.Session(), que establece una conexión HTTP persistente, lo que permite reutilizar la conexión TCP subyacente, lo que puede resultar en un aumento significativo del rendimiento. [21]