Cet article de blog est adapté d’une présentation de Valentin V. Bartenev lors de nginx.conf 2015, qui s’est tenue à San Francisco en septembre.
Table des matières
Il y a quelques jours, nous avons publié le module HTTP/2 de NGINX. Dans cette présentation, je vais vous donner un bref aperçu de ce nouveau module.
0:20 Présentation du protocole
Tout d’abord, je tiens à déconstruire certains mythes autour du nouveau protocole.
Beaucoup de gens considèrent HTTP/2 comme un successeur flambant neuf et supérieur à HTTP/1. Je ne partage pas cet avis, et voici pourquoi. HTTP/2 n’est en réalité qu’une couche de transport supplémentaire pour HTTP/1, ce qui n’est pas une mauvaise chose puisque vous pouvez ainsi utiliser HTTP/2 sans avoir à modifier votre application : il fonctionne avec les mêmes en-têtes. Il vous suffit d’activer HTTP/2 dans NGINX, qui se chargera en toute transparence de tous les aspects liés au protocole.
Mais HTTP/2 n’a rien de magique. Il présente des avantages et des inconvénients. Dans certains cas d’usage, il se comporte bien, tandis que dans d’autres scénarios, ses performances sont médiocres.
1:40 Fonctionnalités clés de HTTP/2
Vous pouvez considérer HTTP/2 comme une nouvelle version de SPDY, car il repose sur SPDY et constitue un protocole très similaire. SPDY est un protocole développé par Google il y a quelques années afin d’accélérer la diffusion de contenu web.
NGINX prend déjà en charge SPDY depuis deux ans. Vous pouvez donc découvrir les avantages de HTTP/2 en utilisant le module SPDY. Certains diront que HTTP/2 n’est qu’une version peaufinée de SPDY 3.1.
Si vous ne connaissez pas SPDY, je vais en présenter quelques points clés. Ces points clés s’appliquent également à HTTP/2, car il s’agit essentiellement du même protocole, à quelques différences de détail près.
Le premier point essentiel est que le protocole lui-même est binaire. J’aime les protocoles binaires : ils sont plus faciles à programmer et, lorsqu’ils sont bien conçus, ils offrent certains avantages en matière de performances. Cependant, je comprends également les inconvénients de cette approche.
3:08 Au cœur de HTTP/2 – Binaire
Voici une requête HTTP/2. Elle a l’air plutôt sympa et, comme vous pouvez le constater, elle est très facile à déboguer. Non, je plaisante. Elle est difficile à déboguer. Et c’est l’un des inconvénients des protocoles binaires.
Vous devrez peut-être utiliser un outil pour décoder la requête ou… parfois, vous devrez peut-être déboguer manuellement les données binaires, car l’outil peut être défaillant ou ne pas afficher tous les détails cachés dans les bits.
Heureusement, la plupart du temps, il suffit d’activer HTTP/2 dans NGINX sans jamais avoir à se soucier de sa nature binaire. Et heureusement, la plupart des requêtes seront traitées par des machines. Les machines sont bien plus douées que les humains pour lire les protocoles binaires.
4:26 Au cœur de HTTP/2 – Multiplexage
L’autre point clé de HTTP/2 est le multiplexage. Au lieu d’envoyer et de recevoir les requêtes et les réponses sous forme de flux de données distincts sur plusieurs connexions, HTTP/2 les multiplexe en un seul flux d’octets, ou flux de données. Il segmente les données correspondant aux différentes requêtes et réponses, chaque segment possédant son propre identifiant ainsi qu’un champ indiquant sa taille, afin que le point de terminaison puisse déterminer à quelle requête appartiennent les données.
L’inconvénient ici est que, puisque chaque fragment de données possède son propre identifiant et ses propres champs, des métadonnées sont transférées en plus des données proprement dites. Cela entraîne donc une certaine surcharge. Par conséquent, si vous ne disposez que d’un seul flux de données, par exemple lorsque vous regardez un film, HTTP/2 n’est pas un protocole adapté, car il ne fera qu’ajouter une surcharge supplémentaire.
Quels sont les avantages du multiplexage ? Son principal avantage est qu’en utilisant une seule connexion, vous gagnez tout le temps que vous auriez consacré, avec HTTP/1.x, à l’établissement d’une connexion lors de la création d’une nouvelle requête.
De tels délais sont particulièrement pénalisants avec TLS. C’est pourquoi la plupart des clients ne prennent désormais en charge HTTP/2 que sur TLS. À ma connaissance, il n’est pas prévu de prendre en charge HTTP/2 sur une connexion TCP non chiffrée, car cela présente peu d’intérêt. En effet, les négociations TCP sont moins coûteuses que les négociations TLS ; éviter plusieurs connexions ne permet donc pas de gagner beaucoup de temps dans ce cas.
7:09 Fonctionnalités clés de HTTP/2 – Compression des en-têtes
L’autre point essentiel concernant HTTP/2 est la compression des en-têtes. Si vous avez des cookies très volumineux, cela peut vous faire économiser des centaines d’octets par requête ou par réponse, mais, en général, la compression des en-têtes ne vous apportera pas grand-chose la plupart du temps. En effet, même si vous considérez les requêtes séparément, elles seront finalement transmises sous forme de paquets sur le réseau. Que vous envoyiez cent octets ou cent cinquante octets ne change donc pas grand-chose, puisque cela tiendra dans un seul paquet.
L’inconvénient de la compression des en-têtes HTTP/2 est qu’elle conserve un état [Note de l’éditeur – Pour les tables utilisées afin de stocker les informations de compression/décompression]. Par conséquent, pour chaque connexion, les serveurs et les clients doivent conserver une forme d’état, ce qui nécessite beaucoup plus de mémoire que pour les connexions HTTP/1. Ainsi, chaque connexion HTTP/2 consomme beaucoup plus de mémoire.
8:40 Fonctionnalités clés de HTTP/2 – Priorisation
Le dernier point clé concernant HTTP/2 est son mécanisme de priorisation. Celui-ci résout le problème introduit par le multiplexage. Lorsque vous ne disposez que d’une seule connexion, vous n’avez qu’un seul canal et devez choisir avec soin la prochaine réponse à y faire transiter.
La gestion des priorités est facultative dans HTTP/2, mais sans elle, vous ne bénéficierez pas d’un gain de performances significatif. Le module HTTP/2 de NGINX prend entièrement en charge la gestion des priorités, qu’elles soient fondées sur des pondérations ou sur des dépendances. D’après ce que nous avons pu constater jusqu’à présent, nous disposons actuellement de l’implémentation de HTTP/2 la plus rapide. Voilà les points essentiels à retenir concernant HTTP/2.
10:06 Histoire de HTTP/2
Voici une diapositive simple qui retrace l’histoire de HTTP/2. Rien de bien compliqué. Voyons maintenant comment HTTP/2 fonctionne en pratique.
10:16 Page de test
Afin de comprendre le fonctionnement de HTTP/2 dans différentes conditions réseau, j’ai effectué quelques tests de performance sur une page web classique. Il s’agit simplement d’une page HTTP/2 que j’ai trouvée sur Github. Vous pouvez voir le nombre de ressources qu’elle contient ainsi que la taille de chacune d’elles. Je pense qu’elle est assez représentative d’un site classique.
10:52 Environnement de test
Voici mon environnement de test, au cas où vous souhaiteriez reproduire le test.
11:02 Chargement du DOM
Et voici le résultat que j’ai obtenu. Vous pouvez voir que j’ai simulé différentes latences réseau sur l’axe des abscisses, exprimées sous forme de temps aller-retour (RTT) en millisecondes, puis que j’ai mesuré le temps de téléchargement sur l’axe des ordonnées, également en millisecondes. Ce test mesure le temps de chargement de la page jusqu’à ce que toutes ses ressources soient entièrement chargées.
Le graphique fait apparaître une tendance évidente : lorsque la latence est faible, il n’y a pas de différence significative entre HTTP, HTTPS et HTTP/2. En revanche, lorsque la latence est plus élevée, le protocole HTTP/1.x non chiffré est le plus rapide. HTTP/2 arrive en deuxième position, tandis que HTTPS est le plus lent.
11:48 Premier affichage
Qu’en est-il du délai avant le « premier affichage » ? Dans de nombreux cas, il s’agit de la mesure la plus importante du point de vue de l’utilisateur, car c’est à ce moment-là qu’il voit réellement quelque chose apparaître à l’écran. Souvent, le temps nécessaire au chargement complet de la page importe moins que le délai avant que l’utilisateur puisse voir quelque chose.
Nous observons ici la même tendance, mais le point intéressant de notre test est que, pour les latences situées au milieu de la plage, de 30 ms à 250 ms, HTTP/2 est légèrement plus rapide que le HTTP classique, bien que la différence soit très faible.
Configuration à 12 h 45
Voilà pour nos tests de performance. Voyons maintenant comment configurer HTTP/2 et NGINX.
En fait, c’est très simple. Il vous suffit d’ajouter le paramètre http2 à la directive listen. L’étape la plus compliquée consiste probablement à obtenir la dernière version d’OpenSSL, car HTTP/2 nécessite l’extension ALPN [négociation de protocole de couche applicative], qui n’est prise en charge qu’à partir d’OpenSSL 1.0.2.
Nous avons également implémenté NPN [négociation du protocole suivant] pour HTTP/2. Cette technologie fonctionne actuellement avec la plupart des clients, mais ceux-ci vont abandonner sa prise en charge, car SPDY sera rendu obsolète début 2016. Cela signifie que vous pouvez utiliser HTTP/2 avec la version d’OpenSSL actuellement incluse dans de nombreuses distributions Linux, mais gardez à l’esprit que cela cessera de fonctionner dans un avenir proche.
Voilà, c’est tout pour la configuration de NGINX avec HTTP/2, et cela conclut ma présentation. Merci.
[Documentation de référence du module HTTP/2]
Questions-réponses
Q : Prendrez-vous également en charge HTTP/2 côté serveur en amont, ou uniquement côté client ?
R : Pour le moment, nous ne prenons en charge HTTP/2 que côté client. Vous ne pouvez pas configurer HTTP/2 avec proxy_pass. [Note de la rédaction – Dans la version originale de cet article, cette phrase avait été retranscrite à tort comme suit : « Vous pouvez configurer HTTP/2 avec proxy_pass ». Nous vous prions de nous excuser pour toute confusion que cela a pu entraîner.]
Mais quel est l’intérêt de HTTP/2 côté backend ? Comme vous pouvez le constater dans les tests de performance, HTTP/2 n’apporte pas grand-chose sur les réseaux à faible latence, comme les connexions aux serveurs en amont.
De plus, dans NGINX, vous disposez du module « keepalive » et pouvez configurer un cache de connexions persistantes. Le principal avantage de HTTP/2 en matière de performances est d’éviter les négociations de connexion supplémentaires. Toutefois, si vous le faites déjà à l’aide d’un cache de connexions persistantes, vous n’avez pas besoin de HTTP/2 côté serveur en amont.
Ressources supplémentaires sur HTTP/2
- HTTP/2 pour les développeurs d’applications web – Livre blanc (PDF) présentant tout ce que vous devez savoir sur HTTP/2
- Réseaux de navigateurs haute performance – Édition spéciale de l’ebook d’Ilya Grigorik de Google
- Quoi de neuf dans HTTP/2 ? – Webinaire NGINX présentant les principales fonctionnalités et fournissant des conseils de mise en œuvre
- 7 conseils pour améliorer les performances de HTTP/2 – Article de blog
- Liste des navigateurs prenant en charge HTTP/2 – site web Can I Use?
Prêt à essayer HTTP/2 avec NGINX Plus dans votre environnement ? Commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation.
À propos de l’auteur
Articles de blog associés
Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.
Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.