Fermer

juin 8, 2018

Contexte, avantages du rendement et mises en œuvre –8 minutes de lecture



En plus de l'infrastructure d'Internet – ou des couches réseau physiques – se trouve le protocole Internet, dans le cadre de la couche TCP / IP ou transport. C'est le tissu qui sous-tend la totalité ou la plupart de nos communications Internet.

Une couche de protocole de niveau supérieur que nous utilisons par-dessus est la couche d'application . À ce niveau, diverses applications utilisent différents protocoles pour se connecter et transférer des informations. Nous avons SMTP, POP3 et IMAP pour l'envoi et la réception de courriels, IRC et XMPP pour chatter, SSH pour l'accès au serveur distant, etc.

Le protocole le plus connu parmi ceux-ci, qui est devenu synonyme d'utilisation du Internet, est HTTP (protocole de transfert hypertexte). C'est ce que nous utilisons pour accéder aux sites tous les jours. Il a été conçu par Tim Berners-Lee au CERN dès 1989. La spécification pour la version 1.0 a été publiée en 1996 (RFC 1945), et 1.1 en 1999.

La spécification HTTP est maintenue par le World Wide Web Consortium, et peut être trouvé à http://www.w3.org/standards/techs/HTTP.

La première génération de ce protocole – les versions 1 et 1.1 – a dominé le web jusqu'en 2015, lorsque HTTP / 2 a été publié et le

HTTP / 1

HTTP est un protocole sans état basé sur une structure demande-réponse ce qui signifie que le client envoie des requêtes au serveur, et ces requêtes sont atomiques: toute requête unique ne connaît pas les requêtes précédentes. (C'est pourquoi nous utilisons des cookies – pour combler le fossé entre plusieurs demandes dans une session d'utilisateur, par exemple, pour pouvoir servir une version authentifiée du site aux utilisateurs connectés.)

Les transferts sont généralement initiés par le client – ce qui signifie le navigateur de l'utilisateur – et les serveurs répondent généralement à ces demandes.

On pourrait dire que l'état actuel de HTTP est assez "bête", ou mieux, de bas niveau, avec beaucoup d '"aide" qui doit être donné aux navigateurs et aux serveurs sur la façon de communiquer efficacement. Les changements dans ce domaine ne sont pas simples à introduire, avec autant de sites Web existants dont le fonctionnement dépend de la rétrocompatibilité avec les changements introduits. Tout ce qui est fait pour améliorer le protocole doit être fait d'une manière transparente qui ne perturbera pas Internet

De nombreuses façons, le modèle actuel est devenu un goulot d'étranglement avec cette stricte demande-réponse, atomique, modèle synchrone, et les progrès ont surtout pris la forme de hacks, souvent menés par les leaders de l'industrie comme Google, Facebook, etc. Le scénario habituel, qui est amélioré de diverses manières, consiste à demander une page web au visiteur, et lorsque son navigateur le reçoit à partir du serveur, il analyse le code HTML et trouve d'autres ressources nécessaires pour rendre la page, comme CSS, images et JavaScript. Lorsqu'il rencontre ces liens de ressource, il arrête de charger tout le reste et demande des ressources spécifiques au serveur. Il ne bouge pas d'un millimètre jusqu'à ce qu'il reçoive cette ressource. Ensuite, il en demande un autre, et ainsi de suite

 Nombre moyen de requêtes dans les meilleurs sites Web du monde

Le nombre de requêtes nécessaires pour charger les plus grands sites Web est souvent de quelques centaines.

et beaucoup d'allers-retours au cours desquels notre visiteur ne voit qu'un écran blanc ou un site web à moitié rendu. Ce sont des secondes gaspillées. Une grande partie de la bande passante disponible est juste restée inutilisée pendant ces cycles de requêtes

CDNs peuvent atténuer beaucoup de ces problèmes, mais même ils ne sont que des hacks.

Comme Daniel Stenberg (un des les personnes travaillant sur la standardisation HTTP / 2) de Mozilla l'ont souligné la première version du protocole a du mal à tirer pleinement parti de la capacité de la couche de transport sous-jacente, TCP
. travailler sur l'optimisation des vitesses de chargement de sites Web sait que cela nécessite souvent de la créativité.

Au fil du temps, les vitesses de bande passante Internet ont considérablement augmenté, mais l'infrastructure HTTP / 1.1-ère n'a pas pleinement utilisé. Il a encore lutté avec des problèmes comme HTTP pipeline – pousser plus de ressources sur la même connexion TCP. Le support côté client dans les navigateurs a été le plus dur, avec Firefox et Chrome le désactivant par défaut, ou ne le supportant pas du tout, comme IE, Firefox version 54+, etc.
Cela signifie que même les petites ressources nécessitent l'ouverture d'un nouvelle connexion TCP, avec tout ce qui l'accompagne – poignées de main TCP, recherches DNS, latence … Et en raison du blocage de tête de ligne le chargement d'une ressource bloque le chargement de toutes les autres ressources

 HTTP pipeline

