7 conseils pour améliorer les performances de HTTP/2

Valentin Bartenev

Pour en savoir plus sur HTTP/2, regardez l’enregistrement de notre webinaire à succès, « Quoi de neuf dans HTTP/2 ? »

Le vénérable protocole de transfert hypertexte, ou « HTTP », vient d’être mis à jour. La norme HTTP/2 a été approuvée en mai 2015 et est désormais mise en œuvre dans les navigateurs et les serveurs web (notamment NGINX Plus et NGINX Open Source). HTTP/2 est actuellement pris en charge par près des deux tiers des navigateurs web utilisés, et cette proportion augmente de plusieurs points de pourcentage chaque mois.

HTTP/2 repose sur le protocole SPDY de Google, qui reste utilisable jusqu’à la fin de sa prise en charge par le navigateur Chrome de Google, début 2016. NGINX a été l’un des premiers à prendre en charge SPDY et joue désormais le même rôle avec HTTP/2. Notre livre blanc complet, « HTTP/2 pour les développeurs d’applications Web » (PDF), présente HTTP/2, explique comment il s’appuie sur SPDY et comment le mettre en œuvre.

Les principales fonctionnalités de HTTP/2 sont les mêmes que celles de SPDY :

• HTTP/2 est un protocole binaire, plutôt que textuel, ce qui le rend plus compact et plus efficace
• Il utilise une seule connexion multiplexée par domaine, plutôt que plusieurs connexions transportant chacune un fichier.
• Les en-têtes sont compressés à l’aide du protocole HPACK spécialement conçu à cet effet (plutôt qu’avec gzip, comme dans SPDY)
• HTTP/2 dispose d’un mécanisme complexe de gestion des priorités qui permet aux navigateurs de demander en premier les fichiers dont ils ont le plus besoin. Ce mécanisme est entièrement pris en charge par NGINX (celui de SPDY était plus simple).

Vous devez maintenant décider si vous souhaitez passer à HTTP/2, ce qui implique notamment de savoir comment en tirer le meilleur parti. Cet article de blog vous guidera à travers les aspects liés aux performances du processus de décision et de mise en œuvre. Découvrez ces 7 conseils pour optimiser les performances de HTTP/2 :

1. Déterminez si vous avez besoin de HTTP/2 dès aujourd’hui
2. Terminer HTTP/2 et TLS
3. Envisagez de commencer par SPDY
4. Identifiez les optimisations HTTP/1.x dans votre code
5. Implémentez HTTP/2 ou SPDY
6. Revoir les optimisations HTTP/1.x
7. Mettre en œuvre le partitionnement intelligent

Remarque: à proprement parler, ni SPDY ni HTTP/2 ne nécessitent TLS, mais tous deux sont principalement avantageux lorsqu’ils sont utilisés avec SSL/TLS, et les navigateurs ne prennent en charge SPDY ou HTTP/2 que lorsque SSL/TLS est utilisé.

Conseil n° 1 – Déterminez si vous avez besoin de HTTP/2 dès aujourd’hui

La mise en œuvre de HTTP/2 est simple, comme nous l’expliquons dans notre livre blanc, « HTTP/2 pour les développeurs d’applications web » (PDF). Cependant, HTTP/2 n’est pas une solution miracle : il est utile pour certaines applications web, mais moins pour d’autres.

L’utilisation de HTTP/2 est susceptible d’améliorer les performances de votre site web si vous utilisez SSL/TLS (désigné ci-après par TLS). Dans le cas contraire, vous devrez ajouter la prise en charge de TLS avant de pouvoir utiliser HTTP/2. La baisse de performances liée à l’utilisation de TLS devrait alors être globalement compensée par le gain de performances apporté par HTTP/2. Vérifiez toutefois que c’est bien le cas pour votre site avant de décider de le mettre en œuvre.

Voici cinq avantages potentiels majeurs de HTTP/2 :

