Xiaobai aprende las notas del rastreador sobre conexión persistente y conexión no persistente

1.? Comparación

HTTP 0.9 está obsoleto

HTTP1.0: conexión no persistente, cada conexión solo maneja una transacción de respuesta de solicitud, algunos servidores esto Incluso todavía se usa y la conexión se puede reutilizar dentro de un cierto período de tiempo. El tiempo de reutilización específico puede ser controlado por el servidor, generalmente alrededor de 15 segundos.

HTTP 1.1 utiliza conexiones persistentes de forma predeterminada. No es necesario establecer una nueva conexión para cada objeto WEB. Una conexión puede transferir varios objetos, pero el servidor aún puede establecer un límite y no habrá lectura. o escribiendo durante demasiado tiempo, el servidor puede cerrarse.

La multiplexación HTTP 2.0 (solo una conexión TCP por dominio) permite verdaderas solicitudes simultáneas, reduce la latencia y mejora la utilización del ancho de banda.

?Antes de la llegada de las conexiones persistentes o la canalización HTTP, cada adquisición de conexión requería la creación de una conexión TCP independiente.

2. Indicación de conexión no persistente

Cada objeto WEB debe establecer una nueva conexión.

Supongamos que una página simple contiene 1 imagen HTML y 2 imágenes PNG, las cuales están almacenadas en un servidor host.

El cliente ingresa la URL para acceder a la página de inicio, /path/index.html

En el primer paso, el cliente establece una conexión TCP con el puerto de servicio HTTP (predeterminado) en el host del servidor

En el segundo paso, el cliente envía una solicitud HTTP /path/index.html

En el tercer paso, el servidor recibe el mensaje de solicitud y obtiene el objeto /sompath/index de la memoria del host del servidor o del disco duro .html, emite la respuesta de este objeto.

En el cuarto paso, el servidor le dice a TCP que cierre la conexión TCP (TCP en realidad no terminará la conexión hasta que el cliente reciba el mensaje de respuesta).

En el quinto paso, el cliente HTTP recibe el mensaje de respuesta. La conexión TCP finalizó. Este mensaje indica que el objeto que se está ensamblando es un archivo HTML. El cliente sacó el archivo y después del análisis encontró referencias a 2 objetos JPEG.

Paso seis, repita los pasos del uno al cuatro para cada objeto JPEG al que se hace referencia

Para conexiones no persistentes, cada objeto tiene 2 retrasos RTT

Conexión persistente, con canalización, todos los objetos de referencia, ***experimentan un retraso RTT;

Conexión persistente, sin canalización, cada objeto de referencia tiene un retraso RTT.

En primer lugar: las conexiones largas y cortas HTTP son esencialmente conexiones largas y cortas TCP.

1. En HTTP1.0, el valor predeterminado es una conexión corta y no existe una disposición formal de conexión: operación Keep-alive;

En HTTP1.1, todas las conexiones son Keep. -alive, es decir, la conexión predeterminada es Conexión persistente.

2. La diferencia entre los dos métodos de conexión se muestra en la siguiente figura.

3 Como se puede ver en la figura anterior, después de que el cliente establece una conexión continua con el servidor. , se puede procesar durante la conexión Múltiples solicitudes/respuestas (Solicitud/Respuesta)

La guía autorizada para HTTP:

HTTP/1.1 permite que los dispositivos HTTP mantengan la conexión TCP abierta después la transacción se completa y la solicitud/respuesta HTTP posterior aún se puede transmitir a través de esta conexión TCP.

Una conexión TCP que permanece abierta una vez finalizada la transacción se convierte en un enlace persistente. Las conexiones no persistentes se cierran al final de cada transacción, y las conexiones persistentes permanecen abiertas entre diferentes transacciones (Solicitud/Respuesta) hasta que el cliente o servidor decide cerrarlas.

Métodos que pueden mejorar el rendimiento de las conexiones HTTP:

Conexiones paralelas

Iniciar solicitudes HTTP simultáneas a través de múltiples conexiones.

Las conexiones paralelas pueden aumentar la velocidad de transmisión de páginas compuestas, pero sus conexiones también tienen algunas desventajas

Cada transacción abrirá/cerrará una nueva conexión, lo que consumirá tiempo y ancho de banda. Debido a la función de inicio lento de TCP, se reducirá el rendimiento de cada conexión. La cantidad de conexiones paralelas que se pueden abrir es en realidad limitada

Conexiones persistentes

Los clientes web a menudo abren conexiones al mismo sitio. Por ejemplo, la mayoría de las imágenes incrustadas en una página web suelen proceder del mismo sitio web, y un número considerable de hipervínculos que apuntan a otros objetos suelen apuntar al mismo sitio. Es probable que una aplicación que inicia una solicitud HTTP a un determinado servidor realice más solicitudes a ese servidor en un futuro próximo. Esta propiedad se denomina localidad del sitio.

Por lo tanto, HTTP/1.1 permite que los dispositivos HTTP mantengan abiertas las conexiones TCP después de que se completa una transacción, para reutilizar la conexión existente para futuras solicitudes HTTP. Una conexión TCP que permanece abierta una vez completada la transacción se denomina conexión persistente. Una conexión persistente permanece abierta entre transacciones hasta que el cliente o servidor decide cerrarla. La fase de establecimiento de conexión lenta se puede evitar reutilizando una conexión persistente inactiva que ya esté abierta al servidor de destino. Además, las conexiones ya abiertas evitan la fase de adaptación a la congestión de inicio lento, lo que permite una transferencia de datos más rápida. Por lo tanto, las conexiones persistentes reducen la latencia y la sobrecarga del establecimiento de la conexión, mantienen las conexiones en un estado optimizado y reducen la cantidad potencial de conexiones abiertas.

