La différence entre http2.0 et http1.1

Qu'est-ce que HTTP 2.0 ?

HTTP/2 (Hypertext Transfer Protocol version 2, initialement nommé HTTP 2.0), est la deuxième version majeure du protocole HTTP utilisée dans le monde. Large Web. HTTP/2 est la première mise à jour du protocole HTTP depuis la sortie de HTTP 1.1 en 1999. Il est principalement basé sur le protocole SPDY (un protocole de couche application basé sur TCP développé par Google pour minimiser les retards du réseau, augmenter la vitesse du réseau et optimiser expérience du réseau des utilisateurs).

Par rapport à HTTP 1.1, les principales différences incluent :

HTTP/2 utilise le format binaire au lieu du format texte

HTTP/2 est entièrement multiplexé, non ordonné et bloquant - une seule connexion est nécessaire pour le parallélisme

Grâce à la compression d'en-tête, HTTP/2 réduit la surcharge

HTTP/2 permet au serveur de « pousser » activement les réponses vers le cache client

Cours recommandé : Tutoriel PHP.

Pourquoi HTTP/2 est-il binaire ?

Comparés aux protocoles texte comme HTTP/1.x, les protocoles binaires sont plus efficaces à analyser, plus compacts « en ligne » et, plus important encore, comportent moins d'erreurs.

Pourquoi HTTP/2 nécessite-t-il un multiplexage ?

HTTP/1.x a un problème appelé blocage de tête de ligne, cela signifie qu'il est Il est plus efficace pour une connexion de soumettre une seule requête à la fois, et elle deviendra plus lente s'il y a plus de requêtes. HTTP/1.1 a essayé d'utiliser le pipeline pour résoudre ce problème, mais l'effet n'était pas idéal (un volume de données important ou une réponse lente entraverait les requêtes derrière cela. De plus, en raison du support réseau (intermédiaire) et le serveur ne peut pas prendre en charge le). bien le pipeline, ce qui rend le déploiement difficile. Le multiplexage peut très bien résoudre ces problèmes, car il peut gérer plusieurs demandes et réponses de messages en même temps ; il peut même mélanger un message avec un autre pendant le processus de transmission. Le client n’a donc besoin que d’une seule connexion pour charger une page.

Pourquoi les en-têtes de message doivent-ils être compressés ?

Supposons qu'une page ait 80 ressources à charger (ce nombre est assez conservateur pour le Web d'aujourd'hui), et chaque requête a un en-tête de message de 1 400 octets (ce qui n'est pas rare non plus, en raison de l'existence d'éléments tels que des cookies et des références), et il faut au moins 7 à 8 allers-retours « en ligne » pour obtenir ces en-têtes de message. Cela n'inclut pas le temps de réponse - c'est juste le temps qu'il faut pour les récupérer auprès du client. Tout cela est dû au mécanisme de démarrage lent de TCP, qui détermine les paquets à récupérer en fonction du nombre de paquets connus - ce qui limite évidemment le nombre de paquets pouvant être envoyés lors des premiers allers-retours. En revanche, même une légère compression des en-têtes peut permettre à ces requêtes d'être traitées en un seul aller-retour - parfois même en un seul paquet. Cette surcharge peut être évitée, en particulier si l'on considère les applications client mobiles, qui, même dans de bonnes conditions, connaissent généralement des latences aller-retour de plusieurs centaines de millisecondes.

Quels sont les avantages du push serveur ?

Lorsque le navigateur demande une page Web, le serveur renvoie du HTML. Le serveur doit attendre que le navigateur analyse le HTML et envoie tout le contenu en ligne avant de commencer à envoyer du JavaScript. , images et demandes de ressources CSS. Le service push du serveur évite les délais aller-retour en « poussant » le contenu dont il pense que le client aura besoin dans le cache du client.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!