7 conseils pour des performances HTTP/2 plus rapides

Pour en savoir plus sur HTTP/2, visionnez l'enregistrement de notre webinaire populaire, Quoi de neuf dans HTTP/2 ?

La vénérable norme HyperText Transfer Protocol, ou HTTP , a désormais été mise à jour. La norme HTTP/2 a été approuvée en mai 2015 et est désormais implémentée dans les navigateurs et les serveurs Web (y compris NGINX Plus et NGINX Open Source ). HTTP/2 est actuellement pris en charge par près des deux tiers de tous les navigateurs Web utilisés, et cette proportion augmente de plusieurs points de pourcentage par mois.

HTTP/2 est basé sur le protocole SPDY de Google, et SPDY reste une option jusqu'à ce que sa prise en charge dans le navigateur Chrome de Google prenne fin début 2016 . NGINX a été un pionnier dans la défense de 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), décrit HTTP/2, montre comment il s'appuie sur SPDY et explique comment l'implémenter.

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 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 avec le protocole HPACK spécialement conçu (plutôt que gzip, comme dans SPDY)
• HTTP/2 dispose d'un système de priorisation complexe pour aider les navigateurs à demander les fichiers les plus nécessaires en premier, qui est entièrement pris en charge dans NGINX (SPDY avait un système plus simple)

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

1. Décidez si vous avez besoin de HTTP/2 aujourd'hui
2. Mettre fin à HTTP/2 et TLS
3. Envisagez de commencer avec SPDY
4. Identifiez les optimisations HTTP/1.x dans votre code
5. Implémenter HTTP/2 ou SPDY
6. Réviser les optimisations HTTP/1.x
7. Mettre en œuvre le sharding intelligent

Note : Ni SPDY ni HTTP/2 ne nécessitent TLS, à proprement parler, mais tous deux sont principalement bénéfiques 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é.

Astuce 1 – Décidez si vous avez besoin de HTTP/2 dès aujourd’hui

La mise en œuvre de HTTP/2 est facile, comme nous le discutons 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, moins pour d’autres.

L’utilisation de HTTP/2 est susceptible d’améliorer les performances du site Web si vous utilisez SSL/TLS (appelé TLS à partir de maintenant). Mais si ce n’est pas le cas, vous devrez ajouter la prise en charge TLS avant de pouvoir utiliser HTTP/2. Dans ce cas, attendez-vous à ce que la pénalité de performance due à l'utilisation de TLS soit à peu près compensée par l'avantage de performance lié à l'utilisation de HTTP/2, mais testez si cela est vraiment vrai pour votre site avant de prendre une décision de mise en œuvre.

Voici cinq avantages potentiels clés de HTTP/2 :

1. Utilise une seule connexion par serveur – HTTP/2 utilise une connexion par serveur, au lieu d’une connexion par demande de fichier. Cela signifie qu'il est beaucoup moins nécessaire de configurer une connexion qui prend du temps, ce qui est particulièrement avantageux avec TLS, car les connexions TLS sont particulièrement longues à créer.
2. Offre des performances TLS plus rapides : HTTP/2 n'a besoin que d'une seule négociation TLS coûteuse et le multiplexage permet de tirer le meilleur parti de la connexion unique. HTTP/2 compresse également les données d'en-tête et évite les optimisations de performances HTTP/1.x telles que la concaténation de fichiers, ce qui permet à la mise en cache de fonctionner plus efficacement.
3. Simplifie vos applications Web – Avec HTTP/2, vous pouvez vous éloigner des « optimisations » HTTP/1.x qui vous obligent, en tant que développeur d'applications, ainsi que l'appareil client à travailler plus dur.
4. Idéal pour les pages Web mixtes – HTTP/2 excelle avec les pages Web traditionnelles qui mélangent HTML, CSS, code JavaScript, images et multimédia limité. Les navigateurs peuvent hiérarchiser les demandes de fichiers pour que les parties clés de la page apparaissent en premier et rapidement.
5. Prend en charge une sécurité renforcée – En réduisant l’impact sur les performances de TLS, HTTP/2 permet à davantage d’applications Web de l’utiliser, offrant ainsi une plus grande sécurité aux utilisateurs.

Et voici cinq inconvénients correspondants que vous rencontrerez :

