Hispanopedia WikiLa conexión persistente HTTP , también conocida como HTTP keep-alive o reutilización de conexión HTTP , consiste en utilizar una únicaconexión TCP para enviar y recibir múltiples solicitudes y respuestas HTTP , en lugar de abrir una nueva conexión para cada par de solicitud/respuesta. El protocolo HTTP/2, más reciente , utiliza esta misma idea y la va más allá, permitiendo la multiplexación de múltiples solicitudes y respuestas simultáneas a través de una sola conexión.
Operación
HTTP 1.0
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 la función keep-alive, añade un encabezado adicional a la solicitud:
Conexión: mantener activo
Cuando el servidor recibe esta solicitud y genera una respuesta, si admite la función keep-alive, también agrega el encabezado mencionado anteriormente a la respuesta. Posteriormente, la conexión no se cierra, 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 ese caso, omitan el "Connection:"encabezado del último mensaje enviado o, mejor aún, le añadan la palabra clave "close":
Conexión: cerrar
Posteriormente, 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 sobre la interoperabilidad entre clientes/servidores HTTP/1.0 (keep-alive) y HTTP/1.1. [ 5 ]
HTTP 1.1
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, simplemente 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 de solo 5 segundos para Apache httpd 2.2 y versiones 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 hilos del servidor durante demasiado tiempo. [ 10 ]
Mantener la conexión mediante codificación de transferencia fragmentada
Keepalive dificulta que el cliente determine dónde termina una respuesta y comienza la siguiente, especialmente durante la operación HTTP en pipeline. [ 11 ] Esto es un problema grave cuando Content-Lengthno se puede utilizar 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.
Ventajas
- Latencia reducida en las solicitudes posteriores (sin necesidad de establecer la conexión ni de iniciar la aplicación lentamente ).
- Menor uso de CPU y menos viajes de ida y vuelta debido a la menor cantidad de nuevas conexiones y protocolos de enlace TLS .
- Permite el procesamiento en paralelo de solicitudes y respuestas HTTP .
- Menor congestión de la red (menos conexiones TCP ).
- Los errores pueden notificarse sin que ello implique el cierre de la conexión TCP.
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, según la RFC 7230, "esto resultó poco práctico para muchas aplicaciones... en su lugar... sea prudente al abrir múltiples conexiones". Estas directrices tienen como objetivo mejorar los tiempos de respuesta HTTP y evitar la congestión. Si la canalización HTTP se implementa correctamente, no se obtiene ningún beneficio de rendimiento con conexiones adicionales, mientras que estas pueden causar problemas de congestión. [ 14 ]
Desventajas
Si el cliente no cierra la conexión una vez recibidos todos los datos necesarios, los recursos del servidor que mantienen la conexión abierta no estarán disponibles para otros clientes. Esto afecta tanto a la disponibilidad del servidor como a la disponibilidad de sus recursos, y el grado de impacto depende 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. [ 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 al servidor y reenviar la solicitud. [ 16 ] No todos los clientes reenviarán 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 Chrome , Edge , Firefox , Opera (desde la versión 4.0), [ 17 ] y Safari, utilizan conexiones persistentes.
En Firefox, se puede personalizar el número de conexiones simultáneas (por servidor, por proxy, total). Las conexiones persistentes caducan después de 115 segundos (1,92 minutos) de inactividad, valor que se puede modificar mediante la configuración. [ 18 ]
Implementación
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. [ 19 ]
Véase también
- El enrutamiento HTTP , mediante el cual se pueden enviar múltiples solicitudes sin esperar una respuesta, permite enviar varias solicitudes.
- HTTP/2 , que permite el procesamiento en paralelo de solicitudes y respuestas fuera de orden, y también el envío predictivo de contenido antes de que se haya solicitado.
Referencias
- ↑ Protocolo de transferencia de hipertexto (HTTP/1.0): Funcionamiento general
- ↑ Gildor, Dan. "¿HTTP_Connection?" . Google Groups . Consultado el 17 de noviembre de 2023 .
- ↑ "Guía TCP/IP: Establecimiento, gestión y terminación de conexiones persistentes HTTP" . www.tcpipguide.com . Archivado del original el 21 de mayo de 2017. Consultado el 31 de diciembre de 2017 .
- ↑ David Gourley; Brian Totty; Marjorie Sayer; Anshu Aggarwal; Sailu Reddy (2002). HTTP: La guía definitiva. (fragmento del capítulo: "Conexiones persistentes") . O'Reilly Media, Inc. ISBN 9781565925090. Consultado el 18 de octubre de 2021 .
- 1 2 Protocolo de transferencia de hipertexto (HTTP/1.1): Sintaxis y enrutamiento de mensajes, persistencia
- ↑ "Servidor HTTP Apache 1.3 – Directiva KeepAliveTimeout" . Archivado del original el 26/10/2015 . Consultado el 28/01/2015 .
- ↑ Servidor HTTP Apache 2.0 – Directiva KeepAliveTimeout
- ↑ Servidor HTTP Apache 2.2 – Directiva KeepAliveTimeout
- ↑ Servidor HTTP Apache 2.4 – Directiva KeepAliveTimeout
- ↑ Múltiple (wiki). "Httpd/KeepAlive" . Docforge . Archivado del original el 6 de enero de 2010. Recuperado el 30 de enero de 2010 .
- ↑ "HTTP: ¿Cuáles son las relaciones entre el pipelining, el keep alive y los eventos enviados por el servidor?" .
- ↑ "HTTP Streaming (o Chunked vs Store & Forward)" .
- ^ "Codificación de transferencia fragmentada" . Junio de 1999.
- ↑ Nielssen, Frystyk Henryk; Gettys, James; Baird-Smith, Anselm; Prud'hommeaux, Eric; Wium Lie, Håkon; Lilley, Chris (octubre de 1997), "Efectos del rendimiento de red de HTTP/1.1, CSS1 y PNG" , ACM SIGCOMM Computer Communication Review , 27 (4), ISSN 0146-4833
- ↑ "¿Cómo manejan los navegadores la condición de carrera de HTTP keepalive?" . Stack Overflow . 6 de marzo de 2017.
- ↑ Fielding, Roy T.; Reschke, Julian (junio de 2014). Fielding, R.; Reschke, J. (eds.). "Protocolo de transferencia de hipertexto (HTTP/1.1): semántica y contenido" . IETF Datatracker . doi : 10.17487/RFC7231 . S2CID 14399078 .
- ↑ "Opera 4.0 actualiza el intercambio de archivos: incluye HTTP 1.1" . Opera Software. 28 de marzo de 2000. Consultado el 8 de julio de 2009 .
- ↑ "Network.http.keep-alive.timeout" . Mozillazine.org . Consultado el 17 de julio de 2009 .
- ↑ "Requests.AdvancedUsage.SessionObjects" . ©MMXVIX. Un proyecto de Kenneth Reitz . Consultado el 22 de abril de 2023 .
Enlaces externos
- Protocolo de transferencia de hipertexto (HTTP/1.1): Sintaxis y enrutamiento de mensajes, gestión de conexiones, persistencia.
- Comportamiento de conexión persistente de los navegadores más populares (fechado)
- Soporte para la función Keep-Alive de Apache HTTPD
- Efectos en el rendimiento de la red de HTTP/1.1, CSS1 y PNG
- Protocolo de transferencia de hipertexto