Une connexion synchrone, non-pipelinée par rapport à une connexion pipeline, montrant des économies possibles dans le temps de chargement.

Certains des développeurs web d'optimisation de sorcellerie doivent recourir au modèle HTTP / 1 pour optimiser leurs sites Web incluent sprites d'image concaténation CSS et JavaScript, sharding (distribution des demandes de ressources des visiteurs sur plus d'un domaine ou sous-domaine), et ainsi de suite.

L'amélioration était due, et il fallait résoudre ces problèmes de manière transparente, rétrocompatible de manière à ne pas interrompre le fonctionnement du web existant

SPDY

En 2009, Google a annoncé un projet qui deviendrait un projet de proposition d'un protocole de nouvelle génération, SPDY (prononcé speedy ), ajoutant le support à Chrome, et le poussant à tous ses services web dans les années suivantes. Ensuite, Twitter et les fournisseurs de serveurs comme Apache, nginx avec leur soutien, Node.js, et plus tard sont venus Facebook, WordPress.com, et la plupart des fournisseurs de CDN.

SPDY introduit multiplexage – envoi de plusieurs ressources en parallèle , sur une seule connexion TCP. Les connexions sont cryptées par défaut et les données sont compressées. Tout d'abord, des tests préliminaires dans le livre blanc SPDY effectués sur les 25 premiers sites ont montré une amélioration de la vitesse de 27% à plus de 60%.

Après avoir fait ses preuves en production, SPDY pour le premier brouillon de HTTP / 2 réalisé par le groupe de travail Hypertext Transfer Protocol httpbis en 2015.

HTTP / 2 vise à résoudre les problèmes de la première version du protocole – problèmes de latence – par: [19659004] Il vise également à résoudre le blocage de tête de ligne. Les données qu'il transfère sont au format binaire ce qui améliore son efficacité et il nécessite un chiffrement par défaut (ou du moins, c'est une exigence imposée par les principaux navigateurs.)

algorithme, résolution de la vulnérabilité dans SPDY et réduction des tailles de [Web][19459003demandes de moitié

Server push est l'une des fonctionnalités qui vise à résoudre l'attente gaspillée en diffusant des ressources sur le navigateur du visiteur avant que le navigateur ne l'exige. Cela réduit le temps d'aller-retour, qui est un gros goulot d'étranglement dans l'optimisation du site.

En raison de toutes ces améliorations, la différence de temps de chargement que HTTP / 2 apporte à la table peut être vue sur ] par imagekit.io.

Plus le nombre de ressources d'un site Web est important, plus le temps de chargement est important

Comment voir si un site Web traite des ressources via HTTP / 2

, nous pouvons vérifier la prise en charge d'un site Web pour le protocole HTTP / 2 dans l'outil 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'article Protocol

 activer l'inspection du protocole dans l'outil d'inspection du navigateur

Une autre façon consiste à installer un petit outil JavaScript qui nous permet d'inspecter HTTP / 2 support via la ligne de commande (en supposant que Node.js et npm soient installés):

 npm install -g is-HTTP2-cli

Après l'installation, nous devrions pouvoir l'utiliser comme ceci:

 is-HTTP2 www.google.com

✓ HTTP / 2 pris en charge par www.google.com
Protocoles supportés: grpc-exp h2 HTTP / 1.1

Implémentations

Au moment de l'écriture, tous les principaux navigateurs supportent HTTP / 2 bien que toutes les requêtes HTTP / 2 soient cryptées, ce dont la spécification HTTP / 2 elle-même n'a pas besoin.

Serveurs

Apache 2.4 le supporte avec son module mod_HTTP2 qui devrait être prêt pour la production. Apache doit être construit avec lui en ajoutant l'argument - enable-HTTP2 à la commande ./ configure . Nous devons également nous assurer d'avoir au moins la version 1.2.1 de la bibliothèque libngHTTP2 installée. Dans le cas où le système a du mal à le trouver, nous pouvons fournir le chemin vers ./ configure en ajoutant - with-ngHTTP2 = .

L'étape suivante consisterait à charger le module en ajoutant la directive à la configuration d'Apache:

 LoadModule HTTP2_module modules / mod_HTTP2.so

Ensuite, nous ajouterions Protocoles h2 h2c HTTP / 1.1 à notre bloc hôte virtuel et rechargerons le serveur. La documentation d'Apache nous avertit des mises en garde lors de l'activation de HTTP / 2:

L'activation de HTTP / 2 sur votre serveur Apache a un impact sur la consommation de ressources et si vous avez un site occupé, vous devrez en examiner soigneusement les implications. La première chose notable après l'activation de HTTP / 2 est que vos processus serveur démarrent des threads supplémentaires. La raison en est que HTTP / 2 donne toutes les demandes qu'il reçoit à ses propres threads Worker pour traitement, collecte les résultats et les diffuse au client.

Vous pouvez en savoir plus sur Apache configuration ici




Source link