1. Utilise une seule connexion par serveur – HTTP/2 utilise une seule connexion par serveur, au lieu d’une connexion par requête de fichier. Cela réduit considérablement le recours à l’établissement de connexions, une opération chronophage, ce qui est particulièrement avantageux avec TLS, car les connexions TLS sont particulièrement longues à établir.
2. Offre de meilleures performances TLS – HTTP/2 ne nécessite qu’une seule négociation TLS coûteuse, et le multiplexage permet d’exploiter au mieux cette connexion unique. HTTP/2 compresse également les données d’en-tête, tandis que l’abandon des optimisations de performances propres à HTTP/1.x, telles que la concaténation de fichiers, permet une mise en cache plus efficace.
3. Simplifie vos applications web – Avec HTTP/2, vous pouvez vous passer des « optimisations » de HTTP/1.x qui vous compliquent la tâche, en tant que développeur d’applications, et sollicitent davantage l’appareil client.
4. Idéal pour les pages Web à contenu mixte – HTTP/2 excelle avec les pages Web traditionnelles qui combinent du HTML, du CSS, du code JavaScript, des images et quelques contenus multimédias. Les navigateurs peuvent hiérarchiser les requêtes de fichiers afin que les éléments clés de la page s’affichent rapidement et en premier.
5. Renforce la sécurité – En réduisant l’impact de TLS sur les performances, HTTP/2 permet à davantage d’applications web de l’utiliser, offrant ainsi une sécurité accrue aux utilisateurs.

Et voici les cinq inconvénients correspondants auxquels vous serez confronté :

1. Surcharge plus importante pour la connexion unique – L’algorithme de compression de données HPACK met à jour une table de correspondance aux deux extrémités. La connexion conserve ainsi un état et nécessite davantage de mémoire.
2. Vous n’avez peut-être pas besoin de chiffrement – Si vos données n’ont pas besoin d’être protégées, ou si elles le sont déjà par un système de DRM ou un autre type d’encodage, la sécurité TLS ne vous sera probablement pas très utile.
3. Les optimisations HTTP/1.x sont contre-productives – Les optimisations HTTP/1.x dégradent en réalité les performances dans les navigateurs prenant en charge HTTP/2, et les supprimer vous demande du travail supplémentaire.
4. Les téléchargements volumineux n’en bénéficient pas – Si votre application web sert principalement à fournir des fichiers volumineux à télécharger ou des flux multimédias, vous n’avez probablement pas besoin de TLS, et le multiplexage n’apporte aucun avantage lorsqu’un seul flux est utilisé.
5. Vos clients ne s’en soucient peut-être pas – Vous pensez peut-être que vos clients ne se soucient pas de savoir si les vidéos de chats qu’ils partagent sur votre site sont protégées par TLS et HTTP/2 – et vous avez peut-être raison.

Tout se résume aux performances – et sur ce point, nous avons une bonne et une mauvaise nouvelle.

La bonne nouvelle, c’est qu’un premier test interne réalisé chez NGINX confirme les prévisions théoriques : pour les pages web à contenu mixte demandées via des connexions présentant des latences Internet habituelles, HTTP/2 offre de meilleures performances que HTTP/1.x et HTTPS. Les résultats se répartissent en trois groupes selon le temps aller-retour (RTT) habituel de la connexion :

• RTT très faibles (0 à 20 ms) – Il n’y a pratiquement aucune différence entre HTTP/1.x, HTTP/2 et HTTPS.
• RTT Internet typiques (30 à 250 ms) – HTTP/2 est plus rapide que HTTP/1.x, et tous deux sont plus rapides que HTTPS. Entre deux villes américaines proches l’une de l’autre, le RTT est d’environ 30 ms, contre environ 70 ms d’une côte à l’autre (environ 4 800 km). Sur l’itinéraire le plus court entre Tokyo et Londres, le RTT est d’environ 240 ms.
• RTT élevés (300 ms et plus) – HTTP/1.x est plus rapide que HTTP/2, qui est lui-même plus rapide que HTTPS.

La figure indique le délai avant le premier affichage, c’est-à-dire le temps nécessaire pour que l’utilisateur voie apparaître pour la première fois le contenu de la page Web à l’écran. Cette mesure est souvent considérée comme déterminante dans la perception qu’ont les utilisateurs de la réactivité d’un site Web.

Pour en savoir plus sur nos tests, regardez ma présentation donnée lors de nginx.conf 2015, « Le module HTTP/2 dans NGINX ».

Cependant, chaque page web est différente, tout comme chaque session utilisateur. Si vous proposez des contenus multimédias en streaming ou des fichiers volumineux à télécharger, ou si vous avez optimisé scientifiquement vos optimisations HTTP/1.x jusqu’à en extraire, euh, toute la substantifique moelle (avec toutes nos excuses à « Seul sur Mars »), vos résultats peuvent être différents, voire opposés.

