¿Qué significa multiplexación en HTTP/2?

En pocas palabras, la multiplexación permite que su navegador envíe múltiples solicitudes a la vez en la misma conexión y las reciba en cualquier orden.

Y ahora viene la respuesta mucho más complicada...

Cuando cargas una página web, descarga la página HTML, ve que necesita algo de CSS, algo de JavaScript, una carga de imágenes... etc.

En HTTP/1.1 solo puedes descargar uno de ellos a la vez en tu conexión HTTP/1.1. Entonces su navegador descarga el HTML y luego solicita el archivo CSS. Cuando se devuelve, solicita el archivo JavaScript. Cuando se devuelve, solicita el primer archivo de imagen... etc. HTTP/1.1 es básicamente sincrónico: una vez que envía una solicitud, queda atascado hasta que recibe una respuesta. Esto significa que la mayor parte del tiempo el navegador no hace mucho, ya que ha enviado una solicitud, está esperando una respuesta, luego envía otra solicitud, luego está esperando una respuesta... etc. Por supuesto, sitios complejos con muchos JavaScript requieren que el navegador realice mucho procesamiento, pero eso depende de que JavaScript se descargue, por lo que, al menos al principio, los retrasos heredados de HTTP/1.1 causan problemas. Normalmente, el servidor tampoco hace mucho (al menos por solicitud; por supuesto, se suman para sitios ocupados), porque debería responder casi instantáneamente a los recursos estáticos (como CSS, JavaScript, imágenes, fuentes... etc.) y con suerte no mucho más incluso para solicitudes dinámicas (que requieren una llamada a una base de datos o algo similar).

Entonces, uno de los principales problemas en la web hoy en día es la latencia de la red al enviar solicitudes entre el navegador y el servidor. Puede que solo sean decenas o quizás cientos de milisegundos, lo que puede no parecer mucho, pero se suman y a menudo son la parte más lenta de la navegación web, especialmente a medida que los sitios web se vuelven más complejos y requieren recursos adicionales (que están obteniendo) y acceso a Internet. es cada vez más a través del móvil (con una latencia más lenta que la banda ancha).

Como ejemplo, digamos que hay 10 recursos que su página web necesita cargar después de que se carga el HTML (que es un sitio muy pequeño para los estándares actuales, ya que es común tener más de 100 recursos, pero lo mantendremos simple y seguiremos con esto ejemplo). Y digamos que cada solicitud tarda 100 ms en viajar a través de Internet hasta el servidor web y viceversa, y el tiempo de procesamiento en ambos extremos es insignificante (digamos 0 para este ejemplo por razones de simplicidad). Como debe enviar cada recurso y esperar una respuesta uno a la vez, esto tomará 10 * 100 ms = 1000 ms o 1 segundo para descargar todo el sitio.

Para solucionar este problema, los navegadores suelen abrir varias conexiones al servidor web (normalmente 6). Esto significa que un navegador puede activar múltiples solicitudes al mismo tiempo, lo cual es mucho mejor, pero a costa de la complejidad de tener que configurar y administrar múltiples conexiones (lo que afecta tanto al navegador como al servidor). Continuemos con el ejemplo anterior y digamos también que hay 4 conexiones y, para simplificar, digamos que todas las solicitudes son iguales. En este caso, puede dividir las solicitudes entre las cuatro conexiones, de modo que dos tendrán 3 recursos para obtener y dos tendrán 2 recursos para obtener en total los diez recursos (3 + 3 + 2 + 2 = 10). En ese caso, el peor caso es 3 tiempos de ronda o 300 ms = 0,3 segundos: una buena mejora, pero este ejemplo simple no incluye el costo de configurar esas conexiones múltiples, ni las implicaciones de recursos de administrarlas (que no he analizado). Aquí, ya que esta respuesta ya es lo suficientemente larga, pero configurar conexiones TCP separadas requiere tiempo y otros recursos (para realizar la conexión TCP, el protocolo de enlace HTTPS y luego alcanzar la velocidad máxima debido al inicio lento de TCP).