Usar conexiones persistentes con conexiones paralelas es probablemente la forma más eficiente. Muchas aplicaciones web abren una pequeña cantidad de conexiones paralelas, cada una de las cuales es una conexión persistente. Hay dos tipos de conexiones persistentes

1) HTTP/1.0 + conexión keep-alive

2) HTTP/1.1 + conexión persistente

HTTP/1.0 ? conexiones keep-alive

Muchos clientes y servidores todavía utilizan estas primeras conexiones keep-alive.

Los clientes que implementan conexiones HTTP/1.0 keep-live pueden mantener una conexión abierta incluyendo el encabezado de solicitud Connection:Keep-Alive.

El encabezado Keep-Alive en la respuesta es opcional, pero solo se puede usar cuando se proporciona Conexión: Keep-Alive.

Conexión:Keep-Alive

Keep-Alive:max=5,timeout=120

Este ejemplo muestra que el servidor manejará hasta 5 transacciones adicionales Mantenga la conexión abierta o manténgala abierta hasta que la conexión haya estado inactiva durante 2 minutos.

Nota:

1 En HTTP/1.0, mantener vivo no se utiliza de forma predeterminada. El cliente debe enviar un encabezado de solicitud Conexión: Mantener vivo para activar la conexión mantener vivo.

2 Si el servidor está dispuesto a mantener la conexión abierta para la siguiente solicitud, se indicará en el encabezado de respuesta. Si no hay Connection:Keep-Alive en el encabezado de respuesta, el cliente pensará. que el servidor no admite keep-live, la conexión se cerrará después de enviar el mensaje de respuesta.

3 La conexión solo se puede mantener abierta si la longitud de la parte del cuerpo de la entidad del mensaje se puede determinar sin detectar el cierre de la conexión; es decir, la parte del cuerpo de la entidad debe tener la longitud correcta. Contenido -Longitud,

Tiene un tipo de medio de varias partes (multipart/form-data tiene un límite) o está codificado mediante codificación de transferencia fragmentada. Es muy malo devolver la longitud del contenido incorrecta en un canal de mantenimiento en vivo, de modo que el otro extremo de la transacción no pueda detectar con precisión el final de un mensaje y el comienzo de otro.

HTTP/1.1 ?Conexión persistente

HTTP/1.1 dejó gradualmente de admitir conexiones keep-alive y las reemplazó con un diseño mejorado llamado conexiones persistentes. El propósito de una conexión persistente es el mismo que el de una conexión de mantenimiento, pero el mecanismo de funcionamiento es mejor. Las conexiones HTTP/1.1 están habilitadas de forma predeterminada. A menos que se especifique lo contrario, HTTP/1.1 asume que todas las conexiones son persistentes. Para cerrar la conexión una vez completada la transacción, la aplicación HTTP/1.1 debe agregar explícitamente un encabezado Conexión: cerrar al mensaje.

Después de que el cliente HTTP1.1 carga la respuesta, a menos que la respuesta contenga el encabezado Conexión: cerrar, la conexión HTTP/1.1 seguirá abierta. Sin embargo, los clientes y servidores aún pueden cerrar conexiones inactivas en cualquier momento. No enviar Conexión: cerrar no significa que el servidor prometa mantener la conexión abierta para siempre.

Nota:

1? ¿Solo cuando todos los paquetes en la conexión tienen longitudes de paquete correctas y personalizadas, es decir, la longitud de la parte del cuerpo de la entidad es consistente con la correspondiente? La conexión se puede mantener de forma persistente si Content-Length es coherente o está codificado mediante codificación de transferencia fragmentada.

2 Si el cliente no desea enviar otras solicitudes en la conexión, debe enviar un encabezado Conexión: cerrar solicitud en la última solicitud

Conexión de canalización

HTTP/1.1 permite el uso opcional de canales de solicitud a través de conexiones persistentes. Esta es otra optimización del rendimiento en comparación con las conexiones permanentes. Se pueden poner varias solicitudes en la cola antes de que llegue una respuesta, y mientras la primera solicitud fluye a través de la red hacia el servidor, la segunda y tercera solicitudes pueden comenzar a enviarse. En condiciones de red de alta latencia, esto puede reducir el tiempo de bucle de red y mejorar el rendimiento.

Notas sobre las conexiones de tuberías:

1) Si el cliente HTTP no puede confirmar que la conexión es duradera, no debe utilizar tuberías.

2) Debe ser De acuerdo con las respuestas HTTP se envían en el mismo orden que la solicitud.

3) El cliente HTTP debe estar preparado para que la conexión se cierre en cualquier momento y estar preparado para reenviar todas las solicitudes canalizadas pendientes.

4) Cuando se produce un error, la conexión de canalización evitará que el cliente comprenda cuál de la serie de solicitudes canalizadas está ejecutando el servidor. Dado que las solicitudes no potentes como POST no se pueden reintentar de forma segura, existe el riesgo de que algunos métodos nunca se ejecuten cuando se produce un error.