1. Surcharge plus importante pour la connexion unique – L’algorithme de compression de données HPACK met à jour une table de recherche aux deux extrémités. Cela rend la connexion avec état et la connexion unique nécessite de la mémoire supplémentaire.
2. Vous n'avez peut-être pas besoin de cryptage – Si vos données n'ont pas besoin de protection, ou si elles sont déjà protégées par DRM ou un autre codage, la sécurité TLS ne vous aidera probablement pas beaucoup.
3. Les optimisations HTTP/1.x nuisent aux performances des navigateurs qui prennent en charge HTTP/2. Leur annulation représente donc un travail supplémentaire pour vous.
4. Les téléchargements volumineux ne présentent aucun avantage – Si votre application Web diffuse principalement des fichiers volumineux téléchargeables ou des flux multimédias, vous ne souhaitez probablement pas utiliser TLS, et le multiplexage n'offre 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 est une question de performance – et à ce sujet, nous avons de bonnes et de mauvaises nouvelles.

La bonne nouvelle est qu’un premier test interne que nous avons effectué ici chez NGINX montre le résultat que la théorie prédirait : pour les pages Web à contenu mixte demandées via des connexions avec des latences Internet typiques, HTTP/2 fonctionne mieux que HTTP/1.x et HTTPS. Les résultats se répartissent en trois groupes en fonction du temps de trajet aller-retour (RTT) typique 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 les deux sont plus rapides que HTTPS. Pour les villes américaines proches les unes des autres, le RTT est d'environ 30 ms, et il est d'environ 70 ms d'un océan à l'autre (environ 3 000 miles). Sur le trajet 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 plus rapide que HTTPS.

L'image montre le temps écoulé jusqu'à la première visualisation, c'est-à-dire le temps écoulé jusqu'à ce que l'utilisateur voie pour la première fois le contenu de la page Web apparaître à l'écran. Cette mesure est souvent considérée comme essentielle à la perception des utilisateurs de la réactivité d’un site Web.

Pour plus de détails sur nos tests, regardez ma présentation de nginx.conf 2015, Le module HTTP/2 dans NGINX .

Cependant, chaque page Web est différente, et chaque session utilisateur est différente. Si vous avez des médias en streaming ou des fichiers téléchargeables volumineux, ou si vous avez éliminé le sucre de vos optimisations HTTP/1.x (avec toutes nos excuses à The Martian ), vos résultats peuvent être différents, voire opposés.

En fin de compte, vous pourriez trouver que le rapport coût-bénéfice n’est pas clair. Si tel est le cas, apprenez autant que vous le pouvez, effectuez des tests de performance sur votre propre contenu, puis passez une décision. (Pour obtenir des conseils, regardez notre webinaire, Quoi de neuf dans HTTP/2 ? ).

Astuce 2 – Terminez HTTP/2 et TLS

La fin d'un protocole signifie que les clients se connectent à un serveur proxy en utilisant un 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 le montre la figure.

L’utilisation d’un serveur distinct pour la terminaison implique de passer à une architecture multiserveur. Les serveurs peuvent être des serveurs physiques distincts, des serveurs virtuels ou des instances de serveur virtuel dans un environnement cloud tel qu'AWS . Il s’agit d’une augmentation de la complexité par rapport à un serveur unique, ou même à une combinaison serveur d’applications/serveur de base de données. Mais cela offre de nombreux avantages et constitue pratiquement – sans jeu de mots – une nécessité pour les sites très fréquentés.

Une fois qu'un serveur ou un serveur virtuel est placé devant une configuration existante, de nombreuses choses sont possibles. Le nouveau serveur décharge la tâche des communications client des autres serveurs et peut être utilisé pour l'équilibrage de charge, la mise en cache de fichiers statiques et à d'autres fins. Il devient 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 de TLS et HTTP/2, équilibrage de charge, etc. L’environnement existant n’a pas besoin d’être modifié du tout, sauf pour le « connecter » au serveur NGINX.

Astuce 3 – Envisagez de commencer avec SPDY

Éditeur – Depuis la publication de cet article de blog, SPDY a atteint la fin du support des principaux navigateurs. Commencer avec SPDY n’est plus une option pour un déploiement à grande échelle.

SPDY est le protocole prédécesseur de HTTP/2, et ses performances globales sont à peu près les mêmes. Parce qu'il existe depuis plusieurs années, plus de navigateurs Web prennent en charge SPDY que HTTP/2 . Cependant, au moment où nous écrivons ces lignes, l’écart se réduit : environ deux tiers des navigateurs Web prennent en charge HTTP/2, tandis qu’environ quatre sur cinq prennent en charge SPDY.

Si vous êtes pressé d’implémenter le nouveau style de protocole de transport Web et que vous souhaitez prendre en charge le plus grand nombre possible d’utilisateurs dès aujourd’hui, vous pouvez commencer par proposer SPDY. Ensuite, début 2016, lorsque la prise en charge de SPDY commencera à être supprimée, vous pourrez passer à HTTP/2 – un changement rapide, du moins avec NGINX. À ce stade, davantage d'utilisateurs utiliseront des navigateurs prenant en charge HTTP/2, vous aurez donc fait ce qu'il y a de mieux pour le plus grand nombre de vos utilisateurs pendant cette transition.

