HTTP est un protocole de transfert hypertexte qui permet d’assurer le transport des données entre client et serveur. Comment sommes-nous passés de HTTP/1 à HTTP/3 ? Pourquoi, et quelles sont les évolutions et les améliorations apportées d’une version du protocole à l’autre ? Voyons ce qui change avec HTTP/3, et comment il permet d’aller vers un web toujours plus rapide et sécurisé.
Le protocole HTTP repose sur TCP, et TCP permet d’assurer la réception de l'intégralité des messages (contrôle d’intégrité), pour valider que les données qui voyagent arrivent à bon port et en bon état. C’est ce contrôle continu qui ralentit le transfert des données.
Afin de contribuer à rendre le web plus rapide tout en conservant la sécurité, Google a introduit QUIC, au départ envisagé comme une nouvelle version du protocole HTTP.
QUIC met TCP de côté au profit de UDP. Quel est l’intérêt ? L’avantage de UDP est que, tout en permettant toujours d’assurer l’intégrité des données, il ne prévoit pas de contrôle des messages tel que TCP le fait, ce qui le rend bien plus performant. Ce serait comme supprimer un péage sur une route : il n'y aurait plus d’étape entraînant un ralentissement du trafic..
Vous avez forcément déjà rencontré UDP : il est utilisé par exemple dans les protocoles de streaming, pour faire en sorte de ne pas dégrader l’expérience utilisateur en cas de perte partielle de données.
En pratique, grâce à QUIC, Google a observé une amélioration de la vitesse de chargement moyenne de 8 % au niveau mondial, et de 13 % dans les zones où la latence est élevée. Nous allons revenir plus loin sur les raisons de ces améliorations, et pour commencer, revenons à quelques notions historiques sur le protocole HTTP, afin de comprendre pourquoi il avait grand besoin d’évoluer.
De HTTP/1 à HTTP/3 real QUIC
HTTP/1.1 et le Keep-Alive pour pallier les limites de HTTP/1 (et de 0.9)
Avant HTTP/1, au début des années 1990, une version 0.9 permettait des échanges selon le protocole suivant, d’une grande simplicité :
- connexion du client HTTP
- envoi d'une requête (GET)
- réponse du serveur HTTP
- fin de la réponse, fermeture de la connexion.
Comme le protocole HTTP 0.9 ne permettait que l’envoi de fichiers HTML et ne permettait pas d’obtenir des informations sur le succès ou l’échec de la requête, le protocole HTTP/1.0 a vu le jour pour dépasser ces limites. Reprenant le même principe que la version 0.9, il a permis d’ajouter des en-têtes pour assurer le transfert de métadonnées, telles que Host, Referer, User-Agent… Il supporte aussi des méthodes telles que HEAD et POST.
A partir de 1997, HTTP/1.1 améliore la gestion du cache, et rend obligatoire l’en-tête Host dans les requêtes (possibilité d’hébergement de différents domaines sur la même adresse IP, et de colocation de serveurs).
Mais il reste encore des limites avec cette nouvelle version du protocole :
- le nombre de connexions pendant le chargement d’une page web, notamment quand elle contient beaucoup d’images ou d’animations ;
- et le temps nécessaire pour l’établissement de la connexion TCP qui augmente la latence.
L’en-tête Connection:Keep-Alive aura permis d’adresser partiellement ce point en réutilisant une même connexion (dite connexion persistante, plutôt que de perdre du temps à en ouvrir de nouvelles), mais ça ne résout pas totalement ce problème de latence pour améliorer la vitesse de chargement.
Au cours du temps, le protocole a été exploité grâce à des en-têtes de plus en plus intelligentes pour l’améliorer et augmenter ses fonctionnalités (session, websocket…).
HTTP/2 : l’avènement du multiplexage des requêtes
En 2015, HTTP/2 fait son apparition. La syntaxe reste relativement similaire à celle de HTTP.1, mais nouveauté majeure : cette nouvelle version permet de multiplexer les requêtes.
Waterfall issu de WebPageTest à gauche pour un site avec HTTP.1, à droite avec HTTP/2
Comme on le voit dans les deux illustrations ci-dessus, le waterfall, qui représente le chargement d’une page web, ressemble à une cascade progressive (requêtes séquentielles) avec HTTP/1 car les ressource sont récupérées l’une après l’autre, et se transforme en chute d’eau abrupte avec HTTP/2 (requêtes multiplexées et donc faites en parallèle).
En passant de HTTP/1 à HTTP/2, seul le mode de segmentation des données et leur transport évoluent. Il n’est donc pas nécessaire de modifier les applications web existantes, mais elles peuvent l’être (ou les prochaines) pour profiter des avantages de HTTP/2 en termes de vitesse de chargement.
Avec HTTP/2, il devient donc moins indispensable de concaténer les ressources JavaScript, CSS, HTML… Par ailleurs, le système de push permet au serveur d’envoyer les ressources avant même que le client ne les sollicite, pour économiser du temps sur les connexions HTTP et le chargement des en-têtes.
Enfin, le protocole étant modulaire, HTTP/2 permet la prise en charge de nouvelles en-têtes au fil du temps, telles que Alt-Svc (notamment pour optimiser le téléchargement des ressources), Client-Hints (pour informer le serveur des contraintes du navigateur)...
Aujourd’hui, l’un des éléments responsables du temps de chargement des pages web - HTTP/2 ou non - c’est que l’intégralité des sites internet est sécurisée grâce à TLS (HTTPS) ce qui peut entraîner… un temps de chargement supplémentaire. C’est là que HTTP/3 entre en scène.
Si l’histoire - et la pré-histoire - de HTTP/3 vous intéresse, vous trouverez plus d’informations ici.
HTTP/3 : pour (encore) plus de rapidité et de sécurité
En 2018, HTTP/3 fait son apparition. Il repose sur QUIC (et donc UDP), comme nous l’avons évoqué un peu plus tôt. Le protocole est similaire à HTTP/2, à ceci près que la couche de transport et de chiffrement sont encore plus performants. Voyons plus précisément pourquoi.
De manière générale, les évolutions de HTTP ont toujours eu pour objectif de pallier les limites de TCP, et UDP permet justement de les contourner.
Par ailleurs, TCP pose un problème de sécurité car les informations transitent en clair. Le chiffrement TLS est une réponse… mais cette solution ajoute des étapes et donc de la latence (encore elle).
Tout l’intérêt de QUIC est ainsi d’offrir les avantages du three-way handshake habituel de TCP avec le handshake de TLS 1.3. En deux mots : performance et sécurité.
A présent, explorons en détail les avantages de HTTP/3 par rapport à son prédécesseur.
Les avantages de HTTP/3 par rapport à HTTP/2
L’amélioration de la vitesse de chargement
Avec TCP et TLS, il faut 2 à 3 allers-retours avec le serveur pour établir une connexion sécurisée, avant que le navigateur ne soit en mesure d’envoyer une requête (sachez que notre moteur permet de raccourcir ce délai et de limiter le nombre d’échanges grâce à la reprise de session TLS. Le chargement des pages web est ainsi accéléré) :
Avec QUIC, si des échanges ont déjà eu lieu entre le serveur et le client, il n’y a plus d’allers-retours à prévoir. Le nombre d’allers-retours étant réduit, le temps de chargement l’est aussi.
L’amélioration de la sécurité
QUIC ne s’arrête pas en si bon chemin sur la route de la performance : tout est prévu côté sécurité avec un système natif de chiffrement et de sécurisation. Il s’agit de QUIC Crypto, une méthode similaire à TLS 1.3, qui permet à QUIC d’envoyer au serveur toutes les requêtes de connexion et de chiffrement en une seule fois. Il n’y a donc plus d’allers-retours ni de latence pour les connexions déjà connues (0-RTT).
Une gestion des paquets plus souple
L’un des autres avantages de QUIC, c’est le fait de réussir à se passer de TCP, de conserver l’intégrité des paquets, mais aussi de ne plus se préoccuper de leur ordre.
TCP peut poser le problème bien connu du head-of-line blocking. C’est-à-dire qu’en cas d’incident lors de l’émission des paquets de données, si le premier paquet d’un lot est perdu dans un stream TCP, alors tous les streams qui suivent attendent que le paquet manquant soit re-transmis et reçu.
Le problème perdure avec HTTP/2 + TCP (dans certains cas, cela peut même conduire à une latence encore plus importante qu’avec HTTP/1), mais avec HTTP/3, il disparaît ! En effet, les ressources qui arrivent peuvent être traitées dès qu’elles sont complètes, au lieu d’attendre de recevoir les paquets dans l’ordre.
En outre, comme HTTP/3 n’est plus lié aux adresses IP mais qu’il se sert d’identifiants de connexion individuels, le téléchargement de données peut rester constant même en cas de changement de réseau.
C’est particulièrement intéressant pour les connexions mobiles, lorsqu’on passe d’un réseau à l’autre (par exemple, de la 4G quand on sort des transports ou de sa voiture, et qu’on passe en Wi-Fi en arrivant au bureau ou chez soi).
Etant donné tous ces avantages, vous vous demandez peut-être à quel point l’usage de HTTP/3 est développé ! La première connexion interopérable a eu lieu en 2018 entre LiteSpeed et Facebook… mais début 2020, seulement 2,9% des sites internet l’utilisent. Vous pouvez suivre l’évolution de la standardisation en cours ici.
Pourquoi une adoption si faible ? Mike Bishop, éditeur du protocole HTTP/3, résume très bien la situation dans ces quelques lignes sur le blog d’Akamai :
“… de nombreuses fonctionnalités de transport qu'offre QUIC peuvent également être réalisées en TCP. Les innovations telles que SACK, RACK, horodatages ACK, TCP Fast Open et Multipath TCP ne sont pas nouvelles.
TLS 1.3 prend en charge les premières données, que vous utilisiez TCP ou QUIC. La difficulté pour ces fonctionnalités est le déploiement, pas l'invention. Beaucoup de ces fonctionnalités ne peuvent pas être utilisées sur les réseaux actuels, en raison d'un problème fondamental dans TCP. TCP est tout simplement trop connu. Et par cela, je veux dire que les équipements réseaux croient qu'ils peuvent interpréter et modifier les paquets qui transitent chez eux, car ils pensent savoir comment TCP est censé se comporter. Le résultat est qu'une grande partie de l'innovation qui s'est produite dans le domaine du transport de données au cours des dernières décennies est encore très difficile à déployer en pratique, car ces équipement ne fonctionnent pas correctement lorsqu'ils sont confrontés à un paquet TCP qui ne se comporte pas comme prévu.”
Voici pour finir quelques take-aways à propos de HTTP/3 :
- Le projet derrière QUIC est de réduire la latence grâce au 0-RTT.
- Son intérêt réside dans le fait qu’il permet seulement 3 handshakes, dont le chiffrement.
- C’est donc du temps gagné sur le transport ET sur le chiffrement.
Source : Benoît Jacquemont @ We Love Speed 2019
Alors, si vous avez la possibilité d’utiliser HTTP/3 sur votre serveur et votre CDN, allez-y ! Vos utilisateurs pourront récupérer un plus grand nombre de ressources en parallèle, et économiser du temps de chargement, en particulier s’il y a beaucoup de latence sur le réseau.
Quelques ressources pour approfondir vos connaissances sur le sujet :
- HTTP/3 Explained (une documentation complète sur les protocole HTTP/3 et QUIC)
- An Academic’s Guide to QUIC (pour comprendre les bases de QUIC et HTTP/3, et les avancées grâce à ces protocoles)
- Et un outil pour vérifier si votre serveur supporte HTTP/3 : HTTP3Check.net.
Et pour suivre l’actu Webperf et ses évolutions, et approfondir vos connaissances,
abonnez-vous à notre newsletter mensuelle !