En définitive, il se peut que le rapport coûts-avantages ne vous paraisse pas évident. Dans ce cas, renseignez-vous autant que possible, effectuez des tests de performance sur votre propre contenu, puis prenez une décision. (Pour vous guider, regardez notre webinaire, « Quoi de neuf dans HTTP/2 ? ».)

Conseil n° 2 – Terminer HTTP/2 et TLS

La terminaison d’un protocole signifie que les clients se connectent à un serveur proxy à l’aide du protocole souhaité, tel que TLS ou HTTP/2. Le serveur proxy se connecte ensuite aux serveurs d’applications, aux serveurs de bases de données, etc., sans nécessairement utiliser le même protocole, comme illustré dans la figure.

L’utilisation d’un serveur distinct pour la terminaison implique de passer à une architecture multiserveur. Il peut s’agir de serveurs physiques distincts, de serveurs virtuels ou d’instances de serveurs virtuels dans un environnement cloud tel que AWS. Cette architecture est plus complexe qu’un serveur unique, voire qu’une combinaison serveur d’applications/serveur de base de données. Mais elle offre de nombreux avantages et constitue pratiquement — sans mauvais jeu de mots — une nécessité pour les sites à fort trafic.

Une fois qu’un serveur physique ou virtuel est placé en amont d’une infrastructure existante, de nombreuses possibilités s’offrent à vous. Le nouveau serveur décharge les autres serveurs de la gestion des communications avec les clients et peut être utilisé pour l’équilibrage de charge, la mise en cache des fichiers statiques et à d’autres fins. Il devient alors facile d’ajouter et de remplacer des serveurs d’applications et d’autres serveurs selon les besoins.

NGINX et NGINX Plus sont souvent utilisés à toutes ces fins : terminaison TLS et HTTP/2, équilibrage de charge, etc. Il n’est pas nécessaire de modifier l’environnement existant, si ce n’est pour placer le serveur NGINX en frontal.

Conseil n° 3 – Envisagez de commencer par SPDY

Note de l’éditeur – Depuis la publication de cet article de blog, les principaux navigateurs ont cessé de prendre en charge SPDY. Commencer par SPDY n’est donc plus une option pour un déploiement à grande échelle.

SPDY est le protocole qui a précédé HTTP/2, et ses performances globales sont à peu près équivalentes. Comme il existe depuis plusieurs années, davantage de navigateurs web prennent en charge SPDY que HTTP/2. Toutefois, à l’heure où nous écrivons ces lignes, l’écart se réduit : environ deux tiers des navigateurs web prennent en charge HTTP/2, contre quatre sur cinq pour SPDY.

Si vous êtes pressé de mettre en œuvre ce nouveau type de protocole de transport Web et souhaitez dès aujourd’hui prendre en charge le plus grand nombre possible d’utilisateurs, vous pouvez commencer par proposer SPDY. Puis, début 2016, lorsque la prise en charge de SPDY commencera à être supprimée, vous pourrez passer à HTTP/2 — une modification rapide, du moins avec NGINX. À ce moment-là, davantage d’utilisateurs disposeront de navigateurs prenant en charge HTTP/2 ; vous aurez ainsi choisi la meilleure solution pour le plus grand nombre d’entre eux pendant cette transition.

Conseil n° 4 – Identifiez les optimisations HTTP/1.x que vous utilisez

Avant de décider de mettre en œuvre HTTP/2, vous devez déterminer dans quelle mesure votre base de code est optimisée pour HTTP/1.x. Il existe quatre types d’optimisations à prendre en compte :

1. Partitionnement de domaine – Vous avez peut-être déjà placé des fichiers sur différents domaines afin d’accroître le parallélisme lors de leur transfert vers le navigateur web ; les réseaux de diffusion de contenu (CDN) le font automatiquement. Mais cela n’améliore pas les performances sous HTTP/2 et peut même les dégrader. Vous pouvez utiliser un partitionnement de domaine adapté à HTTP/2 (voir Conseil 7) afin de ne partitionner que pour les utilisateurs de HTTP/1.x.
2. Sprites d’images – Les sprites d’images regroupent plusieurs images téléchargées dans un seul fichier ; un code distinct récupère ensuite les images au fur et à mesure des besoins. Les sprites d’images présentent moins d’avantages avec HTTP/2, mais ils peuvent néanmoins rester utiles.
3. Concaténation des fichiers de code – À l’instar des sprites d’images, les blocs de code qui seraient normalement conservés et transférés dans des fichiers distincts sont regroupés en un seul fichier. Le navigateur y recherche ensuite le code nécessaire et l’exécute selon les besoins.
4. Intégration des fichiers – Le code CSS, le code JavaScript et même les images sont directement intégrés au fichier HTML. Cela réduit le nombre de transferts de fichiers, au prix d’un fichier HTML plus volumineux lors du téléchargement initial.

