Conexión persistente HTTP - HTTP persistent connection
| HTTP |
|---|
| Métodos de solicitud |
| Campos de encabezado |
| Códigos de estado de respuesta |
| Métodos de control de acceso de seguridad |
| Vulnerabilidades de seguridad |
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, 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 mantener vivo, agrega un encabezado adicional a la solicitud:
Connection: keep-alive
Cuando el servidor recibe esta solicitud y genera una respuesta, si admite mantener vivo, 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, usa 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, agregan la palabra clave "cerca":
Connection: close
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 con respecto a la interoperabilidad entre HTTP / 1.0 (mantener vivo) y clientes / servidores 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 HTTP no utilizan mensajes keepalive independientes, solo permiten que varias solicitudes utilicen una única 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 de solo 5 segundos para Apache httpd 2.2 y superior. La ventaja de un tiempo de espera breve es la capacidad de entregar rápidamente varios componentes de una página web 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, particularmente durante la operación HTTP canalizada. Este es un problema grave cuando Content-Lengthno se puede utilizar 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 ).
- 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 de 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 la conexión abierta 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 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. 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. No todos los clientes volverán a enviar la solicitud, y muchos que lo hagan 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) 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. Las conexiones persistentes caducan después de 60 segundos de inactividad, que se puede cambiar a través del Registro de Windows.
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.
Ver también
- Canalización HTTP , mediante el 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.