Performances et efficacité : travailler avec HTTP/3

HTTP/3 est à l'horizon, suivant de près HTTP/2, qui est sans doute encore très jeune lui-même. Étant donné qu'il a fallu 16 ans pour passer de HTTP/1.1 à HTTP/2, est-ce que quelqu'un devrait vraiment se préoccuper de HTTP/3 ?

La réponse courte : Oui, c'est important, et vous devriez être au courant. C'est comme la façon dont HTTP/2 a apporté des modifications importantes à partir de HTTP/1.1 en passant de l'ASCII au binaire. HTTP/3 apporte à nouveau des modifications importantes, cette fois en basculant le transport sous-jacent de TCP vers UDP.

Bien que HTTP/3 soit encore au stade de la conception, la spécification officielle étant un brouillon, il est déjà en cours de déploiement et il y a de fortes chances que vous en trouviez une version en cours d'exécution sur votre réseau aujourd'hui.

Mais il y a quelques nouveaux dilemmes posés par le fonctionnement de HTTP/3. Aussi, quel est l'avantage? Et que doivent savoir les ingénieurs réseau, les administrateurs système et les développeurs ?

Le principal problème : performances et efficacité

Les développeurs de sites et d'applications construisent généralement avec l'intention que leurs créations soient réellement utilisées. Parfois, la base d'audience est limitée, mais souvent l'idée est simplement d'obtenir autant d'utilisateurs que possible. Naturellement, plus un site Web devient populaire, plus il peut générer de revenus.

Un retard de 100 millisecondes dans le temps de chargement du site Web peut nuire aux taux de conversion de 7 %.

Rapport sur les performances de la vente au détail en ligne d'Akamai : les millisecondes sont essentielles (2017)

En d'autres termes, un site de commerce électronique avec des ventes de 40 000 dollars par jour perdrait un million de dollars par an en raison d'un tel retard.

Ce n'est également un secret pour personne que la performance d'un site est absolument essentielle pour qu'un site devienne plus populaire. La recherche sur les achats en ligne continue de trouver des liens entre des taux de rebond accrus et des temps de chargement plus longs, et entre la fidélité des acheteurs et les performances du site Web pendant l'expérience d'achat.

La recherche a également révélé que :

• 47% des consommateurs s'attendent à ce qu'une page Web se charge en 2 secondes ou moins.
• 40% des personnes abandonnent un site web qui met plus de 3 secondes à se charger.

Et c'était l'état de la patience des acheteurs en ligne il y a plus d'une décennie . Les performances sont donc essentielles, et HTTP/2 et HTTP/3 signifient tous deux de meilleures performances de site Web.

HTTP/2 ? …Qu'est-ce que c'est?

Une bonne compréhension du protocole HTTP/2 est essentielle pour comprendre HTTP/3. Tout d'abord, pourquoi y avait-il besoin de HTTP/2 ?

HTTP/2 a commencé comme un projet Google appelé SPDY, résultat d'une étude qui a révélé que le plus gros problème de performances sur le Web était la latence . L'auteur a conclu que "plus de bande passante n'a pas (beaucoup) d'importance":

Si nous faisons une analogie entre la plomberie et Internet, nous pouvons considérer que la bande passante d'Internet est comme le diamètre de la conduite d'eau. Un tuyau plus gros transporte un plus grand volume d'eau et vous pouvez donc fournir plus d'eau entre deux points.

En même temps, quelle que soit la taille de votre tuyau, si le tuyau est vide et que vous voulez acheminer de l'eau d'un point à l'autre, il faut du temps pour que l'eau circule dans le tuyau. Dans le jargon Internet, le temps nécessaire à l'eau pour se déplacer d'un bout à l'autre du tuyau et vice-versa s'appelle le temps d'aller-retour , ou RTT .

Mike Belshe

