La conexión persistente HTTP , también llamada HTTP Keep-Alive , o reutilización de la conexión HTTP , es la idea de usar una solaconexió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 HTTP / 2 más nuevo usa la misma idea y lo lleva más allá para permitir que múltiples solicitudes / respuestas concurrentes se multiplexen a través de una sola conexión.
Operación
HTTP 1.0
Bajo HTTP 1.0, las conexiones no se consideran persistentes a menos que se incluya un encabezado Keep-Alive, [1] aunque no existe una especificación oficial sobre cómo funciona Keepalive. En esencia, se agregó a un protocolo existente. Si el cliente admite mantener vivo, agrega un encabezado adicional a la solicitud:
Conexión: mantener vivo
Luego, cuando el servidor recibe esta solicitud y genera una respuesta, también agrega un encabezado a la respuesta:
Conexión: mantener vivo
Después de esto, la conexión no se interrumpe, sino que se mantiene abierta. Cuando el cliente envía otra solicitud, usa la misma conexión. Esto continuará hasta que el cliente o el servidor decidan que la conversación ha terminado y uno de ellos interrumpe la conexión.
HTTP 1.1
En HTTP 1.1, todas las conexiones se consideran persistentes a menos que se declare lo contrario. [2] 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 [3] [4] y de solo 5 segundos para Apache httpd 2.2 y superior. [5] [6] 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 de servidor o subprocesos durante demasiado tiempo. [7]
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, particularmente durante la operación HTTP canalizada. [8] Este es un problema grave cuando Content-Length
no se puede utilizar debido a la transmisión. [9] Para resolver este problema, HTTP 1.1 introdujo una codificación de transferencia fragmentada que define un last-chunk
bit. [10] El last-chunk
bit 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 ).
- Reducción del uso de CPU y viajes de ida y vuelta debido a menos conexiones nuevas y apretones de manos 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.
Según RFC 7230, sección 6.4 , "un cliente debe limitar el número de conexiones abiertas simultáneas que mantiene a 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 encontró que esto no era práctico para muchas aplicaciones ... en cambio ... sea conservador al abrir múltiples conexiones". Estas pautas están destinadas a mejorar los tiempos de respuesta HTTP y evitar la congestión. Si la canalización HTTP se implementa correctamente, no se puede obtener ningún beneficio de rendimiento con conexiones adicionales, mientras que las conexiones adicionales pueden causar problemas de congestión. [11]
Desventajas
Si el cliente no cierra la conexión cuando se han recibido todos los datos que necesita, los recursos necesarios para mantener la conexión abierta en el servidor no estarán disponibles para otros clientes. Cuánto esto afecta la disponibilidad del servidor y cuánto tiempo los recursos no están disponibles depende de la arquitectura y configuración del servidor.
También puede ocurrir 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. [12] 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 al servidor y reenviar la solicitud. [13] 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 .
Usar en navegadores web
Todos los navegadores web modernos, incluidos Google Chrome , Firefox , Internet Explorer (desde 4.01), Opera (desde 4.0) [14] y Safari, utilizan conexiones persistentes.
De forma predeterminada, las versiones 6 y 7 de Internet Explorer usan dos conexiones persistentes mientras que la versión 8 usa seis. [15] Las conexiones persistentes caducan después de 60 segundos de inactividad que se puede cambiar a través del Registro de Windows. [dieciséis]
En Firefox , el número 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. [17]
Ver también
- Canalización HTTP , mediante la cual se pueden enviar varias solicitudes sin esperar una respuesta
- HTTP / 2 , que permite la canalización desordenada de solicitudes y respuestas, y también el envío predictivo de contenido antes de que se haya solicitado.
Referencias
- ^ "La guía de TCP / IP - Establecimiento, administración y terminación de conexiones persistentes HTTP" . www.tcpipguide.com . Archivado desde el original el 21 de mayo de 2017 . Consultado el 31 de diciembre de 2017 .
- ^ Protocolo de transferencia de hipertexto (HTTP / 1.1): sintaxis y enrutamiento de mensajes, persistencia
- ^ Servidor HTTP Apache 1.3 - Directiva KeepAliveTimeout
- ^ 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 desde el original el 6 de enero de 2010 . Consultado el 30 de enero de 2010 .
- ^ "HTTP: ¿Cuáles son las relaciones entre la canalización, mantener vivo y los eventos enviados al servidor?" .
- ^ "HTTP Streaming (o Chunked vs Store & Forward)" .
- ^ "Codificación de transferencia fragmentada" .
- ^ Nielssen, Frystyk Henryk; Gettys, James; Baird-Smith, Anselm; Prud'hommeaux, Eric; Wium Lie, Håkon; Lilley, Chris (octubre de 1997), "Network Performance Effects of HTTP / 1.1, CSS1, and PNG" , Computer Communication Review , 27 (4), ISSN 0146-4833
- ^ [1]
- ^ [2]
- ^ "Intercambio de archivos de actualizaciones de Opera 4.0: incluye HTTP 1.1" . Opera Software. 2000-03-28 . Consultado el 8 de julio de 2009 .
- ^ "IE8 acelera las cosas" . Stevesouders.com. 2008-03-10 . Consultado el 17 de julio de 2009 .
- ^ "Cómo cambiar el valor predeterminado de tiempo de espera para mantener vivo en Internet Explorer" . Microsoft. 2007-10-27 . Consultado el 17 de julio de 2009 .
- ^ "Network.http.keep-alive.timeout" . Mozillazine.org . Consultado el 17 de julio de 2009 .
enlaces externos
- Protocolo de transferencia de hipertexto (HTTP / 1.1): sintaxis y enrutamiento de mensajes, administración de conexiones, persistencia
- Comportamiento de conexión persistente de navegadores populares (fechado)
- Soporte de Apache HTTPD Keep-Alive
- Efectos de rendimiento de red de HTTP / 1.1, CSS1 y PNG