¿La canalización de solicitudes HTTP realmente da como resultado cargas de página más rápidas? ¿Por qué?

1

Un argumento frecuentemente citado es básicamente el contenido en esta imagen. ingrese la descripción de la imagen aquí

Sin embargo, esto no refleja la realidad de una conexión TCP subyacente que tiene que iniciarse lentamente, y donde el cliente reconoce todos los demás segmentos recibidos del servidor. Siempre que el cliente tenga algo que enviar (por ejemplo, una solicitud HTTP), los ACK estarán respaldados. Entonces, ¿dónde está la ganancia aquí?

http tcp

— artistoex
fuente

1

en el sentido de HTTP, esto no es lo que he entendido que es la canalización. no es un patrón de tráfico, sino el medio por el cual una solicitud determinada se dirige al módulo que es capaz de procesarla. iis.net/learn/get-started/introduction-to-iis/… mire la sección bajo "Módulos nativos". De lo contrario, en un nivel TCP, las solicitudes y respuestas HTTP son flujos, y no completamente 1 a 1 con los paquetes enviados. Sus diagramas parecen mostrar solicitudes y respuestas, no paquetes. TCP Windowing sería pertinente a la forma en que lo describe.

— Frank Thomas

1

Hay varias razones por las cuales la canalización es más rápida que las conexiones HTTP persistentes puras:

Se pueden agrupar varias solicitudes HTTP en un solo segmento TCP
Se pueden agrupar múltiples respuestas HTTP (para archivos pequeños) en un solo (o menos) segmento (s) TCP
El inicio lento es en realidad bastante rápido, es decir, exponencial. Después de n tiempos de ida y vuelta, el tamaño del lote ya tiene entre 2 ^ n y 2 ^ (n + 1) segmentos de largo. Para n = 10, esto significa 1024… 2048 segmentos o (típicamente) 140… 300 kilobytes por RTT.
Si la conexión TCP todavía está abierta desde una solicitud HTTP anterior (o un conjunto de solicitudes), ya estamos fuera de la fase de inicio lento.

Como la canalización es simple de implementar para la mayoría de los sistemas, lo haría de todos modos.

— Marcel Waldvogel
fuente

1

La ventaja es mantener la tubería llena tanto como sea posible, en lugar de dejar que se drene entre solicitudes.

Con la canalización, la dirección del servidor -> cliente de la canalización está constantemente llena, para un rendimiento máximo y una latencia mínima.

Sin canalización, tiene un protocolo de "detener y esperar" donde el servidor -> la dirección del cliente permanece inactivo entre el momento en que se envía el último fotograma de una respuesta y antes de enviar el primer fotograma de la siguiente respuesta. La tubería permanece inactiva durante todo el tiempo acumulado que lleva que sucedan todas estas cosas:

El tiempo que tarda el último fotograma de la primera respuesta del servidor en transitar la red.
El tiempo que le toma al cliente actuar al recibir ese marco y preparar su nueva solicitud.
El tiempo que tarda la nueva solicitud del cliente en transitar la red.
El tiempo que le toma al servidor preparar su respuesta a la nueva solicitud.

— Spiff
fuente