Dans l'étude, la réduction du temps de chargement des pages était l'objectif. Il a montré que l'augmentation de la bande passante aide initialement, car passer de 1 Mbps à 2 Mbps réduit de moitié le temps de chargement de la page. Cependant, les prestations plafonnent très rapidement.

En revanche, la diminution de la latence présente un avantage constant et permet d'obtenir les meilleurs résultats.

HTTP HOL : le problème de blocage en tête de ligne

La principale cause de latence au sein du protocole HTTP/1 est le problème de blocage en tête de ligne. Les pages Web nécessitent (presque toujours) plusieurs ressources : CSS, JavaScript, polices, images, AJAX/XMR, etc. Cela signifie que le navigateur Web doit effectuer plusieurs requêtes au serveur. Cependant, toutes les ressources ne sont pas nécessaires pour que la page devienne utile.

Avec HTTP/1.0, il était nécessaire que le navigateur termine complètement une requête, y compris la réception complète de la réponse, avant de lancer la requête suivante. Tout devait être fait dans l'ordre. Chaque demande bloquerait la ligne de demandes, d'où le nom.

Pour tenter de compenser le problème de blocage HOL, les navigateurs Web établissent plusieurs connexions simultanées à un seul serveur. Mais ils ont dû limiter arbitrairement ce comportement : les serveurs, les postes de travail et les réseaux peuvent être surchargés avec trop de connexions.

HTTP/1.1 a introduit plusieurs améliorations pour aider à résoudre le problème. Le principal est le pipelining , permettant aux navigateurs Web de lancer de nouvelles requêtes sans avoir à attendre que les requêtes précédentes se terminent. Cela a considérablement amélioré les temps de chargement dans les environnements à faible latence.

Mais il faut toujours que toutes les réponses arrivent séquentiellement dans l'ordre où elles ont été faites, de sorte que le chef de file est toujours bloqué. Étonnamment, de nombreux serveurs ne profitent toujours pas de cette fonctionnalité.

Fait intéressant, HTTP/1.1 a également introduit keep-alive , qui permettait aux navigateurs d'éviter la surcharge liée à la création d'une nouvelle connexion TCP pour chaque requête HTTP. Il s'agissait d'une première tentative pour résoudre un problème de performances dérivé de TCP. Il était si inefficace que la plupart des experts en performances le déconseillent en fait car il ralentit le serveur avec trop de connexions inactives. Nous examinerons de plus près TCP ci-dessous, ainsi que la façon dont ce problème a été résolu par HTTP/2.

Solution de blocage HTTP HOL de HTTP/2

HTTP/2 a introduit le multiplexage requête-réponse sur une seule connexion. Non seulement un navigateur peut lancer une nouvelle requête à tout moment, mais les réponses peuvent être reçues dans n'importe quel ordre — le blocage est complètement éliminé au niveau de l'application.

En conséquence directe, cela signifie que les serveurs Web HTTP/2-savvy peuvent maximiser l'efficacité - nous y reviendrons plus tard.

Bien que le multiplexage requête-réponse soit la principale fonctionnalité de HTTP/2, il inclut plusieurs autres fonctionnalités importantes. Les lecteurs peuvent noter qu'ils sont tous quelque peu liés.

Tramage binaire HTTP/2

HTTP/2 fait passer la norme de protocole HTTP d'un modèle de requête-réponse ASCII inefficace et lisible par l'homme à un cadrage binaire efficace. Ce n'est plus seulement une demande et une réponse :

Avec HTTP/2, les navigateurs communiquent avec les serveurs via des flux bidirectionnels avec plusieurs messages, chacun composé de plusieurs trames.

