Quels sont les avantages de HTTP/3, et comment ce protocole fonctionne-t-il ? Sur le plan technique, en quoi il contribue à améliorer la vitesse de chargement ? On vous explique ce qu’il faut savoir sur le protocole HTTP/3.
Résumons rapidement les épisodes précédents. HTTP/2 a permis des avancées en termes de performance web par rapport à HTTP/1, notamment :
- le multiplexage des requêtes dans le cadre d’une même connexion TCP, soit la réduction du nombre de cycles “requêtes - réponses - handshake” (moins d’allers-retours, ou RTT = plus de vitesse),
- une meilleure flexibilité dans la priorisation du téléchargement des ressources statiques, en supprimant la contrainte de progression linéaire des téléchargements,
- le format de compression des en-têtes HTTP HPACK,
- le système de push serveur qui permet de précharger des ressources avant que le client ne les demande.
Bien que HTTP/2 ait été conçu avec l’intention d’optimiser la vitesse de chargement des pages, le cryptage TLS imposé par ce protocole (HTTPS) peut entraîner des ralentissements (notre moteur permet de corriger ce point). Ainsi, les améliorations espérées n’ont pas toujours été au rendez-vous. Par ailleurs, dans certains cas, la fonctionnalité de push serveur est complexe voire impossible à déployer (Chrome l’a d’ailleurs dépréciée).
Nouvelle évolution du protocole HTTP, HTTP/3 permet de viser des performances toujours meilleures et ouvre des perspectives très intéressantes que nous allons détailler. Les optimisations par rapport à HTTP/2 portent principalement sur la couche de transport et de sécurité, comme nous l’avons expliqué dans cet article.
Pour comprendre où interviennent ces changements et avec quel impact, commençons par revenir sur l’organisation des différentes couches des protocoles de transfert.
De HTTP/1 à HTTP/3 : comprendre le transfert des données et les couches des différents protocoles
De haut en bas : avec HTTP/2, la couche HTTP traite les requêtes et l'interprétation des données, la couche TLS assure la sécurité par chiffrage, la couche TCP garantit un transport fiable des données et retransmet les paquets perdus, et le protocole IP achemine les paquets d'un point à un autre entre appareils. Pour HTTP/3, TCP est remplacé par UDP, et la couche TLS est intégrée à QUIC (source : Robin Marx / Smashing Magazine)
La couche IP
C’est la couche réseau la plus rudimentaire, et ses spécifications datent de 1974. Elle ne garantit pas la livraison, ni l’intégrité des données ou la commande des paquets transmis… Bref, elle n’est pas fiable.
Aussi, les adresses en 32 bits étant limitées à 4 milliards (le nombre de sites web dans le monde a largement dépassé ce seuil), le standard IPv6 (128 bits) est apparu pour contourner cette limite, et il impose une étape de contrôle supplémentaire par rapport à IPv4. Il est adopté à près de 40% en 2022.
Source : Google
La couche TCP
Transmission Control Protocol (TCP) est la couche qui assure la fiabilité. Ses spécifications datent aussi de 1974, avec une édition en 1981. TCP assure les différents échanges entre serveur et client, l’ordre de transmission des paquets de données, la retransmission des paquets perdus, les accusés de réception de livraison à l'expéditeur, les handshakes et le contrôle des erreurs.
Le nombre de contrôles nécessaires à chaque aller-retour (handshake) a été optimisé avec HTTP/2 pour améliorer la vitesse de chargement des pages.
Les limites de TCP et les raisons du choix de UDP
Avant de transporter quoi que ce soit, TCP a besoin d’une première prise de contact pour établir une nouvelle connexion (handshake) afin de s'assurer que le client et le serveur existent et qu'ils peuvent échanger des données. Cela nécessite un aller-retour (RTT) complet sur le réseau, sachant que selon la distance à parcourir, le trajet peut prendre plus de 100 ms. C’est la latence.
Aussi, TCP considère toutes les données transportées comme un seul fichier, ou flux, bien que ces fichiers transportés soient généralement un mélange de paquets de données issus de différentes ressources. Si un paquet à l’intérieur de ces flux est perdu lors du transport, c’est là que se produit le Head-of-Line blocking, soit le blocage du chargement (comme son nom l’indique). Ce blocage ralentit le chargement global de la page web et impacte les couches suivantes du protocole.
TCP pourrait évoluer à l’aide d’extensions. Mais malheureusement, ces extensions ne pourraient pas être déployées à grande échelle parce qu’elles ne pourraient pas être compatibles dans toutes les situations, en raison de la très grande diversité des équipements (pare-feu, load balancers, routeurs, serveurs de mise en cache, proxies…).
UDP intervient ainsi pour contourner ce problème, et permettre les évolutions souhaitées, vu que le déploiement des optimisations à grande échelle n’est pas envisageable pour cette couche.
La couche UDP
Les spécifications de la couche User Datagram Protocol (UDP) datent de 1980. UDP est utilisé par exemple pour la synchronisation de l'horloge des systèmes informatiques, les applications VoIP, le streaming vidéo, les jeux, le système DNS ou encore le protocole DHCP.
UDP ne prévoit pas de handshake. Autrement dit, il ne garantit pas la commande ni la livraison des paquets de données, et n’assure pas non plus leur intégrité et leur ordre, car ce travail est laissé à la couche application avec QUIC qui intègre la couche de sécurité TLS.
HTTP/3 est ainsi construit au-dessus de la pile réseau de base, plutôt que de la reconstruire.
QUIC (Quick UDP Internet Connexion)
QUIC reprend presque toutes les fonctionnalités de TCP :
- accusés de réception pour les paquets reçus et la retransmission des paquets perdus,
- connexions et handshakes,
- contrôle de flux et de congestion pour éviter les surcharges.
Il dépasse les limites des couches réseau en s'appuyant sur le protocole UDP, et cela sans nécessiter de mise à niveau des noyaux des systèmes à l'échelle d’Internet. Il est “simplement” implémenté de façon plus intelligente et performante que TCP pour compenser ses lenteurs, en déléguant les fonctionnalités de fiabilité et de sécurité à l'espace utilisateur. Et pour faciliter son déploiement, pour les raisons de compatibilité avec les intermédiaires que nous avons évoquées, il est exécuté sur UDP.
Explorons les détails de cette couche et ses avantages.
La réduction du risque de blocage des flux lors de la transmission des données
En principe, si des paquets de données sont perdus pendant un transfert, survient alors le phénomène de Head-of-Line blocking que nous avons vu (blocage des flux de données jusqu’à ce que les paquets perdus soient retransmis).
Le fait que les flux soient multiplexés avec HTTP/2 (soit une connexion TCP pour plusieurs flux de données transférés simultanément) permet de limiter le blocage lié à la perte de paquets. En effet, si un paquet est perdu, les autres flux simultanés peuvent continuer.
Source : Cloudflare
Toutefois, comme HTTP/2 s’appuie sur TCP, le risque de Head-of-Line blocking est réduit, mais il n’est pas nul. Pourquoi ? Parce que TCP ne sait pas ce qu’il transporte.
Ainsi, bien qu’un flux soit constitué d’un mélange de paquets de données issus de différentes ressources, si un paquet est perdu, tous les paquets de tous les fichiers peuvent être bloqués, parce que TCP considère le fichier qu’il transporte comme un tout dont il manque une partie.
C’est là que UDP prend tout son sens avec HTTP/3 : en cas de perte de paquets, QUIC sait ce qu’il transporte, et seul le flux concerné par la perte est affecté, les autres peuvent continuer leur route. Par ailleurs, avec QUIC, de nouveaux flux peuvent démarrer avant que les autres ne soient acheminés.
Enfin, le format de compression des en-têtes HTTP/2 HPACK est remplacé par QPACK avec HTTP/3, ce qui favorise la simplification de la priorisation des flux, et diminue les risques d’erreurs et donc de blocage.
La réduction de la latence, et une fiabilité et une sécurité des échanges accrues
Pour le protocole HTTP/2, avec HTTPS, les données HTTP en clair sont d'abord chiffrées par TLS, puis transportées par TCP.
Avec HTTP/3, QUIC encapsule TLS, ce qui contribue à réduire la latence comme il n’y a pas d’étape de négociation TCP. QUIC permet ainsi d’économiser un aller-retour par rapport à TLS + TCP. En l’absence de TCP, les fonctionnalités de fiabilité sont déplacées au-dessus de la couche UDP (TLS est toujours présent, mais encapsulé dans QUIC, donc).
Le fait que toutes les données soient intégralement chiffrées offre un meilleur niveau de sécurité. A aucun moment les données ne circulent en clair. Néanmoins, le revers de cette sécurisation est le suivant : comme les intermédiaires ont plus de mal à superviser le trafic QUIC, ils peuvent le bloquer par précaution vu qu’ils ne peuvent pas inspecter son contenu. Ainsi, derrière certains pare-feux ou proxies, il est impossible d'accéder à des sites ou des services via HTTP/3. C’est une limite inhérente à ce protocole.
Aussi, QUIC chiffre chaque paquet avec TLS, alors que TLS + TCP peut chiffrer plusieurs paquets en même temps. C’est la raison pour laquelle QUIC est potentiellement plus lourd pour les scénarios à haut débit, mais en contrepartie, QUIC permet d’établir des connexions plus rapides.
HTTP/3 permet d’économiser un échange par rapport à HTTP/2 avec TLS1.3 (source : Robin Marx / Smashing Magazine)
Une meilleure stabilité grâce aux identifiants de connexion
Avec TCP, une connexion est définie par 4 paramètres, sachant qu’ils peuvent changer en cours de navigation (en situation de mobilité par exemple) : adresse IP client, port client, adresse IP serveur, et port serveur.
L’une des autres nouveautés introduites par QUIC est le fait que les connexions sont dotées d’un identifiant unique qui persiste à travers les changements d’adresse IP. C’est utile pour le maintien d’une connexion lors du passage d’un réseau mobile à un réseau Wi-Fi.
Plus de flexibilité et une plus grande évolutivité
QUIC est plus flexible que TCP sur les paramètres de transport qui peuvent être personnalisés (nous allons voir une application concrète pour optimiser la vitesse de chargement un peu plus loin).
Comme les données sont chiffrées, et que les terminaux côté client et serveur n’ont pas besoin d’être mis à jour pour suivre les évolutions de cette couche, il n’y a plus de limites techniques pour enrichir les informations contenues dans les paquets de données. Elles peuvent être envoyées et reçues sans contrainte.
HTTP/3 et vitesse de chargement des pages web
Nous avons vu que HTTP/3 contribue à réduire la latence. Et peut-on dire que QUIC est plus efficace que TCP pour exploiter la bande passante ? Le problème de la perte de paquets peut-il être définitivement éradiqué avec HTTP/3 ?
La gestion de la bande passante et du transport des données avec QUIC
En réalité, une connexion n’exploite jamais 100% de la bande passante, et comme il n’est pas possible de connaître à l’avance sa capacité totale (qui peut en plus varier), TCP envoie des paquets pour “tâter le terrain” et procède à ce qui s’appelle un contrôle de congestion. C’est-à-dire qu’il envoie des paquets jusqu’à ce que certains soient perdus, ce qui indique que le débit maximum est atteint.
Seules quelques dizaines d’octets sont envoyés pour commencer, et le débit augmente au fur et à mesure (comme lorsqu’on ouvre un robinet). C’est notamment de là que vient la fameuse recommandation de réduire le poids des données critiques à moins de 14 Ko : l’objectif est de s’assurer qu’elles passeront “dans le tuyau” dès “l’ouverture du robinet” (et au passage, de favoriser votre FCP, et ça ne devrait pas changer avec HTTP/3).
Nous avons vu que QUIC ne bloque plus les flux quand des paquets de données sont perdus, mais ça ne veut pas dire qu’il ne fait pas de contrôle de congestion, et qu’il ne peut pas y avoir de Head-of-Line blocking ! Apportons donc quelques précisions..
Multiplexage, QUIC et la gestion du Head-of-Line blocking
Chaque navigateur a sa propre stratégie de multiplexage pour organiser la transmission des paquets de données lors d’un transfert. Cette organisation a un impact sur le moment où les ressources peuvent être utilisées :
Représentation du fonctionnement du multiplexage circulaire et séquentiel.
Généralement, le multiplexage séquentiel offre les meilleures performances (source : Robin Marx / Smashing Magazine)
Nous savons maintenant que si des paquets sont perdus, avec QUIC, le reste des flux actifs peut continuer.
Pourtant, avec le multiplexage, si des paquets sont perdus pour chaque flux, le blocage peut malgré tout survenir, puisqu’aucun des flux ne pourra continuer s’ils ont chacun des paquets perdus.
Le principe de la suppression du Head-of-Line blocking introduit par QUIC reste très intéressant, mais avec le multiplexage, selon le nombre de flux simultanés et de paquets perdus, ses avantages peuvent être difficiles à estimer.
Dans tous les cas, mieux vaut continuer de s’appuyer sur une bonne stratégie de cache, et l’automatiser pour la rendre plus efficace et gagner du temps, afin de limiter le nombre de données envoyées en même temps, et éviter que les ressources critiques ne viennent bloquer le rendu (puisqu’elles seront en cache).
En effet, le contrôle de congestion reste nécessaire pour optimiser l’utilisation de la bande passante, et il y a toujours un risque de perte de paquet puisque c’est le signal qui indique que la bande passante est exploitée à son maximum. En revanche, l’impact de ces pertes est limité grâce à UDP.
Le temps économisé sur les RTT et les handshakes grâce à QUIC
Nous avons mentionné le fait que que QUIC est plus évolutif, et voici une application concrète : une extension peut différer les accusés de réception des paquets, par exemple tous les 10 envois au lieu de tous les 2 envois. C’est un gain de temps, puisque les contrôles et les handshakes sont plus espacés, et ce sont autant de millisecondes gagnées au cours des allers-retours de connexion !
Par ailleurs, comme QUIC embarque TLS, l’envoi des requêtes HTTP et le chiffrement se font pendant le même trajet, ce qui permet encore d’économiser un aller-retour.
Enfin, HTTP/3 permet toujours de profiter de l’avantage de la reprise de session TLS lors d’une revisite sur un site web - plus besoin d’attendre un nouveau handshake TLS.
Pour ces raisons, HTTP/3 soulage les serveurs en limitant le nombre d’aller-retours, améliore les performances et la vitesse de chargement.
Les évolutions à venir avec HTTP/3
Dans sa version actuelle, QUIC se concentre sur le transport HTTP, en s’appuyant sur la syntaxe HTTP/2. Nous l’avons souligné en début d’article, HTTP/3 est une avancée qui offre des perspectives très intéressantes pour les performances web.
- A terme, QUIC a vocation à transporter d’autres protocoles que HTTP, comme DNS, SMB ou SSH…
- Dans sa version standardisée, QUIC devrait être amené à utiliser le cryptage TLS1.3, ce qui permettra d’améliorer encore la vitesse en économisant les allers-retours entre serveur et client et les handshakes.
- La résilience en cas de perte de paquets est aussi en voie d’amélioration, des expérimentations sont en cours (et vous pouvez y contribuer).
- Grâce aux ID de connexion, QUIC permet initialement de maintenir la stabilité d’une connexion en cas de changement d’IP. A terme, il pourrait permettre d’utiliser simultanément deux réseaux pour profiter d’une bande passante encore plus puissante.
- QUIC est un protocole entièrement fiable, mais UDP ne l’est pas. QUIC pourrait être utilisé pour envoyer des données “non fiables”, ce qui pourrait être pratique pour des jeux, ou du streaming vidéo en direct. Pour la vidéo, QUIC pourrait aussi faciliter le travail des navigateurs pour estimer et proposer automatiquement la qualité de vidéo la plus adaptée aux conditions de navigation.
Les défis à relever pour généraliser l’implémentation de HTTP/3
Développer la prise en charge de UDP
UDP est plus minimal (et flexible) que TCP : nous avons vu qu’il ne gère pas les paquets perdus, et que les fonctionnalités de fiabilité et de sécurité sont assurées au-dessus, par QUIC. Ainsi, UDP demande plus de travail aux couches logicielles et aux processeurs (le travail qu’il ne fait pas), et sa prise en charge dans les différents équipements réseau est pour le moment moins répandue. Notamment les firewalls d’entreprise peuvent éventuellement bloquer le protocole UDP sans distinction et donc bloquer le trafic HTTP/3, comme nous l’avons mentionné plus tôt.
La rétrocompatibilité
L’une des priorités de l’IETF, qui élabore et promeut les standards d’internet, est d’assurer une rétrocompatibilité. Pour cela, il s’agit d’inclure l’en-tête HTTP qui indique au client que HTTP/3 est disponible, et si le client ne le supporte pas, les versions HTTP/1 et HTTP/2 restent disponibles.
C’est aussi l’une des différences avec HTTP/2, pour lequel le transport se négocie dans le cadre du handshake TLS.
La mise en cache des données de connexion
Enfin, comme HTTP/3 se développe et pourrait devenir une norme, l’objectif est de faire en sorte que les clients puissent mettre en cache les données de connexions HTTP/3 précédentes pour se connecter directement lors de visites ultérieures (et ainsi réduire le nombre d’allers-retours à 0, le graal).
En conclusion, nous avons vu que certaines fonctionnalités accessibles depuis HTTP/2, telles que le push serveur, n’ont pas pu produire les effets attendus pour la performance web et la vitesse d’affichage. D’autres, comme la priorisation des flux, ne sont pas sans soulever des difficultés techniques pour l’implémentation. C’est pourquoi des bonnes pratiques comme la concaténation, la compression et la minification des ressources, dont vous profitez automatiquement avec Fasterize, restent pertinentes et indispensables pour optimiser la vitesse de chargement de vos pages, même avec HTTP/3 !
HTTP/2 ne divise pas les temps de chargement par 2 comme par magie, et il en va de même pour HTTP/3. Affirmer le contraire serait malhonnête.
Néanmoins, les améliorations sur la vitesse de chargement sont déjà nettement visibles pour les réseaux lents, et l’amélioration de la résilience en cas de perte de paquets, l’utilisation simultanée de différents réseaux pour plus de bande passante, la meilleure gestion des flux vidéo… sont des perspectives véritablement réjouissantes en termes de performance web !
En somme, c’est une avancée importante, et la communauté webperf est unanime : il faut prendre le train en marche dès maintenant pour profiter des évolutions qui s’annoncent - et c'est justement notre rôle de vous accompagner dans ce sens.
Vous avez des questions à propos de l'impact de HTTP/3 sur la vitesse de chargement ?
Demandez à nos experts :
