Quelqu'un pourrait-il expliquer le multiplexage par rapport à HTTP / 2 et comment cela fonctionne?
Réponses
Trop de publicités?
Simplement dit, le multiplexage permet à votre Navigateur d'incendie à plusieurs demandes à la fois sur la même connexion et de recevoir les demandes de retour dans n'importe quel ordre.
Et maintenant, pour le beaucoup plus compliqué de réponse...
Lorsque vous chargez une page web, il télécharge la page HTML, il voit il a besoin d'un peu de CSS, JavaScript, un chargement des images... etc.
En vertu de HTTP/1.1, vous ne pouvez télécharger l'un de ceux qui à un moment de votre HTTP/1.1 connexion. Si votre navigateur télécharge le code HTML, puis il demande le fichier CSS. Quand c'est revenu, elle demande le fichier JavaScript. Quand c'est revenu, elle demande la première image du fichier... etc. HTTP/1.1 est fondamentalement synchrone - une fois que vous envoyez une demande, vous êtes coincé jusqu'à ce que vous obtenez une réponse. Cela signifie que la plupart du temps, le navigateur ne va pas très bien, comme il l'a tiré d'une demande, est en attente d'une réponse, puis déclenche une autre demande est en attente d'une réponse... etc. Bien sûr, les sites complexes avec beaucoup de JavaScript ne nécessitent le Navigateur de faire beaucoup de traitement, mais cela dépend de l'JavaScript être téléchargé ainsi, au moins pour le début, les délais d'hériter de HTTP/1.1 ne causer des problèmes. Généralement, le serveur n'est pas très souvent (au moins par demande - bien sûr, ils s'additionnent pour les sites), car il doit répondre presque instantanément pour les ressources statiques (comme CSS, JavaScript, images, polices, etc...) et j'espère ne pas trop longtemps, même pour les requêtes dynamiques (qui nécessitent une base de données d'appel ou similaire).
Ainsi, l'une des principales questions sur le web d'aujourd'hui est la latence du réseau pour l'envoi de la demande entre le navigateur et le serveur. Il ne peut y avoir des dizaines ou peut-être des centaines de millisecondes, ce qui peut ne pas sembler beaucoup, mais ils s'additionnent et sont souvent la partie la plus lente de navigation sur le web, en particulier les sites web deviennent plus complexes et nécessitent des ressources supplémentaires (qu'ils sont) et l'accès à Internet est de plus en plus via le mobile (avec un ralentissement de la latence de la large bande).
Comme un exemple, nous allons dire qu'il y a 10 ressources de votre page web doit charger après le HTML est chargé lui-même (qui est un très petit site par les normes d'aujourd'hui que plus de 100 ressources est commun, mais nous allons garder les choses simples et aller avec cet exemple). Et disons que chaque demande de 100ms à voyager à travers l'Internet pour le serveur web et le dos, et le temps de traitement à la fin est négligeable (disons 0 pour cet exemple par souci de simplicité). Comme vous l'avez envoyer chaque ressource et d'attendre une réponse à un moment, cela va prendre 10 * 100 ms = 1000 ms ou 1 seconde pour télécharger l'ensemble du site.
Pour contourner ce problème, les navigateurs habitude d'ouvrir 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 beaucoup mieux, mais au prix de la complexité d'avoir à mettre en place et gérer plusieurs connexions (qui a des répercussions à la fois le navigateur et le serveur). Nous allons continuer avec l'exemple précédent, et aussi il y a 4 connexions et, pour simplifier, disons que toutes les demandes sont égaux. Dans ce cas, vous pouvez diviser la demande dans l'ensemble des quatre connexions, donc deux aura 3 ressources pour obtenir, et deux 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 300ms = 0,3 secondes - une bonne amélioration, mais ce simple exemple ne comprend pas le coût de la configuration de ces multiples connexions, ni les répercussions sur les ressources de leur gestion (je n'en ai pas disparu ici que cette réponse est assez long déjà, mais la mise en place des connexions TCP prend du temps et d'autres ressources pour faire la connexion TCP, HTTPS poignée de main et puis se lever à pleine vitesse en raison de TCP démarrage lent).
HTTP/2 vous permet d'envoyer plusieurs requêtes sur la même connexion, vous n'avez donc pas besoin d'ouvrir plusieurs connexions comme indiqué ci-dessus. Si votre navigateur peut dire "donne-Moi ce fichier CSS. Gimme qu'fichier JavaScript. Gimme image1.jpg. Gimme image2.jpg... Etc". afin d'utiliser pleinement le un unique de connexion. Cela a évidentes de performances avantage de ne pas retarder l'envoi de ces demandes en attente d'une connexion gratuite. Toutes ces demandes font leur chemin par le biais de l'Internet pour le serveur en parallèle. Le serveur répond à chacun, et puis ils commencent à faire leur chemin de retour. En fait, il est même plus puissant que celui que le serveur web puisse y répondre dans n'importe quel ordre il se sent comme et envoyer des fichiers dans un ordre différent, ou même casser chaque fichier demandé en morceaux et mélanger l'ensemble des fichiers. Cela a l'avantage secondaire d'un lourd demande de ne pas bloquer toutes les autres demandes (connu sous le nom de la tête de ligne de blocage de l'émission). Le navigateur web est alors chargé de mettre tous les morceaux ensemble. Dans le meilleur des cas (en supposant qu'aucun des limites de bande passante - voir ci-dessous), si toutes les 10 demandes sont tiré assez bien à la fois en parallèle, et sont traitées par le serveur immédiatement, ce qui signifie en gros, vous avez un voyage aller-retour ou 100ms ou 0,1 secondes, pour télécharger tous les 10 ressources. Et cela n'en a aucun des inconvénients que plusieurs connexions a pour HTTP/1.1! C'est aussi beaucoup plus évolutif que les ressources sur chaque site de croître (actuellement navigateurs ouverts jusqu'à 6 connexions parallèles en vertu de HTTP/1.1, mais devrait croître que des sites plus complexe?).
Ce diagramme montre les différences, et il y a une version animée de trop.
Remarque: HTTP/1.1 le concept de pipeline qui permet aussi à de multiples demandes à être envoyé à la fois. Cependant, ils ont dû être retournées dans l'ordre où elles ont été demandées, dans leur intégralité, de sorte que nulle part près aussi bon que HTTP/2, même si conceptuellement similaire. De ne pas mentionner le fait que ce est si mal pris en charge par les navigateurs et les serveurs qu'il est rarement utilisé.
Une chose souligné dans les commentaires ci-dessous est la façon dont la bande passante effets sur nous ici. Bien sûr, votre connexion Internet est limitée par la façon dont beaucoup vous pouvez télécharger et de HTTP/2 n'a pas d'adresse. Donc, si ces 10 ressources examinées dans les exemples ci-dessus sont tous les massifs de qualité d'impression des images, puis ils vont encore être lent à télécharger. Cependant, pour la plupart des navigateur web, la bande passante est moins un problème de latence. Donc, si ces dix ressources sont de petits éléments (en particulier le texte de ressources comme le CSS et le JavaScript qui peut être au format gzip être minuscule), comme c'est très fréquent sur les sites internet, la bande passante n'est pas vraiment un problème - c'est le volume de ressources qu'est le problème et HTTP/2 ressemble à s'en occuper. C'est aussi pourquoi la concaténation est utilisé dans HTTP/1.1, une autre solution de contournement, par exemple, tous les CSS est souvent réunis en un seul fichier: le montant de la CSS téléchargé est la même, mais en le faisant comme une ressource il y a d'énormes avantages de performance (bien qu'un peu moins avec HTTP/2 et en fait, certains disent que la concaténation doit être un anti-modèle, en vertu de HTTP/2 - si il y a des arguments à l'encontre de faire disparaître complètement trop).
Pour le mettre comme un exemple concret: supposons que vous disposez de l'ordre de 10 éléments à partir d'un magasin pour la livraison à domicile:
HTTP/1.1 avec une connexion signifie que vous devez commander un à la fois et vous ne pouvez pas commander l'élément suivant jusqu'à ce que le dernier arrive. Vous pouvez comprendre il faudrait des semaines pour obtenir par le biais de tout.
HTTP/1.1 avec de multiples connexions signifie que vous pouvez avoir un (limitée) nombre d'indépendants commandes sur la route en même temps.
HTTP/1.1 avec le pipelining signifie que vous pouvez demander toutes les 10 articles les uns après les autres sans attendre, mais ensuite ils arrivent tous dans l'ordre vous l'avez demandé. Et si un article est en rupture de stock alors vous devez attendre pour que, avant que vous obtenez les articles que vous avez commandés après que - même si ceux qui plus tard les articles sont réellement en stock! C'est un peu mieux mais il est encore soumis à des retards, et disons que la plupart des magasins ne prennent pas en charge ce mode de commande de toute façon.
HTTP/2, vous pouvez commander vos articles dans un ordre particulier - sans aucun retard (comme ci-dessus). Le magasin d'expédition pour ce qu'ils sont prêts, ils peuvent arriver dans un ordre différent que vous l'avez demandé, et ils peuvent même diviser les éléments de sorte que certaines parties de l'ordre arrivent en premier (donc mieux que ci-dessus). Finalement, cela devrait signifier que vous 1) obtenir tout plus rapide dans l'ensemble et 2) peuvent commencer à travailler sur chaque article comme il arrive ("oh, c'est pas aussi beau que je le pensais, je vais peut-être vous voulez commander quelque chose d'autre ou à la place").
Bien sûr, vous êtes toujours limité par la taille de votre facteur de van (la bande passante), donc ils pourraient avoir à laisser quelques paquets de retour au bureau de poste jusqu'à la prochaine journée si ils sont plein jour, mais c'est rarement un problème par rapport au retard dans l'envoi de la commande à travers et à l'arrière. La plupart de navigation sur le web implique l'envoi de lettres d'avant en arrière, plutôt que des paquets encombrants.
Espérons que cela aide.
Revanth Kumar
Points
172
Simple Ans (Source) :
Le multiplexage signifie que votre navigateur peut envoyer plusieurs demandes et de recevoir des réponses multiples "livré" en une seule connexion TCP. De sorte que la charge de travail associée à des recherches DNS et des poignées de main est enregistré pour les fichiers provenant du même serveur.
Complexe Détaillé/Réponse:
Regardez la réponse de @BazzaDP.