HTTP/2 HPACK (compression d'en-tête)

La nouvelle compression d'en-tête de HTTP/2, utilisant le format HPACK, permet d'économiser une tonne de bande passante pour la plupart des sites. En effet, la majorité des en-têtes sont les mêmes pour les requêtes envoyées au sein d'une connexion.

Cloudflare fait état d'importantes économies de bande passante grâce à HPACK uniquement :

• 76 % de compression pour les en-têtes d'entrée
• Réduction de 53 % du trafic entrant total
• 69 % de compression pour les en-têtes de sortie
• Réduction de 1,4 % à 15 % du trafic de sortie total

Bien sûr, utiliser moins de bande passante signifie généralement un site Web plus rapide.

Hiérarchisation des flux HTTP/2 et push du serveur

C'est là que le multiplexage de HTTP/2 permet vraiment au serveur de maximiser son efficacité. Le multiplexage permet de servir des ressources plus rapides (par exemple, JavaScript mis en cache en mémoire) avant les plus lentes (par exemple, grandes images, JSON généré par la base de données, etc.). Mais cela permet également une amélioration supplémentaire des performances via la hiérarchisation des flux de HTTP/2.

La hiérarchisation des flux permet de garantir que les aspects presque prêts d'une page sont entièrement terminés sans avoir à attendre que d'autres demandes gourmandes en ressources se terminent. Ceci est accompli grâce à un arbre de dépendance pondéré. Cette arborescence est utilisée pour informer le serveur des réponses auxquelles il doit allouer le plus de ressources système.

Ceci est particulièrement important pour les applications Web progressives (PWA). Par exemple, supposons qu'une page comporte quatre fichiers JavaScript. Deux sont pour la fonctionnalité de la page et deux pour les publicités. Le pire scénario consiste à charger la moitié du JS fonctionnel et la moitié du JS publicitaire, puis de charger de grandes images, avant de charger l'un des JS restants. Dans ce cas, rien sur la page ne fonctionne initialement, car tout doit attendre la ressource la plus lente.

Avec la hiérarchisation des flux, les navigateurs Web peuvent demander au serveur d'envoyer les deux fichiers JS de fonctionnalité de page avant d'envoyer l'un des fichiers JavaScript publicitaires. De cette façon, les utilisateurs n'ont pas à attendre que les publicités se chargent complètement avant d'utiliser les fonctionnalités de la page. Bien que le temps de chargement global ne se soit pas amélioré, les performances perçues ont été considérablement augmentées. Malheureusement, ce comportement dans le navigateur Web est encore principalement une question d'algorithmes, plutôt que d'être quelque chose de spécifié par les développeurs Web.

Dans le même ordre d'idées, la fonctionnalité push du serveur de HTTP/2 permet au serveur d'envoyer des réponses au navigateur pour les requêtes qu'il n'a pas encore faites ! Le serveur peut tirer parti des lacunes de transmission, en utilisant efficacement la bande passante en préchargeant dans le navigateur les ressources que le serveur sait qu'il demandera bientôt. Une partie de l'espoir ici est d'éliminer la pratique de l'intégration des ressources, qui ne fait que gonfler les ressources et les rend plus longues à charger.

Malheureusement, ces deux fonctionnalités nécessitent une configuration minutieuse de la part des développeurs Web pour vraiment réussir. Il ne suffit pas de les activer.

HTTP/2 apporte clairement de nombreux avantages potentiels, dont certains sont moins chers à exploiter que d'autres. Comment s'en sortent-ils dans le monde réel ?

Adoption de HTTP contre HTTP/2

SPDY a été créé en 2009. HTTP/2 a été standardisé en 2015. SPDY est devenu le nom d'une branche de développement instable du code, HTTP/2 devenant la version finale. Le résultat est que SPDY est devenu obsolète et HTTP/2 est généralement la norme que tout le monde suit.

Après la standardisation, l'adoption de HTTP/2 (ou "h2") a augmenté rapidement pour atteindre environ 40 % des 1 000 sites Web les plus importants. Cela était principalement dû au fait que de grands fournisseurs d'hébergement et de cloud déployaient une assistance pour le compte de leurs clients. Malheureusement, plusieurs années plus tard, l'adoption de HTTP/2 a ralenti et la majorité d'Internet est toujours sur HTTP/1.

Absence de prise en charge du navigateur pour le mode HTTP/2 Clear Text

Il y a eu de nombreux appels pour que HTTP/2 fasse du chiffrement une partie obligatoire de la norme. Au lieu de cela, la norme définissait à la fois les modes cryptés (h2) et texte clair (h2c). En tant que tel, HTTP/2 pourrait remplacer entièrement HTTP/1.

Malgré la norme, tous les navigateurs Web actuels ne prennent en charge HTTP/2 que sur des connexions cryptées et n'implémentent intentionnellement pas le mode texte clair. Au lieu de cela, les navigateurs s'appuient sur le mode de rétrocompatibilité HTTP/1 pour accéder à des serveurs non sécurisés. Ceci est le résultat direct d'une poussée idéologique visant à sécuriser le Web par défaut.

Pourquoi HTTP/3 ? Et en quoi est-ce différent ?

Le problème de blocage de tête de ligne HTTP étant désormais résolu par HTTP/2, les développeurs de protocoles ont tourné leur attention vers le prochain facteur de latence le plus important : le problème de blocage de tête de ligne TCP .

Protocole de contrôle de transmission (TCP)

Les réseaux IP (protocole Internet) sont basés sur l'idée que des ordinateurs s'envoient des paquets. Un paquet n'est que des données avec des informations d'adressage attachées au sommet.

Mais les applications doivent généralement gérer des flux de données. Pour réaliser cette illusion, le protocole de contrôle de transmission (TCP) présente aux applications un canal à travers lequel un flux de données peut circuler. Comme avec la plupart des canaux, il existe une garantie que les données sortiront du canal dans le même ordre qu'elles y entreront, également connu sous le nom de "premier entré, premier sorti" (FIFO). Ces caractéristiques ont rendu TCP très utile et très largement adopté.

Dans le cadre des garanties de livraison de données fournies par TCP, il doit être capable de gérer une grande variété de situations. L'un des problèmes les plus complexes est de savoir comment fournir toutes les données lorsqu'un réseau est surchargé, sans aggraver la situation pour tout le monde. L'algorithme pour cela s'appelle le contrôle de la congestion et fait partie des spécifications Internet en constante évolution. Sans un contrôle suffisant de la congestion, Internet s'arrête.

En octobre 1986, Internet a connu le premier de ce qui est devenu une série d'« effondrements de congestion ». Au cours de cette période, le débit de données de LBL à UC Berkeley (sites séparés par 400 mètres et trois sauts IMP) est passé de 32 Kbps à 40 bps.

V. Jacobson (1988)

C'est là qu'intervient le problème de blocage de tête de ligne TCP.

Problème de blocage TCP HOL

Le contrôle de la congestion TCP fonctionne en implémentant des mécanismes d' interruption et de retransmission des paquets, utilisés chaque fois qu'une perte de paquets est détectée. Backoff est destiné à aider à calmer le réseau. La retransmission garantit que les données sont finalement livrées.

Cela signifie que les données TCP peuvent arriver à destination dans le désordre et qu'il est de la responsabilité de la partie réceptrice de réorganiser les paquets avant de les réassembler dans le flux. Malheureusement, cela signifie qu'un seul paquet perdu peut entraîner la mise en pause de tout le flux TCP pendant que le serveur attend sa retransmission. Par conséquent, la tête de file est bloquée.

Un autre projet de Google visait à résoudre ce problème en introduisant un protocole appelé QUIC.

Le protocole QUIC est construit sur UDP au lieu de TCP, et QUIC constitue la base de HTTP/3.

Qu'est-ce qu'UDP ?

Le protocole de datagramme utilisateur (UDP) est une alternative à TCP. Il ne donne pas l'illusion d'un flux ou les mêmes garanties qu'offre TCP. Au lieu de cela, il fournit simplement un moyen simple de placer des données dans un paquet, de l'adresser à un autre ordinateur et de l'envoyer. Il n'est pas fiable , non ordonné et ne s'accompagne d'aucune forme de contrôle de la congestion.

Son but est d'être léger et de fournir les fonctionnalités minimales nécessaires pour permettre la communication. De cette façon, l'application peut mettre en œuvre ses propres garanties. Ceci est souvent très utile dans les applications en temps réel. Par exemple, lors d'appels téléphoniques, les utilisateurs préfèrent généralement recevoir 90 % des données immédiatement, plutôt que 100 % des données à terme.

La solution TCP HOL de HTTP/3

La résolution du problème de blocage TCP HOL a nécessité plus que le simple passage à UDP, car il est toujours nécessaire de garantir la livraison de toutes les données et d'éviter les effondrements de congestion du réseau. Le protocole QUIC est conçu pour faire tout cela en fournissant une expérience optimisée de type HTTP sur UDP.

Comme QUIC prend le contrôle de la gestion des flux, du cadrage binaire, etc., il ne reste plus grand-chose à faire pour HTTP/2 lorsqu'il s'exécute au-dessus de QUIC. Cela fait partie du facteur déterminant pour que cette nouvelle combinaison de QUIC + HTTP soit normalisée en HTTP/3.

Remarque : Il existe de nombreuses versions de QUIC, car le protocole est en cours de développement et déployé dans des environnements de production depuis des années. Il existe même une version spécifique à Google appelée GQUIC. En tant que tel, il est important de faire la distinction entre les anciens protocoles QUIC et la nouvelle norme HTTP/3.

Toujours crypté

HTTP/3 inclut un chiffrement qui emprunte beaucoup à TLS mais ne l'utilise pas directement. L'un des principaux défis de mise en œuvre pour HTTP/3 est que les bibliothèques TLS/SSL doivent être modifiées pour ajouter la nouvelle fonctionnalité requise.

Ce changement est dû au fait que HTTP/3 diffère de HTTPS en termes de chiffrement. Avec l'ancien protocole HTTPS, seules les données elles-mêmes sont protégées par TLS, laissant une grande partie des métadonnées de transport visibles. Dans HTTP/3, les données et le protocole de transport sont protégés. Cela peut ressembler à une fonctionnalité de sécurité, et c'est le cas. Mais c'est fait de cette façon pour éviter une grande partie de la surcharge présente dans HTTP/2. Par conséquent, chiffrer le protocole de transport ainsi que les données rend le protocole plus performant.

Impact de HTTP/3 sur l'infrastructure réseau

HTTP/3 n'est pas sans controverse. Les principales préoccupations concernent l'infrastructure réseau.

HTTP/3 côté client

Côté client, il est assez courant que le trafic UDP soit fortement limité et/ou bloqué. L'application de ces restrictions à HTTP/3 va à l'encontre de l'intérêt du protocole.

Deuxièmement, il est assez courant que HTTP soit surveillé et/ou intercepté. Même avec le trafic HTTPS, les réseaux surveillent régulièrement les éléments de transport en texte clair du protocole pour déterminer s'ils doivent interrompre la connexion afin d'empêcher l'accès à certains sites Web à partir de réseaux spécifiques ou dans des régions spécifiques. Dans certains pays, cela est même imposé par la loi pour certains fournisseurs de services. Le cryptage obligatoire dans HTTP/3 rend cela impossible.

Il ne s'agit pas seulement d'un filtrage au niveau gouvernemental. De nombreuses universités, bibliothèques publiques, écoles et foyers dont les parents sont inquiets choisissent activement soit de bloquer l'accès à certains sites Web, soit au moins de conserver un journal des sites visités. Le cryptage obligatoire dans HTTP/3 rend cela impossible.

Il convient de noter qu'un filtrage limité est actuellement possible. En effet, le champ d'indication du nom du serveur (SNI) - qui contient le nom d'hôte du site Web mais pas le chemin, les paramètres de requête, etc. - n'est toujours pas chiffré. Mais cela devrait changer dans un avenir proche avec l'introduction de l'ESNI (SNI crypté), qui a récemment été ajouté à la norme TLS.

HTTP/3 côté serveur

Côté serveur, il est recommandé de bloquer tous les ports et protocoles qui n'attendent pas de trafic, ce qui signifie que les administrateurs de serveur doivent désormais ouvrir UDP 443 pour HTTP/3, plutôt que de s'appuyer sur leurs règles TCP 443 existantes.

Deuxièmement, l'infrastructure réseau peut rendre les sessions TCP persistantes , ce qui signifie qu'elles seront toujours routées vers le même serveur même si les priorités de routage changent. Comme HTTP/3 s'exécute sur UDP, qui est sans session, l'infrastructure réseau doit être mise à jour pour suivre les ID de connexion spécifiques à HTTP/3, qui ont été laissés non chiffrés spécifiquement pour faciliter le routage permanent.

Troisièmement, il est assez courant que HTTP soit inspecté pour détecter les abus, surveiller les problèmes de sécurité courants, détecter et empêcher la propagation de logiciels malveillants et de virus, etc. Cela n'est pas possible avec HTTP/3 en raison de son cryptage. Néanmoins, les options où le périphérique d'interception possède une copie des clés de sécurité sont toujours possibles, en supposant que les périphériques implémentent le support HTTP/3.

Enfin, de nombreux administrateurs s'opposent à devoir gérer encore plus de certificats SSL, bien que ce soit moins un problème maintenant avec des services tels que Let's Encrypt étant disponibles.

Jusqu'à ce qu'il existe des solutions largement acceptées et bien connues pour résoudre ces problèmes, je pense qu'il est probable que de nombreux grands réseaux bloqueront simplement HTTP/3.

Impact de HTTP/3 sur le développement Web

Il n'y a pas grand chose à craindre sur ce front. Les fonctionnalités de hiérarchisation des flux et de push de serveur de HTTP/2 sont toujours présentes dans HTTP/3. Cela vaut la peine pour les développeurs Web de se familiariser avec ces fonctionnalités s'ils veulent vraiment optimiser les performances de leur site.

Utiliser HTTP/3 dès maintenant

Les utilisateurs de Google Chrome ou du navigateur open source Chromium sont déjà configurés pour utiliser HTTP/3. Les versions de qualité de production des serveurs HTTP / 3 sont encore un peu loin - la spécification n'est pas tout à fait finalisée au moment d'écrire ces lignes. Mais en attendant, il existe de nombreux outils avec lesquels jouer, et Google et Cloudflare ont déjà poussé la prise en charge de leurs environnements de production.

La façon la plus simple de l'essayer est d'utiliser Caddy dans Docker. Un certificat SSL est nécessaire pour cela, donc une adresse IP accessible au public facilite les choses. Les étapes sont :

1. Configuration DNS. Obtenez un nom d'hôte fonctionnel qui est en direct sur Internet, par exemple yourhostname.example.com IN A 192.0.2.1 .
2. Création de Caddyfile. Il doit contenir ces lignes :

 yourhostname.example.com log stdout errors stdout ext .html .htm .md .txt browse gzip tls [email protected]

1. Exécution de Caddy : docker run -v Caddyfile:/etc/Caddyfile -p 80:80 -p 443:443 abiosoft/caddy --quic —ou en dehors de Docker, caddy --quic .
2. Exécution de chrome avec QUIC activé : chromium --enable-quic
3. (Facultatif) Installation d'une extension d'indicateur de protocole.
4. Naviguer vers le serveur compatible QUIC , où un navigateur de fichiers doit être visible.

Les développeurs peuvent également tester leurs serveurs avec les outils utiles suivants :

• Test HTTP/2 de Keycdn
• HTTP3Check de LiteSpeed
• Test du serveur SSL de Qualys

Merci d'avoir lu!