Astuce 4 – Identifiez votre utilisation des optimisations HTTP/1.x

Avant de décider d’implémenter HTTP/2, vous devez identifier la partie de votre base de code optimisée pour HTTP/1.x. Il existe quatre types d’optimisations à surveiller :

1. Partage de domaine – Vous avez peut-être déjà placé des fichiers dans différents domaines pour augmenter le parallélisme dans le transfert de fichiers vers le navigateur Web ; les réseaux de domaine de contenu (CDN) le font automatiquement. Mais cela n’aide pas – et peut nuire – aux performances sous HTTP/2. Vous pouvez utiliser le partitionnement de domaine compatible HTTP/2 (voir Astuce 7 ) pour partitionner uniquement pour les utilisateurs HTTP/1.x.
2. Sprites d'image – Les sprites d'image sont des agglomérations d'images qui sont téléchargées dans un seul fichier ; un code séparé récupère ensuite les images au fur et à mesure des besoins. Les avantages des sprites d'images sont moindres sous HTTP/2, même si vous pouvez toujours les trouver utiles.
3. Concaténation de fichiers de code – Similaires aux sprites d’image, les morceaux de code qui seraient normalement conservés et transférés sous forme de fichiers séparés sont combinés en un seul. Le navigateur recherche et exécute ensuite le code nécessaire dans le fichier concaténé selon les besoins.
4. Fichiers en ligne – le code CSS, le code JavaScript et même les images sont insérés directement dans le fichier HTML. Cela signifie moins de transferts de fichiers, au détriment d'un fichier HTML volumineux pour le téléchargement initial.

Les trois derniers types d'optimisations combinent tous de petits fichiers en fichiers plus grands pour réduire les nouvelles connexions et les échanges d'initialisation, ce qui est particulièrement coûteux pour TLS.

La première optimisation, le partitionnement de domaine, fait le contraire : elle force l’ouverture de davantage de connexions en impliquant des domaines supplémentaires dans l’image. Ensemble, ces techniques apparemment contradictoires peuvent être assez efficaces pour augmenter les performances des sites HTTP/1.x. Cependant, leur conception, leur mise en œuvre, leur gestion et leur exécution nécessitent tous du temps, des efforts et des ressources.

Avant d’implémenter HTTP/2, identifiez où ces optimisations existent et comment elles affectent actuellement la conception des applications et le flux de travail dans votre organisation, afin de pouvoir ensuite les modifier ou les annuler après le passage à HTTP/2.

Astuce 5 – Déployez HTTP/2 ou SPDY

En fait, déployer HTTP/2 ou SPDY n’est pas si difficile. Si vous êtes un utilisateur NGINX, il vous suffit d'« activer » le protocole dans votre configuration NGINX, comme nous le détaillons pour HTTP/2 dans notre livre blanc, HTTP/2 pour les développeurs d'applications Web (PDF). Le navigateur et le serveur négocieront ensuite pour choisir un protocole, en optant pour HTTP/2 si le navigateur le prend également en charge (et si TLS est utilisé).

Une fois que vous avez implémenté HTTP/2 au niveau du serveur, les utilisateurs des versions de navigateur qui prennent en charge HTTP/2 verront leurs sessions avec votre application Web exécutées sur HTTP/2. Les utilisateurs de versions de navigateur plus anciennes verront leurs sessions exécutées sur HTTP/1.x, comme indiqué dans la figure. Si vous implémentez HTTP/2 ou SPDY pour un site très fréquenté, vous devrez mettre en place des processus pour mesurer les performances avant et après, et annuler le changement s'il a des impacts négatifs importants.

Note : Avec HTTP/2 et son utilisation d'une connexion unique, certains détails de votre configuration NGINX deviennent plus importants. Vérifiez 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 de configuration générales, consultez Terminaison SSL/TLS NGINX dans le Guide d'administration NGINX Plus. Vous pouvez obtenir des conseils plus spécifiques dans nos blogs 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 NGINX , explore comment le choix de la taille de la clé du serveur, de l'accord du serveur et du chiffrement en masse affecte les performances.

