Conexión HTTP persistente

La versión actual de la página aún no ha sido revisada por colaboradores experimentados y puede diferir significativamente de la versión revisada el 26 de septiembre de 2017; las comprobaciones requieren 11 ediciones .

Una conexión HTTP persistente ( ing.  HTTP conexión persistente ), también llamada HTTP keep-alive o reutilización de conexión HTTP ( ing.  HTTP connection reuse ) - usando una única conexión TCP para enviar y recibir múltiples solicitudes y respuestas HTTP en lugar de abrir una nueva conexión para cada par solicitud-respuesta. El nuevo protocolo HTTP/2 amplía esta idea al permitir múltiples solicitudes/respuestas simultáneas en la misma conexión.

Funcionalidad

HTTP 1.0

Cuando se trabaja sobre HTTP 1.0 con este tipo de conexión, no existe una especificación oficial. De hecho, esta es una adición al protocolo existente. Si el navegador admite conexiones persistentes, envía un encabezado adicional en la solicitud:

Conexión: Mantener vivo

Luego, cuando el servidor recibe dicha solicitud y genera una respuesta, también agrega al encabezado de respuesta

Conexión: Mantener vivo

Después de eso, la conexión no se interrumpe, sino que permanece abierta. Cuando el cliente envía otra solicitud, utiliza la misma conexión. Esto continuará hasta que el cliente o el servidor decida que el intercambio ha terminado y una de las partes finaliza la conexión.

HTTP 1.1

Cuando se ejecuta sobre HTTP 1.1 , todas las conexiones se consideran persistentes a menos que se indique lo contrario. [1] Sin embargo, las conexiones persistentes no utilizan mensajes de actividad, sino que simplemente permiten que se envíen varias solicitudes en la misma conexión. Sin embargo, el tiempo de espera predeterminado de httpd para Apache 1.3 [2] y 2.0 [3] es de solo 15 segundos, mientras que para Apache 2.2 [4] y 2.4 [5] es de solo 5 segundos. La ventaja de un tiempo de espera corto es que puede servir rápidamente varios componentes de una página web al cliente sin bloquear los procesos o subprocesos del servidor durante demasiado tiempo. [6]

Ventajas

Estas ventajas son especialmente evidentes para las conexiones HTTPS seguras, porque la creación de una conexión segura requiere más tiempo de CPU y tráfico de red entre el cliente y el servidor.

Según RFC 7230, sección 6.4 , "el cliente debe limitar la cantidad de conexiones simultáneas a un servidor en particular". La versión anterior de la especificación HTTP/1.1 especificaba valores máximos específicos , pero RFC 7230 "resultó poco práctico para muchas aplicaciones... en su lugar... sea prudente al abrir conexiones simultáneas". Estas recomendaciones tienen como objetivo mejorar los tiempos de respuesta de HTTP y evitar la congestión de la red. Si la canalización HTTP se implementa correctamente, las conexiones adicionales no mejorarán el rendimiento, pero pueden generar congestión en la red. [7]

Desventajas

Si el cliente no cierra la conexión después de haber recibido todos los datos necesarios, los recursos del servidor involucrados en el mantenimiento de la conexión no estarán disponibles para otros clientes. Cuánto afecta esto a la disponibilidad del servidor y cuánto tiempo estarán ocupados los recursos depende de la arquitectura y la configuración del servidor.

Uso en navegadores web

Todos los navegadores modernos utilizan conexiones persistentes, incluidos Google Chrome , Firefox , Internet Explorer (desde la versión 4.01), Opera (desde la versión 4.0) [8] y Safari .

De forma predeterminada , las versiones 6 y 7 de Internet Explorer abren 2 conexiones persistentes, mientras que la versión 8 abre 6. [9] Las conexiones persistentes se cierran después de 60 segundos de inactividad, lo que se anula en el registro de Windows. [diez]

En Firefox se puede configurar el número de conexiones simultáneas (por servidor, por proxy, total). Las conexiones persistentes se cierran después de 115 segundos (1,9166666666666666 minutos) de tiempo de inactividad, que es configurable. [once]

Notas

  1. Protocolo de transferencia de hipertexto (HTTP/1.1): sintaxis y enrutamiento de mensajes, persistencia . Consultado el 1 de noviembre de 2015. Archivado desde el original el 14 de diciembre de 2016.
  2. Apache HTTP Server 1.3 - Directiva KeepAliveTimeout . Consultado el 1 de noviembre de 2015. Archivado desde el original el 26 de octubre de 2015.
  3. Apache HTTP Server 2.0 - Directiva KeepAliveTimeout . Consultado el 1 de noviembre de 2015. Archivado desde el original el 31 de octubre de 2015.
  4. Apache HTTP Server 2.2 - Directiva KeepAliveTimeout . Fecha de acceso: 15 de septiembre de 2012. Archivado desde el original el 22 de mayo de 2014.
  5. Apache HTTP Server 2.4 - Directiva KeepAliveTimeout . Consultado el 1 de noviembre de 2015. Archivado desde el original el 31 de octubre de 2015.
  6. Múltiple (wiki). Httpd/KeepAlive (enlace no disponible) . doctorforge _ Fecha de acceso: 30 de enero de 2010. Archivado desde el original el 30 de octubre de 2012. 
  7. Nielssen, FrystykHenryk; Gettys, James; Baird-Smith, Anselm & Prud'hommeaux, Eric (octubre de 1997), Network Performance Effects of HTTP/1.1, CSS1, and PNG , Computer Communication Review Vol . 27 (4), ISSN 0146-4833 , < http://conferences .sigcomm.org/sigcomm/1997/papers/p102.html > Archivado el 17 de febrero de 2011 en Wayback Machine . 
  8. Intercambio de archivos de actualizaciones de Opera 4.0: incluye HTTP 1.1 (enlace descendente) . Opera Software (28 de marzo de 2000). Consultado el 8 de julio de 2009. Archivado desde el original el 10 de septiembre de 2010. 
  9. IE8 acelera las cosas . Stevesouders.com (10 de marzo de 2008). Consultado el 17 de julio de 2009. Archivado desde el original el 10 de agosto de 2009.
  10. Cómo cambiar el valor predeterminado de tiempo de espera de actividad en Internet Explorer . Microsoft (27 de octubre de 2007). Consultado el 17 de julio de 2009. Archivado desde el original el 22 de julio de 2009.
  11. Red.http.keep-alive.timeout . Mozillazina.org. Consultado el 17 de julio de 2009. Archivado desde el original el 8 de junio de 2009.

Enlaces