http / 2: protocole réseau qui améliore considérablement la vitesse de chargement de la page Web
Points de base:
Évolution du protocole HTTP:
L'infrastructure d'Internet - ou la couche de réseau physique - est un protocole Internet (dans le cadre de la couche TCP / IP ou de transport). Il s'agit de l'infrastructure de la plupart de nos communications Internet.
ci-dessus, c'est la couche d'application, et diverses applications utilisent différents protocoles pour connecter et transmettre des informations. Par exemple, nous avons SMTP, POP3 et IMAP pour l'envoi et la réception des e-mails;
Le protocole le plus célèbre, qui est également synonyme d'Internet, est HTTP (Hypertext Transfer Protocol). Nous l'utilisons tous les jours pour visiter le site Web. Il a été conçu par Tim Berners Lee au CERN dès 1989. La spécification de la version 1.0 a été publiée en 1996 (RFC 1945) et la version 1.1 a été publiée en 1999.
La spécification HTTP est maintenue par la World Wide Web Alliance et peut être trouvée sur https://www.w3.org/standards/techs/http.
La première génération de protocoles HTTP (versions 1.0 et 1.1) a dominé Internet jusqu'en 2015, après la sortie de HTTP / 2, l'industrie (serveur Web et fournisseurs de navigateurs) a commencé à l'adopter.
Limites de Http / 1.1:
http est un protocole sans état basé sur une structure de réponse à la demande, ce qui signifie que le client fait des demandes au serveur, qui sont atomiques: aucune demande unique n'est consciente de la demande précédente. (C'est pourquoi nous utilisons des cookies - par exemple, afin de connecter plusieurs demandes dans une session utilisateur pour pouvoir fournir une version authentifiée du site Web à l'utilisateur connecté).
Les transfertssont généralement lancés par le client (navigateur de l'utilisateur) et le serveur ne répond généralement qu'à ces demandes.
On peut dire que l'état HTTP actuel est assez "maladroit", ou plutôt de faible niveau, nécessitant beaucoup "d'aide" au navigateur et au serveur pour illustrer comment communiquer efficacement. Il n'est pas facile d'apporter des changements dans ce domaine, car de nombreux sites Web existants reposent sur la compatibilité arrière avec les changements introduits. Toute opération conçue pour améliorer le protocole doit être effectuée de manière transparente sans interrompre Internet.
À bien des égards, ce modèle stricte de demande de demande, atomique, de synchronisation est devenu un goulot d'étranglement, et les progrès ont pris la forme de piratage, généralement dirigé par des leaders de l'industrie tels que Google et Facebook. La situation habituelle (qui est améliorée de diverses manières) est lorsque les visiteurs demandent une page Web, et lorsque leur navigateur le reçoit du serveur, il analyse le HTML et trouve d'autres ressources nécessaires pour rendre la page, comme CSS, les images, et javascript. Lorsqu'il rencontre ces liens de ressource, il cesse de charger tous les autres contenus et demande la ressource spécifiée du serveur. Il ne bougera pas du tout avant qu'il ne soit reçu. Il demande ensuite une autre ressource, etc.
Le nombre de demandes requis pour le chargement des meilleurs sites Web du monde est généralement des centaines.
Cela comprend beaucoup de temps d'attente, ainsi que beaucoup de temps aller-retour, au cours desquels les visiteurs ne peuvent voir que l'écran blanc ou les sites Web semi-rendus. Ce sont toutes quelques secondes de gaspillage. Au cours de ces cycles de demande, une grande quantité de bande passante disponible est tout simplement inactive et inutilisée.
CDN peut atténuer beaucoup de ces problèmes, mais ce ne sont aussi qu'une solution temporaire.
Comme l'a souligné Daniel Stenberg de Mozilla (l'une des personnes impliquées dans la normalisation HTTP / 2), la première version du protocole a du mal à profiter pleinement de la capacité de la couche de transport sous-jacente TCP. Les utilisateurs qui ont travaillé sur l'optimisation des vitesses de chargement du site Web savent que cela nécessite généralement une certaine créativité, pour le mettre euphémistiquement.
Au fil du temps, la vitesse de la bande passante Internet a considérablement augmenté, mais l'infrastructure de l'ère HTTP / 1.1 n'a pas profité de cela. Il a encore du mal à faire face à des problèmes tels que les pipelines HTTP - repousser plus de ressources sur la même connexion TCP - et ainsi de suite. Les clients du navigateur prennent en charge le plus de traînées, Firefox et Chrome le désactivent par défaut, ou il n'est pas du tout pris en charge, comme IE, les versions Firefox 54, etc. Cela signifie que même une petite ressource doit ouvrir une nouvelle connexion TCP, et tous les ballonnements qui suit - TCP Handshake, recherche DNS, retard ... en raison de la tête du blocage de l'équipe, le chargement d'une ressource entraînera le blocage de tout Chargement d'autres ressources.
synchronise la comparaison des connexions sans pipeline aux connexions du pipeline, montrant des économies de temps de charge possibles.
Dans le cadre du modèle HTTP / 1, certaines techniques d'optimisation que les développeurs Web doivent utiliser pour optimiser leurs sites Web incluent les assistants d'image, les connexions CSS et JavaScript, la rupture (distribue les demandes de ressources du visiteur à plusieurs domaines ou sous-domaines).
Une amélioration est nécessaire, elle doit résoudre ces problèmes de manière compatible en arrière et en arrière pour éviter d'interrompre les travaux sur les toiles existantes.
spdy et http / 2:
En 2009, Google a annoncé un projet qui deviendrait un projet de proposition pour le protocole de prochaine génération SPDY (prononcé Speedy ), ajoutant un support pour Chrome et le poussant vers lui dans les prochaines années. services. Par la suite, les fabricants de Twitter et de serveurs tels qu'Apache et Nginx ont également fourni la prise en charge, Node.js, et plus tard Facebook, WordPress.com et la plupart des fournisseurs de CDN.
SPDY introduit le multiplexage - la tendance de plusieurs ressources en parallèle sur une seule connexion TCP. La connexion est chiffrée par défaut et les données sont compressées. Premièrement, les tests préliminaires des 25 premiers sites Web du Livre blanc SPDY ont montré que la vitesse augmentait de plus de 27% à plus de 60%.
Après avoir prouvé son efficacité dans un environnement de production, SPDY version 3 est devenue la base du premier projet HTTP / 2 développé par HTTPBIS, le groupe de travail sur les protocoles de transfert hypertexte en 2015.
http / 2 est conçu pour résoudre le problème de retard qui afflige la première version du protocole par:
Il est également conçu pour résoudre le problème du blocage frontal. Les données qu'elle transmet au format binaire, améliore l'efficacité et nécessite le cryptage par défaut (ou du moins, il s'agit d'une exigence imposée par les navigateurs grand public).
La compression de la tête est effectuée à l'aide de l'algorithme HPACK, qui résout les vulnérabilités dans SPDY et réduit la taille des demandes Web en deux.
Le serveur push est l'une des fonctionnalités conçues pour résoudre le temps d'attente gaspillé, fournissant des ressources au serveur du navigateur avant les demandes du navigateur. Cela réduit le temps aller-retour, qui est un goulot d'étranglement majeur dans l'optimisation du site Web.
En raison de toutes ces améliorations, le décalage horaire de chargement apporté par HTTP / 2 peut être vu sur l'exemple de la page de ImageKit.io.
Plus il y a d'économies en temps de chargement, plus les ressources du site Web sont évidentes.
Comment voir si un site Web fournit des ressources via HTTP / 2:
Dans les navigateurs traditionnels tels que Firefox ou Chrome, nous pouvons consulter la prise en charge du site Web pour le protocole HTTP / 2 dans l'outil d'inspecteur en ouvrant l'onglet "réseau" et en cliquant avec le bouton droit sur la bande au-dessus de la liste des ressources. Ici, nous pouvons activer l'élément "Protocole".
Implémentation côté serveur:
À ce jour, tous les navigateurs grand public prennent en charge HTTP / 2, bien que toutes les demandes HTTP / 2 soient nécessaires, et la spécification HTTP / 2 elle-même ne nécessite pas de cryptage.
Apache 2.4 le prend en charge via son module mod_http2, qui devrait maintenant être prêt pour la production. Apache doit le construire en ajoutant le paramètre --enable-http2 à la commande ./configure. Nous devons également nous assurer qu'au moins la version 1.2.1 de la bibliothèque LibngHTTP2 est installée. Si le système a du mal à le trouver, nous pouvons fournir un chemin vers ./configure en ajoutant - avec - avec-nghttp2 =
L'étape suivante consiste à charger le module en ajoutant la directive à la configuration d'Apache:
<code>LoadModule http2_module modules/mod_http2.so</code>
Ensuite, nous ajoutons des protocoles H2 H2C HTTP / 1.1 à notre bloc d'hôte virtuel et rechargez le serveur. La documentation d'Apache nous met en garde contre les précautions lors de l'activation de HTTP / 2:
L'activation de HTTP / 2 sur votre serveur Apache affectera la consommation de ressources, et si vous avez un site occupé, vous voudrez peut-être considérer attentivement son impact.
Lorsque HTTP / 2 est activé, la première chose à noter est que votre processus de serveur démarrera des threads supplémentaires. La raison en est que HTTP / 2 maintient toutes les demandes qu'il reçoit à son propre fil de travail pour le traitement, collecte les résultats et les diffuse au client.
Vous pouvez en savoir plus sur la configuration Apache ici.
Nginx a pris en charge HTTP / 2 depuis la version 1.9.5, nous pouvons l'activer en ajoutant simplement le paramètre http2 à notre spécification hôte virtuelle:
<code>server {
listen 443 ssl http2 default_server;
ssl_certificate server.crt;
ssl_certificate_key server.key;</code>puis recharger nginx.
Malheureusement, à ce jour, la poussée du serveur n'a pas été officiellement implémentée, mais elle a été ajoutée à la feuille de route de développement et devrait être publiée l'année prochaine. Pour les personnes plus aventureuses, il existe un module Nginx non officiel qui ajoute la prise en charge de la poussée du serveur HTTP / 2.
LiteSpeed et OpenLitespeed se vante également de prendre en charge HTTP / 2.
Une note avant d'activer HTTP / 2 du côté du serveur est de s'assurer que nous avons la prise en charge SSL. Cela signifie que tous les extraits de code hôte virtuel que nous avons mentionnés ci-dessus - pour Apache et Nginx - doivent entrer la version SSL du bloc d'hôte virtuel et écouter le port 443. Une fois que nous avons installé Apache ou Nginx, et nous avons configuré l'hôte virtuel ordinaire, obtenir le certificat SSL LETSECCRYPT et l'installer sur n'importe quelle distribution Linux majeure devrait être une question de quelques lignes de code. CERTBOT est un outil de ligne de commande qui automatise l'intégralité du processus.
Résumé:
Dans cet article, je décris brièvement HTTP / 2, une spécification de protocole Web de deuxième génération émergente.
La liste complète des implémentations de la nouvelle génération de HTTP peut être trouvée ici.
Pour ceux qui ne savent pas grand-chose sur la technologie, le raccourci pour la transition vers ce nouveau protocole peut être simplement implémenter CDN dans la pile Web, car CDN a été l'un des premiers fournisseurs à adopter HTTP / 2.
HTTP / 2 FAQ:
(La partie FAQ est omise ici car elle est fortement dupliquée avec la sortie précédente)
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!
Que faire si une erreur se produit dans le script de la page actuelle
La différence entre l'API de repos et l'API
Quelles sont les plateformes formelles de trading de devises numériques ?
Touches de raccourci de l'écran de verrouillage Windows
Qu'est-ce que le trading de devises numériques
Quelle est la fonction du téléphone portable NFC ?
Comment paginer dans Oracle
méthode de sauvegarde des données MySQL
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