Les trois derniers types d’optimisation consistent tous à regrouper de petits fichiers en fichiers plus volumineux afin de réduire le nombre de nouvelles connexions et de négociations d’initialisation, particulièrement coûteuses avec TLS.

La première optimisation, le partitionnement de domaine, fait l’inverse : elle impose l’ouverture de davantage de connexions en faisant intervenir des domaines supplémentaires. Ensemble, ces techniques apparemment contradictoires peuvent améliorer assez efficacement les performances des sites HTTP/1.x. Cependant, leur conception, leur mise en œuvre, leur gestion et leur exploitation nécessitent toutes du temps, des efforts et des ressources.

Avant de mettre en œuvre HTTP/2, déterminez où ces optimisations sont utilisées et comment elles influent actuellement sur la conception des applications et les processus de travail au sein de votre organisation, afin de pouvoir ensuite les modifier ou les supprimer après la migration vers HTTP/2.

Conseil n° 5 – Déployez HTTP/2 ou SPDY

En réalité, déployer HTTP/2 ou SPDY n’est pas si difficile. Si vous utilisez NGINX, il vous suffit d’« activer » le protocole dans votre configuration NGINX, comme nous l’expliquons pour HTTP/2 dans notre livre blanc, HTTP/2 pour les développeurs d’applications Web (PDF). Le navigateur et le serveur négocient ensuite le choix du protocole et optent pour HTTP/2 si le navigateur le prend également en charge (et si TLS est utilisé).

Une fois HTTP/2 mis en œuvre au niveau du serveur, les sessions des utilisateurs disposant d’une version de navigateur compatible avec HTTP/2 s’exécuteront sur ce protocole dans votre application web. Celles des utilisateurs disposant d’une version plus ancienne s’exécuteront sur HTTP/1.x, comme illustré dans la figure. Si vous mettez en œuvre HTTP/2 ou SPDY pour un site à fort trafic, veillez à mettre en place des processus permettant de mesurer les performances avant et après le changement, et de revenir en arrière si celui-ci a des effets négatifs importants.

Remarque : Avec HTTP/2 et son utilisation d’une connexion unique, certains détails de votre configuration NGINX prennent davantage d’importance. Examinez votre configuration NGINX en accordant une attention particulière au réglage et au test des paramètres de directives telles que output_buffers, proxy_buffers et ssl_buffer_size. Pour obtenir des instructions générales sur la configuration, consultez Terminaison SSL/TLS avec NGINX dans le Guide d’administration de NGINX Plus. Vous trouverez des conseils plus précis dans nos articles de blog Déchargement SSL, chiffrement et certificats avec NGINX et Comment améliorer le référencement avec HTTPS et NGINX. Notre livre blanc, Performances SSL de NGINX, examine l’incidence du choix de la taille de la clé du serveur, de l’algorithme d’échange de clés et du chiffrement par blocs sur les performances.

Remarque : l’utilisation de certains chiffrements avec HTTP/2 peut nécessiter une attention particulière. La RFC relative à HTTP/2 contient une longue liste de suites de chiffrement à éviter. Vous pouvez donc préférer configurer vous-même la liste des chiffrements. Dans NGINX et NGINX Plus, envisagez d’ajuster la directive ssl_ciphers et d’activer ssl_prefer_server_ciphers, puis de tester la configuration avec les versions courantes des navigateurs. Le test de serveur SSL de Qualys analyse la configuration des serveurs Web SSL, mais (en novembre 2015) il n’est pas fiable pour les négociations de connexion HTTP/2.

Conseil n° 6 – Revoyez les optimisations HTTP/1.x

Étonnamment, l’annulation ou la révision de vos optimisations HTTP/1.x constitue en réalité la partie la plus créative d’une implémentation HTTP/2. Plusieurs aspects doivent être pris en compte, et vous disposez d’une grande latitude quant à la marche à suivre.

