En termes simples, le multiplexage permet à votre navigateur de déclencher plusieurs demandes à la fois sur la même connexion et de recevoir les demandes dans n'importe quel ordre.
Et maintenant pour la réponse beaucoup plus compliquée ...
Lorsque vous chargez une page Web, il télécharge la page HTML, il voit qu'elle a besoin de CSS, de JavaScript, d'une charge d'images ... etc.
Sous HTTP / 1.1, vous ne pouvez en télécharger qu'un seul à la fois sur votre connexion HTTP / 1.1. Ainsi, votre navigateur télécharge le HTML, puis il demande le fichier CSS. Lorsque cela est retourné, il demande le fichier JavaScript. Quand cela est retourné, il demande le premier fichier image ... etc. HTTP / 1.1 est fondamentalement synchrone - une fois que vous envoyez une requête, vous êtes bloqué jusqu'à ce que vous obteniez une réponse. Cela signifie que la plupart du temps, le navigateur ne fait pas grand-chose, car il a déclenché une requête, attend une réponse, puis déclenche une autre requête, puis attend une réponse ... etc. Bien sûr, des sites complexes avec beaucoup de JavaScript nécessitent que le navigateur effectue beaucoup de traitement, mais cela dépend du JavaScript téléchargé donc, au moins pour le début, les retards hérités de HTTP / 1.1 posent des problèmes. En général, le serveur n'est pas
L'un des principaux problèmes sur le Web aujourd'hui est donc la latence du réseau dans l'envoi des requêtes entre le navigateur et le serveur. Cela peut ne prendre que des dizaines ou peut-être des centaines de millisecondes, ce qui peut sembler peu, mais ils s'additionnent et sont souvent la partie la plus lente de la navigation Web - d'autant plus que les sites Web deviennent plus complexes et nécessitent des ressources supplémentaires (au fur et à mesure qu'ils obtiennent) et un accès Internet est de plus en plus via mobile (avec une latence plus lente que le haut débit).
À titre d'exemple, disons qu'il y a 10 ressources que votre page Web a besoin de charger après le chargement du HTML lui-même (ce qui est un très petit site selon les normes d'aujourd'hui car plus de 100 ressources sont courantes, mais nous allons rester simple et continuer avec cela exemple). Et disons que chaque requête prend 100 ms pour voyager sur Internet vers le serveur Web et inversement et que le temps de traitement à chaque extrémité est négligeable (disons 0 pour cet exemple pour des raisons de simplicité). Comme vous devez envoyer chaque ressource et attendre une réponse une par une, cela prendra 10 * 100 ms = 1 000 ms ou 1 seconde pour télécharger l'ensemble du site.
Pour contourner ce problème, les navigateurs ouvrent généralement plusieurs connexions au serveur Web (généralement 6). Cela signifie qu'un navigateur peut déclencher plusieurs demandes en même temps, ce qui est bien mieux, mais au prix de la complexité de devoir configurer et gérer plusieurs connexions (ce qui a un impact à la fois sur le navigateur et le serveur). Continuons l'exemple précédent et disons également qu'il y a 4 connexions et, pour simplifier, disons que toutes les demandes sont égales. Dans ce cas, vous pouvez diviser les demandes sur les quatre connexions, donc deux auront 3 ressources à obtenir, et deux auront 2 ressources pour obtenir totalement les dix ressources (3 + 3 + 2 + 2 = 10). Dans ce cas, le pire des cas est de 3 tours ou 300 ms = 0,3 seconde - une bonne amélioration, mais cet exemple simple n'inclut pas le coût de mise en place de ces connexions multiples,
HTTP / 2 vous permet d'envoyer plusieurs requêtes sur le mêmeconnexion - vous n'avez donc pas besoin d'ouvrir plusieurs connexions comme ci-dessus. Ainsi, votre navigateur peut dire "Donnez-moi ce fichier CSS. Donnez-moi ce fichier JavaScript. Gimmez l'image1.jpg. Gimmez l'image2.jpg ... Etc." pour utiliser pleinement la connexion unique. Cela présente l'avantage évident en termes de performances de ne pas retarder l'envoi de ces demandes en attente d'une connexion gratuite. Toutes ces requêtes transitent par Internet vers le serveur en (presque) parallèle. Le serveur répond à chacun d'eux, puis ils commencent à revenir. En fait, c'est encore plus puissant que cela car le serveur Web peut y répondre dans n'importe quel ordre et renvoyer les fichiers dans un ordre différent, ou même diviser chaque fichier demandé en morceaux et mélanger les fichiers ensemble.problème de blocage de tête de ligne ). Le navigateur Web est alors chargé de rassembler toutes les pièces. Dans le meilleur des cas (en supposant qu'aucune limite de bande passante - voir ci-dessous), si les 10 demandes sont déclenchées à peu près en même temps et reçoivent une réponse immédiate du serveur, cela signifie que vous avez essentiellement un aller-retour ou 100 ms ou 0,1 seconde, pour téléchargez les 10 ressources. Et cela n'a aucun des inconvénients que plusieurs connexions avaient pour HTTP / 1.1! Ceci est également beaucoup plus évolutif à mesure que les ressources sur chaque site Web augmentent (actuellement, les navigateurs ouvrent jusqu'à 6 connexions parallèles sous HTTP / 1.1, mais cela devrait-il augmenter à mesure que les sites deviennent plus complexes?).
Remarque: HTTP / 1.1 a le concept de pipelining qui permet également d'envoyer plusieurs requêtes à la fois. Cependant, ils devaient encore être retournés afin qu'ils aient été demandés, dans leur intégralité, donc loin d'être aussi bons que HTTP / 2, même si conceptuellement c'est similaire. Sans parler du fait que cela est si mal pris en charge par les navigateurs et les serveurs qu'il est rarement utilisé.
Une chose mise en évidence dans les commentaires ci-dessous est l'impact de la bande passante sur nous. Bien sûr, votre connexion Internet est limitée par la quantité que vous pouvez télécharger et HTTP / 2 ne résout pas cela. Donc, si ces 10 ressources décrites dans les exemples ci-dessus sont toutes des images de qualité d'impression massive, elles seront toujours lentes à télécharger. Cependant, pour la plupart des navigateurs Web, la bande passante pose moins de problème que la latence. Donc, si ces dix ressources sont de petits éléments (en particulier les ressources textuelles comme CSS et JavaScript qui peuvent être gzippées pour être minuscules), comme cela est très courant sur les sites Web, alors la bande passante n'est pas vraiment un problème - c'est le simple volume de ressources qui est souvent le problème et HTTP / 2 cherche à résoudre ce problème. C'est également pourquoi la concaténation est utilisée dans HTTP / 1.1 comme une autre solution de contournement, par exemple, tous les CSS sont souvent réunis dans un seul fichier:anti-pattern sous HTTP / 2 - bien qu'il y ait des arguments contre le supprimer complètement aussi).
Pour donner un exemple concret: supposons que vous deviez commander 10 articles dans un magasin pour une livraison à domicile:
HTTP / 1.1 avec une connexion signifie que vous devez les commander un par un et que vous ne pouvez pas commander l'article suivant avant que le dernier n'arrive. Vous pouvez comprendre qu'il faudrait des semaines pour tout traverser.
HTTP / 1.1 avec plusieurs connexions signifie que vous pouvez avoir un nombre (limité) de commandes indépendantes en même temps.
HTTP / 1.1 avec pipelining signifie que vous pouvez demander les 10 éléments l'un après l'autre sans attendre, mais ils arrivent tous dans l'ordre spécifique que vous avez demandé. Et si un article est en rupture de stock, vous devez attendre cela avant de recevoir les articles que vous avez commandés par la suite - même si ces derniers sont réellement en stock! C'est un peu mieux mais c'est toujours sujet à des retards, et disons que la plupart des magasins ne supportent pas cette façon de commander de toute façon.
HTTP / 2 signifie que vous pouvez commander vos articles dans n'importe quel ordre particulier - sans aucun délai (similaire à ci-dessus). La boutique les expédiera au fur et à mesure qu'ils sont prêts, de sorte qu'ils peuvent arriver dans un ordre différent de celui que vous avez demandé, et ils peuvent même diviser les articles afin que certaines parties de cette commande arrivent en premier (donc mieux que ci-dessus). En fin de compte, cela devrait signifier que vous 1) obtenez tout plus rapidement dans l'ensemble et 2) pouvez commencer à travailler sur chaque élément au fur et à mesure qu'il arrive ("oh ce n'est pas aussi beau que je le pensais, alors je pourrais peut-être commander autre chose aussi ou à la place" ).
Bien sûr, vous êtes toujours limité par la taille de la fourgonnette de votre facteur (la bande passante), donc ils devront peut-être laisser certains colis au bureau de tri jusqu'au lendemain s'ils sont pleins pour ce jour-là, mais c'est rarement un problème comparé au retard dans l'envoi de la commande et inversement. La plupart de la navigation sur le Web implique l'envoi de petites lettres dans les deux sens, plutôt que des colis volumineux.
Explication géniale. L'exemple est ce dont j'avais besoin pour obtenir cela. Donc, dans HTTP / 1.1, il y a une perte de temps entre l'attente de la réponse à venir et l'envoi de la prochaine requête. HTTP / 2 corrige ce problème. Je vous remercie.
user3448600
1
Mais dur je pense. J'aurais pu simplement me demander d'ajouter un article sur la bande passante - ce que je suis heureux de faire et que je ferai après la fin de cette discussion. Cependant, la bande passante IMHO n'est pas un problème aussi important pour la navigation Web (du moins dans le monde occidental) - la latence l'est. Et HTTP / 2 améliore la latence. La plupart des sites Web sont constitués de nombreuses petites ressources et même si vous avez la bande passante pour les télécharger (comme le font souvent les gens), cela sera lent en raison de la latence du réseau. La bande passante devient plus un problème pour les grandes ressources. Je conviens que ces sites Web avec des images massives et d'autres ressources peuvent toujours atteindre une limite de bande passante.
Barry Pollard
1
HTTP ne doit pas être utilisé pour imposer la commande - car il n'offre pas de telles garanties. Avec HTTP / 2, vous pouvez suggérer une priorité de livraison, mais pas une commande. De plus, si l'un de vos actifs JavaScript est mis en cache, mais que l'autre ne l'est pas, HTTP ne peut même pas influencer la priorité. Au lieu de cela, vous devriez utiliser l'ordre dans le HTML couplé à une utilisation appropriée de async ou defer ( croissant avec leweb.com/2014/02/async-vs-defer-attributes.html ), ou une bibliothèque comme require.js.
Barry Pollard
1
Excellente explication. Merci!
hmacias
2
C'est parce que HTTP / 1.1 est un flux de texte et HTTP / 2 est basé sur des paquets - eh bien, ils sont appelés trames dans HTTP / 2 plutôt que paquets. Ainsi, dans HTTP / 2, chaque trame peut être étiquetée sur un flux qui permet l'entrelacement des trames. Dans HTTP / 1.1, ce concept n'existe pas car il s'agit simplement d'une série de lignes de texte pour l'en-tête, puis le corps. Plus de détails ici: stackoverflow.com/questions/58498116/…
Barry Pollard
5
Demander le multiplexage
HTTP / 2 peut envoyer plusieurs demandes de données en parallèle sur une seule connexion TCP. Il s'agit de la fonctionnalité la plus avancée du protocole HTTP / 2 car elle vous permet de télécharger des fichiers Web de manière asynchrone à partir d'un serveur. La plupart des navigateurs modernes limitent les connexions TCP à un serveur. Cela réduit le temps d'aller-retour supplémentaire (RTT), ce qui accélère le chargement de votre site Web sans aucune optimisation et rend le partage de domaine inutile.
Le multiplexage signifie que votre navigateur peut envoyer plusieurs requêtes et recevoir plusieurs réponses «groupées» dans une seule connexion TCP. Ainsi, la charge de travail associée aux recherches DNS et aux prises de contact est enregistrée pour les fichiers provenant du même serveur.
ceci peut être réalisé en utilisant le pipelining également dans http 1.1. L'objectif principal du multiplexage dans HTTP2 est de ne pas attendre les réponses de manière ordonnée
Dhairya Lakhera
3
Le multiplexage dans HTTP 2.0 est le type de relation entre le navigateur et le serveur qui utilise une seule connexion pour fournir plusieurs demandes et réponses en parallèle, créant de nombreuses trames individuelles dans ce processus.
Le multiplexage s'éloigne de la sémantique stricte requête-réponse et permet des relations un-à-plusieurs ou plusieurs-à-plusieurs.
Votre exemple de multiplexage HTTP / 2 ne montre pas vraiment le multiplexage. Le scénario de votre diagramme montre le pipelining HTTP qui a été introduit dans HTTP / 1.1.
ich5003 le
@ ich5003 Il s'agit d'un multiplexage car il utilise une seule connexion. Mais il est également vrai que les cas d'envoi de plusieurs réponses pour une seule requête n'y sont pas représentés.
Juanma Menendez le
1
ce que j'essaie de dire, que le scénario présenté ci-dessus est également réalisable uniquement en utilisant le pipeline HTTP.
ich5003 le
Je pense que la source de confusion ici est l'ordre de la demande / réponse dans le diagramme de droite - ils affichent un cas particulier de multiplexage dans HTTP / 2 qui peut également être réalisé par pipelining dans HTTP / 1.1. Si l'ordre de réponse dans le diagramme était différent de l'ordre de demande, aucune confusion ne se produirait.
raiks
1
Puisque la réponse de @Juanma Menendez est correcte alors que son diagramme est déroutant, j'ai décidé de l'améliorer, en clarifiant la différence entre le multiplexage et le pipelining, les notions qui sont souvent confondues.
Pipeline (HTTP / 1.1)
Plusieurs demandes sont envoyées via la même connexion HTTP. Les réponses sont reçues dans le même ordre. Si la première réponse prend beaucoup de temps, les autres réponses doivent faire la queue. Similaire au pipeline CPU où une instruction est récupérée tandis qu'une autre est en cours de décodage. Plusieurs instructions sont en vol en même temps, mais leur ordre est conservé.
Multiplexage (HTTP / 2)
Plusieurs demandes sont envoyées via la même connexion HTTP. Les réponses sont reçues dans un ordre arbitraire. Pas besoin d'attendre une réponse lente qui bloque les autres. Similaire à l'exécution d'instructions dans le désordre dans les processeurs modernes.
Espérons que l'image améliorée clarifie la différence:
Réponses:
En termes simples, le multiplexage permet à votre navigateur de déclencher plusieurs demandes à la fois sur la même connexion et de recevoir les demandes dans n'importe quel ordre.
Et maintenant pour la réponse beaucoup plus compliquée ...
Lorsque vous chargez une page Web, il télécharge la page HTML, il voit qu'elle a besoin de CSS, de JavaScript, d'une charge d'images ... etc.
Sous HTTP / 1.1, vous ne pouvez en télécharger qu'un seul à la fois sur votre connexion HTTP / 1.1. Ainsi, votre navigateur télécharge le HTML, puis il demande le fichier CSS. Lorsque cela est retourné, il demande le fichier JavaScript. Quand cela est retourné, il demande le premier fichier image ... etc. HTTP / 1.1 est fondamentalement synchrone - une fois que vous envoyez une requête, vous êtes bloqué jusqu'à ce que vous obteniez une réponse. Cela signifie que la plupart du temps, le navigateur ne fait pas grand-chose, car il a déclenché une requête, attend une réponse, puis déclenche une autre requête, puis attend une réponse ... etc. Bien sûr, des sites complexes avec beaucoup de JavaScript nécessitent que le navigateur effectue beaucoup de traitement, mais cela dépend du JavaScript téléchargé donc, au moins pour le début, les retards hérités de HTTP / 1.1 posent des problèmes. En général, le serveur n'est pas
L'un des principaux problèmes sur le Web aujourd'hui est donc la latence du réseau dans l'envoi des requêtes entre le navigateur et le serveur. Cela peut ne prendre que des dizaines ou peut-être des centaines de millisecondes, ce qui peut sembler peu, mais ils s'additionnent et sont souvent la partie la plus lente de la navigation Web - d'autant plus que les sites Web deviennent plus complexes et nécessitent des ressources supplémentaires (au fur et à mesure qu'ils obtiennent) et un accès Internet est de plus en plus via mobile (avec une latence plus lente que le haut débit).
À titre d'exemple, disons qu'il y a 10 ressources que votre page Web a besoin de charger après le chargement du HTML lui-même (ce qui est un très petit site selon les normes d'aujourd'hui car plus de 100 ressources sont courantes, mais nous allons rester simple et continuer avec cela exemple). Et disons que chaque requête prend 100 ms pour voyager sur Internet vers le serveur Web et inversement et que le temps de traitement à chaque extrémité est négligeable (disons 0 pour cet exemple pour des raisons de simplicité). Comme vous devez envoyer chaque ressource et attendre une réponse une par une, cela prendra 10 * 100 ms = 1 000 ms ou 1 seconde pour télécharger l'ensemble du site.
Pour contourner ce problème, les navigateurs ouvrent généralement plusieurs connexions au serveur Web (généralement 6). Cela signifie qu'un navigateur peut déclencher plusieurs demandes en même temps, ce qui est bien mieux, mais au prix de la complexité de devoir configurer et gérer plusieurs connexions (ce qui a un impact à la fois sur le navigateur et le serveur). Continuons l'exemple précédent et disons également qu'il y a 4 connexions et, pour simplifier, disons que toutes les demandes sont égales. Dans ce cas, vous pouvez diviser les demandes sur les quatre connexions, donc deux auront 3 ressources à obtenir, et deux auront 2 ressources pour obtenir totalement les dix ressources (3 + 3 + 2 + 2 = 10). Dans ce cas, le pire des cas est de 3 tours ou 300 ms = 0,3 seconde - une bonne amélioration, mais cet exemple simple n'inclut pas le coût de mise en place de ces connexions multiples,
HTTP / 2 vous permet d'envoyer plusieurs requêtes sur le mêmeconnexion - vous n'avez donc pas besoin d'ouvrir plusieurs connexions comme ci-dessus. Ainsi, votre navigateur peut dire "Donnez-moi ce fichier CSS. Donnez-moi ce fichier JavaScript. Gimmez l'image1.jpg. Gimmez l'image2.jpg ... Etc." pour utiliser pleinement la connexion unique. Cela présente l'avantage évident en termes de performances de ne pas retarder l'envoi de ces demandes en attente d'une connexion gratuite. Toutes ces requêtes transitent par Internet vers le serveur en (presque) parallèle. Le serveur répond à chacun d'eux, puis ils commencent à revenir. En fait, c'est encore plus puissant que cela car le serveur Web peut y répondre dans n'importe quel ordre et renvoyer les fichiers dans un ordre différent, ou même diviser chaque fichier demandé en morceaux et mélanger les fichiers ensemble.problème de blocage de tête de ligne ). Le navigateur Web est alors chargé de rassembler toutes les pièces. Dans le meilleur des cas (en supposant qu'aucune limite de bande passante - voir ci-dessous), si les 10 demandes sont déclenchées à peu près en même temps et reçoivent une réponse immédiate du serveur, cela signifie que vous avez essentiellement un aller-retour ou 100 ms ou 0,1 seconde, pour téléchargez les 10 ressources. Et cela n'a aucun des inconvénients que plusieurs connexions avaient pour HTTP / 1.1! Ceci est également beaucoup plus évolutif à mesure que les ressources sur chaque site Web augmentent (actuellement, les navigateurs ouvrent jusqu'à 6 connexions parallèles sous HTTP / 1.1, mais cela devrait-il augmenter à mesure que les sites deviennent plus complexes?).
Ce diagramme montre les différences et il existe également une version animée .
Remarque: HTTP / 1.1 a le concept de pipelining qui permet également d'envoyer plusieurs requêtes à la fois. Cependant, ils devaient encore être retournés afin qu'ils aient été demandés, dans leur intégralité, donc loin d'être aussi bons que HTTP / 2, même si conceptuellement c'est similaire. Sans parler du fait que cela est si mal pris en charge par les navigateurs et les serveurs qu'il est rarement utilisé.
Une chose mise en évidence dans les commentaires ci-dessous est l'impact de la bande passante sur nous. Bien sûr, votre connexion Internet est limitée par la quantité que vous pouvez télécharger et HTTP / 2 ne résout pas cela. Donc, si ces 10 ressources décrites dans les exemples ci-dessus sont toutes des images de qualité d'impression massive, elles seront toujours lentes à télécharger. Cependant, pour la plupart des navigateurs Web, la bande passante pose moins de problème que la latence. Donc, si ces dix ressources sont de petits éléments (en particulier les ressources textuelles comme CSS et JavaScript qui peuvent être gzippées pour être minuscules), comme cela est très courant sur les sites Web, alors la bande passante n'est pas vraiment un problème - c'est le simple volume de ressources qui est souvent le problème et HTTP / 2 cherche à résoudre ce problème. C'est également pourquoi la concaténation est utilisée dans HTTP / 1.1 comme une autre solution de contournement, par exemple, tous les CSS sont souvent réunis dans un seul fichier:anti-pattern sous HTTP / 2 - bien qu'il y ait des arguments contre le supprimer complètement aussi).
Pour donner un exemple concret: supposons que vous deviez commander 10 articles dans un magasin pour une livraison à domicile:
HTTP / 1.1 avec une connexion signifie que vous devez les commander un par un et que vous ne pouvez pas commander l'article suivant avant que le dernier n'arrive. Vous pouvez comprendre qu'il faudrait des semaines pour tout traverser.
HTTP / 1.1 avec plusieurs connexions signifie que vous pouvez avoir un nombre (limité) de commandes indépendantes en même temps.
HTTP / 1.1 avec pipelining signifie que vous pouvez demander les 10 éléments l'un après l'autre sans attendre, mais ils arrivent tous dans l'ordre spécifique que vous avez demandé. Et si un article est en rupture de stock, vous devez attendre cela avant de recevoir les articles que vous avez commandés par la suite - même si ces derniers sont réellement en stock! C'est un peu mieux mais c'est toujours sujet à des retards, et disons que la plupart des magasins ne supportent pas cette façon de commander de toute façon.
HTTP / 2 signifie que vous pouvez commander vos articles dans n'importe quel ordre particulier - sans aucun délai (similaire à ci-dessus). La boutique les expédiera au fur et à mesure qu'ils sont prêts, de sorte qu'ils peuvent arriver dans un ordre différent de celui que vous avez demandé, et ils peuvent même diviser les articles afin que certaines parties de cette commande arrivent en premier (donc mieux que ci-dessus). En fin de compte, cela devrait signifier que vous 1) obtenez tout plus rapidement dans l'ensemble et 2) pouvez commencer à travailler sur chaque élément au fur et à mesure qu'il arrive ("oh ce n'est pas aussi beau que je le pensais, alors je pourrais peut-être commander autre chose aussi ou à la place" ).
Bien sûr, vous êtes toujours limité par la taille de la fourgonnette de votre facteur (la bande passante), donc ils devront peut-être laisser certains colis au bureau de tri jusqu'au lendemain s'ils sont pleins pour ce jour-là, mais c'est rarement un problème comparé au retard dans l'envoi de la commande et inversement. La plupart de la navigation sur le Web implique l'envoi de petites lettres dans les deux sens, plutôt que des colis volumineux.
J'espère que cela pourra aider.
la source
Demander le multiplexage
HTTP / 2 peut envoyer plusieurs demandes de données en parallèle sur une seule connexion TCP. Il s'agit de la fonctionnalité la plus avancée du protocole HTTP / 2 car elle vous permet de télécharger des fichiers Web de manière asynchrone à partir d'un serveur. La plupart des navigateurs modernes limitent les connexions TCP à un serveur. Cela réduit le temps d'aller-retour supplémentaire (RTT), ce qui accélère le chargement de votre site Web sans aucune optimisation et rend le partage de domaine inutile.
la source
Réponses simples ( source ):
Le multiplexage signifie que votre navigateur peut envoyer plusieurs requêtes et recevoir plusieurs réponses «groupées» dans une seule connexion TCP. Ainsi, la charge de travail associée aux recherches DNS et aux prises de contact est enregistrée pour les fichiers provenant du même serveur.
Réponses complexes / détaillées:
Regardez la réponse fournie par @BazzaDP.
la source
Le multiplexage dans HTTP 2.0 est le type de relation entre le navigateur et le serveur qui utilise une seule connexion pour fournir plusieurs demandes et réponses en parallèle, créant de nombreuses trames individuelles dans ce processus.
Le multiplexage s'éloigne de la sémantique stricte requête-réponse et permet des relations un-à-plusieurs ou plusieurs-à-plusieurs.
la source
Puisque la réponse de @Juanma Menendez est correcte alors que son diagramme est déroutant, j'ai décidé de l'améliorer, en clarifiant la différence entre le multiplexage et le pipelining, les notions qui sont souvent confondues.
Pipeline (HTTP / 1.1)
Plusieurs demandes sont envoyées via la même connexion HTTP. Les réponses sont reçues dans le même ordre. Si la première réponse prend beaucoup de temps, les autres réponses doivent faire la queue. Similaire au pipeline CPU où une instruction est récupérée tandis qu'une autre est en cours de décodage. Plusieurs instructions sont en vol en même temps, mais leur ordre est conservé.
Multiplexage (HTTP / 2)
Plusieurs demandes sont envoyées via la même connexion HTTP. Les réponses sont reçues dans un ordre arbitraire. Pas besoin d'attendre une réponse lente qui bloque les autres. Similaire à l'exécution d'instructions dans le désordre dans les processeurs modernes.
Espérons que l'image améliorée clarifie la différence:
la source