Note : L'utilisation des chiffrements que vous utilisez avec HTTP/2 peut nécessiter une attention particulière. La RFC pour HTTP/2 contient une longue liste de suites de chiffrement à éviter , et vous préférerez peut-être configurer vous-même la liste de chiffrement. Dans NGINX et NGINX Plus, pensez à régler la directive ssl_ciphers et à activer ssl_prefer_server_ciphers , puis à tester la configuration avec les versions de navigateur courantes. Le test Qualys SSL Server analyse la configuration des serveurs Web SSL, mais (en novembre 2015) il n'est pas fiable pour les négociations HTTP/2 .

Astuce 6 – Révisez les optimisations HTTP/1.x

Étonnamment, annuler ou réviser vos optimisations HTTP/1.x est en fait la partie la plus créative d’une implémentation HTTP/2. Il y a plusieurs questions à prendre en compte et de nombreux degrés de liberté quant à ce qu'il faut faire.

Avant de commencer à apporter des modifications, demandez-vous si les utilisateurs d’anciens navigateurs en souffriront. Dans cet esprit, il existe trois grandes stratégies pour annuler ou réviser les optimisations HTTP/1.x :

• Rien à voir ici, les amis – Si vous n'avez pas optimisé votre/vos application(s) pour HTTP/1.x, ou si vous avez apporté des modifications modérées que vous acceptez de conserver, alors 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, mais pas de les éliminer complètement. Par exemple, certains spritings d'images pour des groupes cohérents de petites images pourraient être conservés, tandis que le renforcement du fichier HTML initial avec des données intégrées pourrait disparaître.
• Inversion complète des optimisations HTTP/1.x (mais voir la note sur le partitionnement de domaine dans l’Astuce 7 ) – Vous souhaiterez peut-être vous débarrasser complètement de ces optimisations.

La mise en cache est un peu un joker. Théoriquement, la mise en cache fonctionne de manière optimale lorsqu'il existe une pléthore de petits fichiers. Cependant, cela représente beaucoup d’E/S de fichiers. Une certaine concaténation de fichiers étroitement liés peut être judicieuse, à la fois pour le flux de travail et pour les performances de l'application. Réfléchissez attentivement à votre propre expérience et à ce que partagent les autres développeurs lorsqu’ils implémentent HTTP/2.

Astuce 7 – Mettre en œuvre le sharding intelligent

Le partitionnement de domaine est peut-être la stratégie d’optimisation HTTP/1.x la plus extrême, et probablement aussi la plus réussie. Vous pouvez utiliser une version du partitionnement de domaine qui améliore toujours les performances pour HTTP/1.x mais qui est fondamentalement ignorée, et de manière bénéfique, pour HTTP/2. (Qui ne bénéficie généralement pas du partitionnement de domaine, en raison de l’utilisation d’une seule connexion.)

Pour un partitionnement compatible HTTP/2, effectuez ces deux opérations :

• Faites en sorte que les noms de domaine des ressources fragmentées soient résolus vers la même adresse IP.
• Assurez-vous que votre certificat dispose d'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, voir RFC 7540 , Hypertext Transfer Protocol Version 2 (HTTP/2) .

Si ces conditions sont réunies, le partitionnement se produira pour HTTP/1.x – les domaines sont suffisamment différents pour inciter les navigateurs à créer des ensembles de connexions supplémentaires – et non pour HTTP/2 ; les domaines distincts sont traités comme un seul domaine et une seule connexion peut accéder à tous.

Conclusion

HTTP/2 et TLS sont susceptibles d'améliorer les performances de votre site et de permettre aux utilisateurs de savoir que leur interaction avec votre site est sécurisée. Que vous soyez le premier de votre groupe à implémenter HTTP/2 ou que vous cherchiez à rattraper vos concurrents, vous pouvez ajouter la prise en charge HTTP/2 rapidement et efficacement.

Utilisez ces conseils pour vous aider à obtenir les meilleures performances HTTP/2 avec le moins d'effort continu, afin que vous puissiez vous concentrer sur la création d'applications rapides, efficaces et sécurisées, faciles à entretenir et à exécuter.

Ressources

• Pour en savoir plus sur HTTP/2, consultez le livre blanc de NGINX ( PDF ).
• Le site Web Puis-je utiliser montre la prise en charge du navigateur pour une large gamme de technologies Web frontales, notamment SPDY et HTTP/2 .
• En janvier 2016, plus de 6 % des sites Web utilisaient HTTP/2.

 

• Pour plus de détails sur nos tests, voir la présentation HTTP/2 de nginx.conf 2015.
• NGINX propose un webinaire, Quoi de neuf dans HTTP/2 ? , qui décrit les fonctionnalités clés et donne des conseils de mise en œuvre.
• Pour un aperçu des conseils de performances NGINX, consultez notre article de blog, 10 conseils pour des performances d'application 10x supérieures .