Avant de commencer à apporter des modifications, demandez-vous si elles risquent de pénaliser les utilisateurs de navigateurs plus anciens. Dans cette optique, il existe trois grandes stratégies pour annuler ou revoir les optimisations HTTP/1.x :

• Rien à signaler – Si vous n’avez pas optimisé vos applications pour HTTP/1.x, ou si vous avez apporté des modifications modérées que vous souhaitez conserver, vous n’avez rien à faire pour prendre en charge HTTP/2 dans votre application.
• Approche mixte – Vous pouvez décider de réduire la concaténation des fichiers et des données, sans pour autant la supprimer complètement. Par exemple, vous pouvez conserver certains sprites regroupant de petites images cohérentes, tout en renonçant à alourdir le fichier HTML initial avec des données intégrées.
• Abandon complet des optimisations HTTP/1.x (mais consultez la remarque sur le partitionnement de domaine dans le Conseil 7) – Vous pouvez envisager de supprimer complètement ces optimisations.

La mise en cache est quelque peu imprévisible. En théorie, elle fonctionne de manière optimale lorsqu’il existe une multitude de petits fichiers. Toutefois, cela implique de nombreuses opérations d’entrée/sortie sur les fichiers. Il peut être judicieux de regrouper certains fichiers étroitement liés, tant pour le flux de travail que pour les performances de l’application. Tenez soigneusement compte de votre propre expérience et des retours d’autres développeurs lors de leur mise en œuvre de HTTP/2.

Conseil n° 7 – Mettez en œuvre un partitionnement intelligent

Le partitionnement de domaine est peut-être la stratégie d’optimisation HTTP/1.x la plus radicale, mais aussi potentiellement la plus efficace. Vous pouvez utiliser une variante du partitionnement de domaine qui améliore toujours les performances avec HTTP/1.x, mais qui est pour l’essentiel ignorée par HTTP/2, ce qui est avantageux. (En règle générale, HTTP/2 ne tire aucun bénéfice du partitionnement de domaine, car il utilise une connexion unique.)

Pour un partitionnement de domaine compatible avec HTTP/2, veillez à respecter ces deux conditions :

• Faites en sorte que les noms de domaine des ressources réparties sur plusieurs domaines soient résolus vers la même adresse IP.
• Assurez-vous que votre certificat comporte un caractère générique qui le rend valide pour tous les noms de domaine utilisés pour le partitionnement, ou que vous disposez d’un certificat multidomaine approprié.

Pour plus de détails, consultez la RFC 7540, « Protocole de transfert hypertexte version 2 (HTTP/2) ».

Si ces conditions sont réunies, le partitionnement aura lieu avec HTTP/1.x — les domaines sont suffisamment différents pour que les navigateurs créent des ensembles de connexions supplémentaires — mais pas avec HTTP/2 ; les domaines distincts sont traités comme un seul domaine, et une connexion unique permet d’accéder à chacun d’eux.

Conclusion

HTTP/2 et TLS devraient améliorer les performances de votre site et indiquer aux utilisateurs que leurs interactions avec celui-ci sont sécurisées. Que vous soyez le premier de votre secteur à mettre en œuvre HTTP/2 ou que vous rattrapiez vos concurrents, vous pouvez ajouter rapidement et efficacement la prise en charge de HTTP/2.

Suivez ces conseils pour optimiser les performances de HTTP/2 tout en réduisant au minimum les efforts de maintenance, afin de vous concentrer sur la création d’applications rapides, efficaces, sécurisées, faciles à maintenir et à exploiter.

Ressources

• Pour tout savoir sur HTTP/2, consultez le livre blanc de NGINX (PDF).
• Le site « Can I use » indique la compatibilité des navigateurs avec un large éventail de technologies web front-end, notamment SPDY et HTTP/2.
• En janvier 2016, plus de 6 % des sites web utilisaient HTTP/2.

• Pour en savoir plus sur nos tests, consultez la présentation sur HTTP/2 de la conférence nginx.conf 2015.
• NGINX propose un webinaire intitulé « Quoi de neuf dans HTTP/2 ? », qui présente les principales fonctionnalités et fournit des conseils de mise en œuvre.
• Pour un aperçu des conseils d’optimisation des performances de NGINX, consultez notre article de blog, « 10 conseils pour multiplier par 10 les performances des applications ».

À propos de l’auteur

Valentin Bartenev

Autres articles de Valentin Bartenev