En pocas palabras, la multiplexación permite que su navegador active varias solicitudes a la vez en la misma conexión y reciba las solicitudes en cualquier orden.
Y ahora 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, un montón de imágenes ... etc.
En 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 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 síncrono: una vez que envía una solicitud, está atascado hasta que obtenga una respuesta. Esto significa que la mayoría de las veces el navegador no hace 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 realice muchos procesos, pero eso depende de la descarga de JavaScript, por lo que, al menos al principio, los retrasos heredados de HTTP / 1.1 causan problemas. Normalmente, el servidor no es
Entonces, uno de los principales problemas en la web hoy en día es la latencia de la red en el envío de solicitudes entre el navegador y el servidor. Puede ser solo 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 (a medida que se obtienen) y acceso a Internet. es cada vez más a través de dispositivos móviles (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 y lo seguiremos. ejemplo). Y digamos que cada solicitud tarda 100 ms en viajar a través de Internet al servidor web y viceversa y el tiempo de procesamiento en cada extremo es insignificante (digamos 0 en este ejemplo por simplicidad). Como tienes que enviar cada recurso y esperar una respuesta uno a la vez, esto tomará 10 * 100ms = 1,000ms 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 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, para simplificar, 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 tiempos redondos o 300 ms = 0,3 segundos; una buena mejora, pero este simple ejemplo no incluye el costo de configurar esas conexiones múltiples.
HTTP / 2 le permite enviar múltiples solicitudes en el mismoconexión, por lo que no es necesario abrir varias conexiones como se indica arriba. Para que su navegador pueda decir "Dame este archivo CSS. Dame ese archivo JavaScript. Dame image1.jpg. Dame image2.jpg ... Etc." para utilizar plenamente la única conexión. Esto tiene el beneficio obvio de rendimiento 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 incluso más poderoso que eso, ya que el servidor web puede responder a ellos en el orden que desee y enviar archivos en orden diferente, o incluso dividir cada archivo solicitado en pedazos y entremezclar los archivos.problema de bloqueo del jefe de línea ). Luego, el navegador web tiene la tarea de volver a unir todas las piezas. En el mejor de los casos (asumiendo que no hay límites de ancho de banda, ver más abajo), si las 10 solicitudes se envían prácticamente 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 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?).
Nota: HTTP / 1.1 tiene el concepto de canalización, que también permite que se envíen varias solicitudes a la vez. Sin embargo, todavía tenían que devolverse en el orden en que se solicitaron, en su totalidad, por lo que no son tan buenos como HTTP / 2, incluso si conceptualmente es similar. Sin mencionar el hecho de que tanto los navegadores como los servidores soportan tan mal que rara vez se utiliza.
Una cosa que se destaca en los comentarios a continuación es cómo nos afecta el ancho de banda aquí. Por supuesto, su conexión a Internet está limitada por la cantidad que puede descargar y HTTP / 2 no se ocupa de 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 lentos para descargar. 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 (en particular, recursos de texto como CSS y JavaScript que pueden ser comprimidos con gzip 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 se usa la concatenación en HTTP / 1.1 como otra solución alternativa, por lo que, por ejemplo, todo CSS a menudo se une en un solo archivo:anti-patró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 en 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 artículo hasta que llegue el último. Puede comprender 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 llegan en el orden específico que solicitó. Y si un artículo está agotado, tendrá que esperar antes de recibir 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 realizar pedidos 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 solicitó, e incluso pueden dividir los artículos para que algunas partes de ese pedido lleguen primero (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, así que podría querer 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. a la demora en enviar el pedido de un lado a otro. La mayor parte de la navegación web implica el envío de letras pequeñas de un lado a otro, en lugar de paquetes voluminosos.
Explicación impresionante. El ejemplo es lo que necesitaba para conseguir esto. Entonces, en HTTP / 1.1 hay una pérdida de tiempo entre esperar a que llegue la respuesta y enviar la siguiente solicitud. HTTP / 2 corrige esto. Gracias.
user3448600
1
Pero duro, creo. Podría haberme pedido simplemente que agregara un artículo sobre el ancho de banda, lo cual estoy feliz de hacer y lo haré después de que terminemos esta discusión. Sin embargo, en mi humilde opinión, el ancho de banda no es un problema tan grande para la navegación web (al menos en el mundo occidental), la latencia sí lo es. Y HTTP / 2 mejora la latencia. La mayoría de los sitios web se componen de muchos recursos pequeños e incluso si tiene el ancho de banda para descargarlos (como suele hacer la gente), será lento debido a la latencia de la red. El ancho de banda se convierte en un problema mayor para los grandes recursos. Estoy de acuerdo en que los sitios web con imágenes masivas y otros recursos aún pueden alcanzar un límite de ancho de banda.
Barry Pollard
1
HTTP no debe usarse para hacer cumplir los pedidos, porque no ofrece tales garantías. Con HTTP / 2 puede sugerir una prioridad para la entrega, pero no un pedido. Además, si uno de sus activos de JavaScript está almacenado en caché, pero el otro no, HTTP no puede influir ni siquiera en la prioridad. En su lugar, debe usar el orden en HTML junto con el uso apropiado de async o defer ( growwiththeweb.com/2014/02/async-vs-defer-attributes.html ), o una biblioteca como require.js.
Barry Pollard
1
Gran explicación ¡Gracias!
hmacias
2
Es porque HTTP / 1.1 es un flujo de texto y HTTP / 2 está basado en paquetes, bueno, en HTTP / 2 se llaman marcos en lugar de paquetes. Entonces, en HTTP / 2, cada cuadro se puede etiquetar en un flujo que permite el entrelazado de los cuadros. En HTTP / 1.1 no existe tal concepto, ya que es solo una serie de líneas de texto para el encabezado y luego el cuerpo. Más detalles aquí: stackoverflow.com/questions/58498116/…
Barry Pollard
5
Solicitar multiplexación
HTTP / 2 puede enviar múltiples solicitudes de datos en paralelo a través de una sola conexión TCP. Esta es la característica más avanzada del protocolo HTTP / 2 porque le permite descargar archivos web de forma asincrónica desde un servidor. La mayoría de los navegadores modernos limitan las conexiones TCP a un servidor. Esto reduce el tiempo adicional de ida y vuelta (RTT), lo que hace que su sitio web se cargue más rápido sin ninguna optimización y hace que la fragmentación del dominio sea innecesaria.
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 de DNS y los apretones de manos se guarda para los archivos que provienen del mismo servidor.
esto se puede lograr usando pipelining también en http 1.1. El propósito principal de la multiplexación en HTTP2 es no esperar las respuestas de manera ordenada
Dhairya Lakhera
3
La multiplexación en HTTP 2.0 es el tipo de relación entre el navegador y el servidor que usa una sola conexión para entregar múltiples solicitudes y respuestas en paralelo, creando muchas tramas individuales en este proceso.
La multiplexación rompe con la semántica estricta de solicitud-respuesta y permite relaciones de uno a muchos o de muchos a muchos.
Su ejemplo de multiplexación HTTP / 2 no muestra realmente multiplexación. El escenario en su diagrama muestra la canalización HTTP que se introdujo en HTTP / 1.1.
ich5003
@ ich5003 Es multiplexado porque usa una sola conexión. Pero también es cierto que allí no se representan los casos de envío de varias respuestas por una sola solicitud.
Juanma Menendez
1
Lo que trato de decir es que el escenario que se muestra arriba también se puede lograr solo usando canalización HTTP.
ich5003
Creo que la fuente de confusión aquí es el orden de solicitud / respuesta en el diagrama de la derecha: muestran un caso especial de multiplexación en HTTP / 2 que también se puede lograr mediante la canalización en HTTP / 1.1. Si el orden de respuesta en el diagrama fuera diferente del orden de la solicitud, no se produciría confusión.
raiks
1
Como la respuesta de @Juanma Menendez es correcta mientras que su diagrama es confuso, decidí mejorarlo, aclarando la diferencia entre multiplexación y canalización, las nociones que a menudo se combinan.
Canalización (HTTP / 1.1)
Se envían varias solicitudes a través de la misma conexión HTTP. Las respuestas se reciben en el mismo orden. Si la primera respuesta lleva mucho tiempo, otras respuestas deben esperar en la fila. Similar a la canalización de CPU donde se busca una instrucción mientras se decodifica otra. Varias instrucciones están en vuelo al mismo tiempo, pero su orden se conserva.
Multiplexación (HTTP / 2)
Se envían varias solicitudes a través de la misma conexión HTTP. Las respuestas se reciben en el orden arbitrario. No es necesario esperar una respuesta lenta que esté bloqueando a otros. Similar a la ejecución de instrucciones fuera de orden en las CPU modernas.
Con suerte, la imagen mejorada aclara la diferencia:
Respuestas:
En pocas palabras, la multiplexación permite que su navegador active varias solicitudes a la vez en la misma conexión y reciba las solicitudes en cualquier orden.
Y ahora 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, un montón de imágenes ... etc.
En 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 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 síncrono: una vez que envía una solicitud, está atascado hasta que obtenga una respuesta. Esto significa que la mayoría de las veces el navegador no hace 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 realice muchos procesos, pero eso depende de la descarga de JavaScript, por lo que, al menos al principio, los retrasos heredados de HTTP / 1.1 causan problemas. Normalmente, el servidor no es
Entonces, uno de los principales problemas en la web hoy en día es la latencia de la red en el envío de solicitudes entre el navegador y el servidor. Puede ser solo 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 (a medida que se obtienen) y acceso a Internet. es cada vez más a través de dispositivos móviles (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 y lo seguiremos. ejemplo). Y digamos que cada solicitud tarda 100 ms en viajar a través de Internet al servidor web y viceversa y el tiempo de procesamiento en cada extremo es insignificante (digamos 0 en este ejemplo por simplicidad). Como tienes que enviar cada recurso y esperar una respuesta uno a la vez, esto tomará 10 * 100ms = 1,000ms 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 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, para simplificar, 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 tiempos redondos o 300 ms = 0,3 segundos; una buena mejora, pero este simple ejemplo no incluye el costo de configurar esas conexiones múltiples.
HTTP / 2 le permite enviar múltiples solicitudes en el mismoconexión, por lo que no es necesario abrir varias conexiones como se indica arriba. Para que su navegador pueda decir "Dame este archivo CSS. Dame ese archivo JavaScript. Dame image1.jpg. Dame image2.jpg ... Etc." para utilizar plenamente la única conexión. Esto tiene el beneficio obvio de rendimiento 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 incluso más poderoso que eso, ya que el servidor web puede responder a ellos en el orden que desee y enviar archivos en orden diferente, o incluso dividir cada archivo solicitado en pedazos y entremezclar los archivos.problema de bloqueo del jefe de línea ). Luego, el navegador web tiene la tarea de volver a unir todas las piezas. En el mejor de los casos (asumiendo que no hay límites de ancho de banda, ver más abajo), si las 10 solicitudes se envían prácticamente 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 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 que se envíen varias solicitudes a la vez. Sin embargo, todavía tenían que devolverse en el orden en que se solicitaron, en su totalidad, por lo que no son tan buenos como HTTP / 2, incluso si conceptualmente es similar. Sin mencionar el hecho de que tanto los navegadores como los servidores soportan tan mal que rara vez se utiliza.
Una cosa que se destaca en los comentarios a continuación es cómo nos afecta el ancho de banda aquí. Por supuesto, su conexión a Internet está limitada por la cantidad que puede descargar y HTTP / 2 no se ocupa de 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 lentos para descargar. 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 (en particular, recursos de texto como CSS y JavaScript que pueden ser comprimidos con gzip 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 se usa la concatenación en HTTP / 1.1 como otra solución alternativa, por lo que, por ejemplo, todo CSS a menudo se une en un solo archivo:anti-patró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 en 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 artículo hasta que llegue el último. Puede comprender 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 llegan en el orden específico que solicitó. Y si un artículo está agotado, tendrá que esperar antes de recibir 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 realizar pedidos 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 solicitó, e incluso pueden dividir los artículos para que algunas partes de ese pedido lleguen primero (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, así que podría querer 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. a la demora en enviar el pedido de un lado a otro. La mayor parte de la navegación web implica el envío de letras pequeñas de un lado a otro, en lugar de paquetes voluminosos.
Espero que ayude.
fuente
Solicitar multiplexación
HTTP / 2 puede enviar múltiples solicitudes de datos en paralelo a través de una sola conexión TCP. Esta es la característica más avanzada del protocolo HTTP / 2 porque le permite descargar archivos web de forma asincrónica desde un servidor. La mayoría de los navegadores modernos limitan las conexiones TCP a un servidor. Esto reduce el tiempo adicional de ida y vuelta (RTT), lo que hace que su sitio web se cargue más rápido sin ninguna optimización y hace que la fragmentación del dominio sea innecesaria.
fuente
Respuesta simple ( fuente ):
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 de DNS y los apretones de manos se guarda para los archivos que provienen del mismo servidor.
Respuesta compleja / detallada:
Busque la respuesta proporcionada por @BazzaDP.
fuente
La multiplexación en HTTP 2.0 es el tipo de relación entre el navegador y el servidor que usa una sola conexión para entregar múltiples solicitudes y respuestas en paralelo, creando muchas tramas individuales en este proceso.
La multiplexación rompe con la semántica estricta de solicitud-respuesta y permite relaciones de uno a muchos o de muchos a muchos.
fuente
Como la respuesta de @Juanma Menendez es correcta mientras que su diagrama es confuso, decidí mejorarlo, aclarando la diferencia entre multiplexación y canalización, las nociones que a menudo se combinan.
Canalización (HTTP / 1.1)
Se envían varias solicitudes a través de la misma conexión HTTP. Las respuestas se reciben en el mismo orden. Si la primera respuesta lleva mucho tiempo, otras respuestas deben esperar en la fila. Similar a la canalización de CPU donde se busca una instrucción mientras se decodifica otra. Varias instrucciones están en vuelo al mismo tiempo, pero su orden se conserva.
Multiplexación (HTTP / 2)
Se envían varias solicitudes a través de la misma conexión HTTP. Las respuestas se reciben en el orden arbitrario. No es necesario esperar una respuesta lenta que esté bloqueando a otros. Similar a la ejecución de instrucciones fuera de orden en las CPU modernas.
Con suerte, la imagen mejorada aclara la diferencia:
fuente