HTTP/2 le permite enviar múltiples solicitudes en la misma conexión, por lo que no necesita abrir múltiples conexiones como se indicó anteriormente. Entonces su navegador puede decir "Dame este archivo CSS. Dame ese archivo JavaScript. Dame imagen1.jpg. Dame imagen2.jpg... Etc." utilizar plenamente una única conexión. Esto tiene el beneficio obvio de rendimiento al no retrasar el envío de aquellas solicitudes que esperan una conexión gratuita. Todas estas solicitudes llegan a través de Internet hasta el servidor en (casi) paralelo. El servidor responde a cada uno y luego comienzan a regresar. De hecho, es incluso más poderoso que eso, ya que el servidor web puede responder a ellos en cualquier orden que desee y enviar archivos en diferente orden, o incluso dividir cada archivo solicitado en pedazos y entremezclarlos. Esto tiene el beneficio secundario de que una solicitud pesada no bloquea todas las demás solicitudes posteriores (conocido como problema de bloqueo del encabezado de línea ). Luego, el navegador web tiene la tarea de volver a unir todas las piezas. En el mejor de los casos (suponiendo que no haya límites de ancho de banda; consulte a continuación), si las 10 solicitudes se envían prácticamente a la vez en paralelo y el servidor las responde inmediatamente, esto significa que básicamente tiene un viaje de ida y vuelta o 100 ms o 0,1 segundos, para Descargue los 10 recursos. ¡Y esto no tiene ninguna de las desventajas que tenían las conexiones múltiples para HTTP/1.1! Esto también es mucho más escalable a medida que crecen los recursos en cada sitio web (actualmente los navegadores abren hasta 6 conexiones paralelas bajo HTTP/1.1, pero ¿debería crecer a medida que los sitios se vuelven más complejos?).

Este diagrama muestra las diferencias y también hay una versión animada .

Nota: HTTP/1.1 tiene el concepto de canalización , que también permite enviar múltiples solicitudes a la vez. Sin embargo, todavía tenían que devolverse en el orden en que fueron solicitados, en su totalidad, por lo que no son tan buenos como HTTP/2, incluso si conceptualmente son similares. Sin mencionar el hecho de que tanto los navegadores como los servidores lo soportan tan mal que rara vez se utiliza.

Una cosa que se destaca en los comentarios a continuación es cómo el ancho de banda nos afecta aquí. Por supuesto, su conexión a Internet está limitada por la cantidad que puede descargar y HTTP/2 no soluciona eso. Entonces, si esos 10 recursos discutidos en los ejemplos anteriores son todos imágenes masivas con calidad de impresión, su descarga seguirá siendo lenta. Sin embargo, para la mayoría de los navegadores web, el ancho de banda es un problema menor que la latencia. Entonces, si esos diez recursos son elementos pequeños (particularmente recursos de texto como CSS y JavaScript, que se pueden comprimir para que sean pequeños), como es muy común en los sitios web, entonces el ancho de banda no es realmente un problema: es el gran volumen de recursos lo que a menudo es el problema y HTTP/2 busca solucionarlo. Esta es también la razón por la que la concatenación se usa en HTTP/1.1 como otra solución alternativa, por lo que, por ejemplo, todo el CSS a menudo se une en un solo archivo: la cantidad de CSS descargado es la misma, pero al hacerlo como un solo recurso, se obtienen enormes beneficios de rendimiento (aunque menos con HTTP/2 y, de hecho, algunos dicen que la concatenación debería ser un antipatrón en HTTP/2 (aunque también hay argumentos en contra de eliminarlo por completo).

Para ponerlo como un ejemplo del mundo real: supongamos que tiene que pedir 10 artículos en una tienda para entrega a domicilio:

• HTTP/1.1 con una conexión significa que tienes que pedirlos uno a la vez y no puedes pedir el siguiente artículo hasta que llegue el último. Puedes entender que se necesitarían semanas para superar todo.

• HTTP/1.1 con múltiples conexiones significa que puede tener un número (limitado) de pedidos independientes sobre la marcha al mismo tiempo.

• HTTP/1.1 con canalización significa que puede solicitar los 10 elementos uno tras otro sin esperar, pero luego todos llegarán en el orden específico que solicitó. Y si un artículo está agotado, tendrá que esperar antes de recibir los artículos que pidió después, ¡incluso si esos artículos posteriores realmente están en stock! Esto es un poco mejor, pero todavía está sujeto a retrasos y digamos que la mayoría de las tiendas no admiten esta forma de realizar pedidos de todos modos.

• HTTP/2 significa que puedes ordenar tus artículos en cualquier orden en particular, sin demoras (similar a lo anterior). La tienda los enviará cuando estén listos, por lo que es posible que lleguen en un orden diferente al que usted solicitó, e incluso pueden dividir los artículos para que algunas partes de ese pedido lleguen primero (mejor que el anterior). En última instancia, esto debería significar que usted 1) obtiene todo más rápido en general y 2) puede comenzar a trabajar en cada artículo a medida que llega ("oh, eso no es tan bueno como pensé, así que tal vez quiera pedir algo más también o en su lugar" ).

Por supuesto, todavía estás limitado por el tamaño de la camioneta de tu cartero (el ancho de banda), por lo que es posible que tengan que dejar algunos paquetes en la oficina de clasificación hasta el día siguiente si están llenos para ese día, pero eso rara vez es un problema en comparación. al retraso en el envío del pedido de ida y vuelta. La mayor parte de la navegación web implica enviar y recibir cartas pequeñas, en lugar de paquetes voluminosos.

Apr 09 '2016 16:04 Barry Pollard