Le module HTTP/2 dans NGINX

Cet article de blog est adapté d'une présentation de Valentin V. Bartenev à nginx.conf 2015, qui s'est tenu à San Francisco en septembre.

Table des matières

Il y a quelques jours, nous avons publié le module HTTP/2 de NGINX. Dans cet exposé, je vais vous donner un bref aperçu du nouveau module.

0:20 Présentation du protocole

Tout d’abord, je voudrais démystifier certains mythes autour du nouveau protocole.

Beaucoup de gens considèrent HTTP/2 comme un successeur brillant et supérieur à HTTP/1. Je ne partage pas cet avis, et voici pourquoi. HTTP/2 n’est en fait qu’une autre couche de transport pour HTTP/1, ce qui n’est pas mal car, par conséquent, vous pouvez utiliser HTTP/2 sans avoir à modifier votre application – il fonctionne avec les mêmes en-têtes. Vous pouvez simplement activer HTTP/2 dans NGINX et NGINX gérera en douceur tous les éléments du protocole pour vous.

Mais HTTP/2 n’est pas magique. Cela a ses avantages et ses inconvénients. Il existe des cas d’utilisation où il se comporte bien et également des scénarios où il se comporte mal.

1:40 Principales fonctionnalités de HTTP/2

Vous pouvez considérer HTTP/2 comme une nouvelle version de SPDY car il est basé sur SPDY et est un protocole très similaire. SPDY est un protocole développé par Google il y a quelques années, conçu pour accélérer la diffusion de contenu Web.

NGINX prend en charge SPDY depuis deux ans déjà, 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 améliorée de SPDY 3.1.

Si vous n’êtes pas familier avec SPDY, je vais passer en revue quelques points clés. Et ces points clés sont également vrais pour HTTP/2, car il s’agit fondamentalement du même protocole avec quelques différences dans les détails.

Le premier point clé est que le protocole lui-même est binaire. J’aime les protocoles binaires – ils sont plus faciles à coder et les bons protocoles binaires présentent certains avantages en termes de performances. Cependant, je comprends aussi les inconvénients de cette approche.

3:08 HTTP/2 Inside – Binaire

Voici une requête HTTP/2. Cela a l’air plutôt cool et, comme vous pouvez le voir, c’est très facile à déboguer. Non, je plaisante. C'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… eh bien, parfois, vous devrez peut-être déboguer le binaire manuellement car l’outil peut être cassé, ou l’outil peut ne pas vous montrer tous les détails cachés dans les bits.

Heureusement, la plupart du temps, vous pouvez simplement ajouter HTTP/2 dans NGINX et ne jamais avoir à gérer sa nature binaire. Et heureusement, la plupart des demandes seront traitées par des machines. Les machines sont bien plus douées que les humains pour lire les protocoles binaires.

4:26 HTTP/2 Inside – Multiplexage

Le prochain point clé de HTTP/2 est le multiplexage. Au lieu d'envoyer et de recevoir des réponses et des requêtes sous forme de flux de données distincts sur plusieurs connexions, HTTP/2 les multiplexe sur un flux d'octets ou un flux de données. Il découpe les données pour différentes requêtes et différentes réponses, et chaque tranche possède sa propre identification et son propre champ de taille, qui permettent au point de terminaison de déterminer quelles données appartiennent à quelle requête.

L’inconvénient ici est que, puisque chaque bloc de données possède sa propre identification, ses propres champs, il y a des métadonnées qui sont transférées en plus des données réelles. Donc, il y a des frais généraux. Par conséquent, si vous n’avez qu’un seul flux de données, par exemple si vous regardez un film, HTTP/2 n’est pas un bon protocole car tout ce que vous obtiendrez sera une surcharge supplémentaire.

Quels sont les avantages du multiplexage ? Le principal avantage du multiplexage est qu’en utilisant une seule connexion, vous pouvez économiser tout le temps que vous passeriez avec HTTP/1.x sur l’établissement de liaison lorsque vous devez créer une nouvelle requête.

De tels retards sont particulièrement douloureux lorsque vous utilisez TLS. C'est pourquoi la plupart des clients prennent désormais en charge HTTP/2 uniquement via TLS. Autant que je sache, il n’existe aucun projet visant à prendre en charge HTTP/2 sur TCP simple, car cela n’apporte pas beaucoup d’avantages. En effet, les poignées de main TCP ne sont pas aussi coûteuses que les poignées de main TLS, vous n’économisez donc pas beaucoup ici en évitant les connexions multiples.

7:09 Principales fonctionnalités de HTTP/2 – Compression d'en-tête

Le prochain point clé concernant HTTP/2 est sa compression d’en-tête. Si vous avez des cookies très volumineux, cela peut vous faire économiser des centaines d’octets par requête ou réponse, mais en général, la plupart du temps, vous ne bénéficierez pas beaucoup de la compression d’en-tête. Parce que, même si vous pensez à des requêtes séparées, vous aurez tôt ou tard affaire à une couche de paquets sur le réseau et peu importe que vous envoyiez cent octets ou cent et demi octets, car au final, cela aboutira toujours à un seul paquet.

L’inconvénient de la compression d’en-tête HTTP/2 est qu’elle est avec état [ Éditeur – Pour les tables utilisées pour stocker les informations de compression/décompression]. Par conséquent, pour chaque connexion, les serveurs et les clients doivent conserver une sorte d'état et cela coûte beaucoup plus de mémoire que de conserver l'état pour les connexions HTTP/1. Ainsi, chaque connexion HTTP/2 utilisera beaucoup plus de mémoire.

8h40 Principales fonctionnalités de HTTP/2 – Priorisation

