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

sitios http2 (3)

¿Podría alguien explicar la multiplexación en relación con HTTP / 2 y cómo funciona?

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

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

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

Bajo HTTP / 1.1 solo puede descargar uno de esos a la vez en su conexión HTTP / 1.1. Entonces su navegador descarga el HTML, luego le pide 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, está atascado hasta que obtiene una respuesta. Esto significa que la mayoría de las veces el navegador no está haciendo mucho, ya que ha disparado una solicitud, está esperando una respuesta, luego dispara otra solicitud, luego está esperando una respuesta ... etc. Por supuesto, sitios complejos con muchos JavaScript requieren que el Navegador procese mucho, pero eso depende de la descarga de JavaScript, por lo que, al menos al principio, los retrasos heredados a HTTP / 1.1 causan problemas. Por lo general, el servidor tampoco funciona mucho (al menos por solicitud, por supuesto, se suman a los sitios ocupados), ya que 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 la base de datos o similar).

Entonces, uno de los principales problemas en la web hoy en día es la latencia de la red al enviar las 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 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 (como lo están haciendo) y acceso a Internet es cada vez más 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 cargue el HTML (que es un sitio muy pequeño para los estándares actuales, ya que más de 100 recursos son comunes, pero lo mantendremos simple e iremos con esto ejemplo). Y supongamos 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 cada extremo es insignificante (digamos 0 para este ejemplo por simplicidad). Como debe enviar cada recurso y esperar una respuesta de uno en uno, esto tomará 10 * 100 ms = 1,000 ms o 1 segundo para descargar todo el sitio.

Para evitar esto, los navegadores generalmente abren múltiples conexiones al servidor web (generalmente 6). Esto significa que un navegador puede disparar 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 también digamos que hay 4 conexiones y, por simplicidad, digamos que todas las solicitudes son iguales. En este caso, puede dividir las solicitudes en las cuatro conexiones, por lo que dos tendrán 3 recursos para obtener, y dos tendrán 2 recursos para obtener totalmente los diez recursos (3 + 3 + 2 + 2 = 10). En ese caso, el peor de los casos es 3 veces redondas o 300 ms = 0,3 segundos, una buena mejora, pero este simple ejemplo no incluye el costo de configurar esas conexiones múltiples, ni las implicaciones de recursos de administrarlas (lo cual no he analizado). aquí, ya que esta respuesta ya es lo suficientemente larga, pero configurar conexiones TCP separadas lleva tiempo y otros recursos: hacer 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 varias conexiones como se indicó anteriormente. Entonces su navegador puede decir "Dame este archivo CSS. Dame ese archivo JavaScript. Dame image1.jpg. Dame image2.jpg ... Etc." para utilizar completamente la única conexión. Esto tiene el beneficio de rendimiento obvio de no retrasar el envío de esas solicitudes en espera de una conexión gratuita. Todas estas solicitudes se abren paso 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 aún más poderoso que eso, ya que el servidor web puede responder a ellos en el orden que desee y devolver los archivos en un orden diferente, o incluso dividir cada archivo solicitado en pedazos y mezclarlos. Esto tiene el beneficio secundario de que una solicitud pesada no bloquea todas las demás solicitudes posteriores (conocido como el problema de bloqueo de cabecera ). 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, ver más abajo), si las 10 solicitudes se disparan casi a la vez en paralelo y el servidor las responde de inmediato, esto significa que básicamente tiene un viaje de ida y vuelta o 100ms o 0.1 segundos, para Descargue los 10 recursos. ¡Y esto no tiene ninguno de los inconvenientes 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 ¿eso 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 pipelining que también permite enviar múltiples solicitudes a la vez. Sin embargo, todavía tenían que ser devueltos en el orden en que fueron solicitados, en su totalidad, por lo que ni siquiera son tan buenos como HTTP / 2, incluso si conceptualmente es similar. Sin mencionar el hecho de que esto es tan poco compatible con los navegadores y servidores que rara vez se usa.

Una cosa resaltada en los comentarios a continuación es cómo el ancho de banda nos impacta aquí. Por supuesto, su conexión a Internet está limitada por la cantidad que puede descargar y HTTP / 2 no aborda eso. Entonces, si esos 10 recursos discutidos en los ejemplos anteriores son imágenes masivas con calidad de impresión, entonces aún serán lentas para descargar. Sin embargo, para la mayoría de los navegadores web, el ancho de banda es menos problemático 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 que a menudo es el problema y HTTP / 2 busca solucionar eso. 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, todos los CSS a menudo se unen en un solo archivo: la cantidad de CSS descargada es la misma, pero al hacerlo como un recurso hay grandes 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: suponga que tiene que pedir 10 artículos de una tienda para entrega a domicilio:

HTTP / 1.1 con una conexión significa que debe ordenarlos uno a la vez y no puede ordenar el siguiente elemento hasta que llegue el último. Puedes entender que llevaría semanas superarlo 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 artículos uno tras otro sin esperar, pero luego todos llegan en el orden específico que solicitó. Y si un artículo está agotado, debe esperar antes de obtener los artículos que ordenó después de eso, ¡incluso si esos artículos posteriores están realmente en stock! Esto es un poco mejor, pero aún está sujeto a retrasos, y digamos que la mayoría de las tiendas no admiten esta forma de ordenar de todos modos.
HTTP / 2 significa que puede ordenar sus artículos en cualquier orden en particular, sin demoras (similar a lo anterior). La tienda los enviará cuando estén listos, por lo que pueden llegar en un orden diferente al que usted solicitó, e incluso pueden dividir los artículos para que algunas partes de ese pedido lleguen primero (tan mejor que arriba). En última instancia, esto debería significar que 1) obtiene todo más rápido en general y 2) puede comenzar a trabajar en cada elemento a medida que llega ("oh, eso no es tan bueno como pensé que sería, por lo que es posible que desee pedir algo más también o en su lugar" )

Por supuesto, todavía está limitado por el tamaño de la camioneta de su 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 con el retraso en el envío del pedido de ida y vuelta. La mayor parte de la navegación web implica enviar pequeñas letras de un lado a otro, en lugar de paquetes voluminosos.

Espero que ayude.

La multiplexación en HTTP 2.0 es el tipo de relación entre el navegador y el servidor que usa una única conexión para entregar múltiples solicitudes y respuestas en paralelo, creando muchos marcos individuales en este proceso.

La multiplexación rompe con la estricta semántica de solicitud-respuesta y permite relaciones uno a muchos o muchos a muchos.

Respuesta simple ( Source ):

La multiplexación significa que su navegador puede enviar múltiples solicitudes y recibir múltiples respuestas "agrupadas" en una sola conexión TCP. Por lo tanto, la carga de trabajo asociada con las búsquedas DNS y los apretones de manos se guarda para los archivos que provienen del mismo servidor.

Respuesta compleja / detallada:

Mira la respuesta proporcionada por @BazzaDP.