Le dernier point clé concernant HTTP/2 est sa mécanique de priorisation. Cela résout le problème introduit par le multiplexage. Lorsque vous n'avez qu'une seule connexion, vous n'avez qu'un seul tuyau, et vous devez décider soigneusement quelle réponse vous allez placer dans ce tuyau ensuite.

La priorisation est facultative dans HTTP/2, mais sans elle, vous n’obtiendrez pas beaucoup d’avantages en termes de performances. Le module HTTP/2 de NGINX prend entièrement en charge la priorisation, la priorité basée sur les poids et la priorité basée sur les dépendances. D’après ce que nous avons vu jusqu’à présent, nous avons actuellement l’implémentation la plus rapide de HTTP/2. Voici les points clés de HTTP/2.

10:06 Historique de HTTP/2

Voici une diapositive simple qui retrace l’histoire de HTTP/2. Assez simple. Passons maintenant au fonctionnement pratique de HTTP/2.

10:16 Page de test

Afin de comprendre comment HTTP/2 fonctionne dans différentes conditions de réseau, j’ai effectué quelques tests sur une page Web typique. Ceci est juste une page HTTP/2 que j'ai trouvée sur Github. Vous pouvez voir combien de ressources il possède et quelle est la taille de chaque ressource. Je pense que c’est assez représentatif d’un site typique.

10:52 Environnement de test

Voici mon environnement de test, au cas où vous voudriez reproduire le test.

11:02 Chargement 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 X sous forme de temps d’aller-retour (RTT) en millisecondes, puis j’ai mesuré le temps de téléchargement sur l’axe des Y, également en millisecondes. Et ce test mesure le temps de chargement de la page lorsque toutes les ressources de la page sont entièrement chargées.

À partir du graphique, vous pouvez voir une tendance évidente : pour les faibles latences, il n’y a pas de différence significative entre HTTP, HTTPS et HTTP/2. Pour des latences plus élevées, vous pouvez voir que HTTP/1.x simple est le choix le plus rapide. HTTP/2 arrive en deuxième position et HTTPS est le plus lent.

11:48 Première peinture

Et qu'en est-il du temps de la « première peinture » ? Dans de nombreux cas, il s’agit de la mesure la plus significative du point de vue de l’utilisateur, car c’est à ce moment-là qu’il voit réellement quelque chose sur son écran. Dans de nombreux cas, le temps nécessaire au chargement complet de la page n’a pas vraiment d’importance, mais le temps nécessaire à l’utilisateur pour voir quelque chose compte beaucoup.

Ici, nous voyons la même tendance, mais la partie intéressante de notre test est que pour les latences au milieu de la gamme, de 30 ms à 250 ms, HTTP/2 est un peu plus rapide que HTTP simple, bien que la différence soit très faible.

12:45 Configuration

Voilà donc nos repères, parlons maintenant de la façon de configurer HTTP/2 et NGINX.

C'est en fait très simple. Il vous suffit d’ajouter le paramètre http2 à la directive listen . L'étape la plus compliquée ici est probablement d'obtenir la dernière version d'OpenSSL, car HTTP/2 nécessite l'extension ALPN [ Application‑Layer Protocol Negotiation ], et l'extension ALPN n'est prise en charge que par OpenSSL 1.0.2.

Nous avons également implémenté NPN [ Next Protocol Negotiation ] pour HTTP/2, qui fonctionne avec la plupart des clients pour le moment, mais ils vont supprimer la prise en charge de NPN car SPDY sera obsolète début 2016. Cela signifie que vous pouvez utiliser HTTP/2 avec la version OpenSSL qui fait partie de nombreuses distributions Linux pour le moment, mais vous devez garder à l'esprit qu'elle cessera de fonctionner dans un avenir proche.

Voilà donc tout ce qu’il faut savoir sur la configuration de NGINX pour HTTP/2 et cela conclut ma présentation. Merci.

[ Documentation de référence pour le module HTTP/2 ]

Questions et réponses

Q: Allez-vous également prendre en charge HTTP/2 côté amont ou prendre en charge HTTP/2 uniquement côté client ?

UN: Pour le moment, nous ne prenons en charge HTTP/2 que côté client. Vous ne pouvez pas configurer HTTP/2 avec proxy_pass . [ Éditeur – Dans la version originale de ce message, cette phrase a été incorrectement transcrite comme « Vous pouvez configurer HTTP/2 avec proxy_pass . » Nous nous excusons pour toute confusion que cela a pu causer. ]

Mais quel est l’intérêt de HTTP/2 côté backend ? Car comme vous pouvez le constater à partir des tests de performance, HTTP/2 n’apporte pas beaucoup d’avantages aux réseaux à faible latence tels que les connexions en amont.

De plus, dans NGINX, vous disposez du module keepalive et vous pouvez configurer un cache keepalive. Le principal avantage de HTTP/2 en termes de performances est d'éliminer les poignées de main supplémentaires, mais si vous le faites déjà avec un cache keepalive, vous n'avez pas besoin de HTTP/2 côté amont.

Autres ressources HTTP/2

• HTTP/2 pour les développeurs d'applications Web – Livre blanc (PDF) couvrant tout ce que vous devez savoir sur HTTP/2
• Réseau de navigateur haute performance – Édition spéciale du livre électronique d'Ilya Grigorik de Google
• Quoi de neuf dans HTTP/2 ? – Webinaire NGINX décrivant les fonctionnalités clés et donnant des conseils de mise en œuvre
• 7 conseils pour améliorer les performances HTTP/2 – Article de blog
• Liste des navigateurs prenant en charge HTTP/2 – Puis-je l'utiliser ? site Web

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 .