Cet article présente les principaux avantages, mais aussi les défis, du protocole HTTP/3 qui semble être l’avenir pour une meilleure performance web.
Dans notre article précédent intitulé “L’utilisation du protocole HTTP/2 peut améliorer les performances de votre site web”, nous avons abordé les principales limitations de performance des anciens protocoles HTTP/1.x et la manière dont HTTP/2 les aborde pour améliorer les performances du web. Alors que nous assistons toujours à des migrations des services fournis par HTTP/1.1 vers HTTP/2, le marché voit déjà pointer le futur protocole HTTP/3.
Le protocole HTTP/3 améliorera-t-il les performances du web ?
HTTP/2 : quelle est sa limite ?
HTTP/2 a introduit le concept de multiplexage de plusieurs transactions HTTP dans une seule connexion TCP. Ce concept visait à résoudre le problème du blocage de Head Of Line (HOL),l’un des principaux problèmes de performance rencontrés par les services numériques modernes.
Le multiplexage est certainement utile dans le cas de réseaux à haute performance. Malheureusement, il devient inefficace pour les réseaux qui souffrent de perte de paquets. Pire encore l’utilisation de HTTP/2 dans ces réseaux à faible performance peut en fait dégrader les performances globales par rapport à l’utilisation de son homologue HTTP/1.1. En effet si la couche HTTP/2 peut séparer les différentes transactions HTTP sur des flux dédiés, TCP n’a pas connaissance de cette abstraction. Tout ce qu’il voit est un flux d’octets, de sorte que la perte de paquets a le même impact sur toutes les transactions HTTP !
En conclusion, l’utilisation du protocole HTTP/2 ne résout pas complètement le problème du blocage HOL…
C’est là que HTTP/3 entre en jeu pour aider à améliorer les performances du web ! Au lieu d’utiliser TCP comme couche de transport pour la session, il utilise QUIC, un nouveau protocole de transport Internet.
Ainsi, afin de comprendre ce qu’est HTTP/3, abordons d’abord les principales caractéristiques du protocole QUIC.
Qu’est-ce que QUIC ?
QUIC est l’abréviation de « Quick UDP Internet Connection ». Il s’agit d’un nouveau encrypted-by-defaultprotocole de transport, Internet crypté par défaut, qui introduit un certain nombre d’améliorations destinées à accélérer le trafic HTTP et à le rendre plus sûr.
Ainsi, comme son nom l’indique, QUIC ne repose pas sur le protocole de transport TCP utilisé dans les communications HTTP/1.x et HTTP/2 traditionnelles.
Construit sur le protocole UDP, QUIC lui ajoute une série de fonctionnalités afin de le rendre fiable. Il tente également de résoudre les principaux problèmes rencontrés lors de l’utilisation du protocole TCP, qui sont les suivants :
- latence d’établissement de la connexion
- gestion de plusieurs flux en présence de perte de paquets
Actuellement, cette spécification est un projet Internet de l’IETF..
Résolution du problème de la latence due au TCP
Lorsqu’une session TCP est établie, elle déclenche généralement l’algorithme de contrôle de congestion TCP. Il évalue la quantité de trafic qui peut être envoyée avant que la congestion ne se produise par le biais du processus de démarrage lent TCP (Slow Start)..
En s’appuyant sur le protocole UDP et en prenant en charge les flux de première classe, QUIC résout ce problème de latence lié au démarrage lent de la connexion.
Le problème de blocage de HOL est résolu
QUIC va un peu plus loin et offre un support de premier ordre pour le multiplexage, de sorte que différents flux HTTP peuvent à leur tour être mappés sur différents flux de transport QUIC. Mais, bien qu’ils partagent toujours la même connexion QUIC, de sorte qu’aucun établissement de session supplémentaire n’est nécessaire et que l’état de congestion est partagé, les flux QUIC sont transmis indépendamment. Ainsi, dans la plupart des cas, la perte de paquets affectant un flux n’affecte pas les autres
Cela rend QUIC beaucoup plus résistant aux conditions de perte de paquets et donc beaucoup plus efficace pour les connexions Internet de mauvaise qualité ou sujettes à perte.
Sécurité intégrée (et augmentation supplémentaire des performances)
L’une des déviations les plus radicales de QUIC par rapport au désormais vénérable TCP est l’objectif déclaré de fournir un protocole de transport sécurisé par défaut. QUIC atteint cet objectif en fournissant des fonctions de sécurité, comme l’authentification et le cryptage, qui sont généralement gérées par un protocole de couche supérieure (comme TLS), à partir du protocole de transport lui-même.
De par sa conception, QUIC s’appuie sur la version 1.3 de la spécification TLS.
L’établissement de session initial de QUIC combine l’établissement en trois étapes typique de TCP avec la poignée de main TLS 1.3. Cela permet l’authentification des points d’extrémité ainsi que la négociation des paramètres cryptographiques. Cela permet non seulement de garantir que la connexion est toujours authentifiée et cryptée, mais aussi d’accélérer l’établissement de la connexion initiale. La poignée de main QUIC typique ne nécessite qu’un seul aller-retour entre le client et le serveur, alors que deux allers-retours sont nécessaires pour les poignées de main TCP et TLS 1.3 combinées.
Qu’est-ce que le protocole HTTP/3 ?
Le protocole QUIC peut potentiellement supporter n’importe quelle application au-dessus de lui. Cela dit,, la première implémentation est HTTP, de sorte que HTTP fonctionnant sur QUIC est appelé HTTP/3.
En résumé, nous pouvons différencier les différentes spécifications HTTP comme suit :
- HTTP/1 – ASCII sur TCP
- HTTP/2 – multiplexage binaire sur TCP
- HTTP/3 – binaire sur QUIC multiplexé
En outre, si nous prenons en considération la spécification TLS intégrée, les piles HTTPS peuvent être schématisées comme suit :
Comment un client se connecte-t-il en HTTP/3 ?
En général, lorsqu’un client se connecte à un serveur qui supporte HTTP/3, il se connecte d’abord en HTTPS traditionnel sur le port TCP 443.
Le serveur répond alors avec un en-tête de réponse spécifique « Alt-Svc » (service alternatif). Il indique l’endroit où la même ressource demandée est disponible via HTTP/3. Ce service alternatif est défini par une combinaison protocole/hôte/port.
Le navigateur du client met généralement en cache ces informations afin d’éviter d’avoir à établir la connexion TCP initiale la prochaine fois qu’il aura besoin de la même ressource.
Comme alternative, lorsqu’il demande l’adresse IP correspondant au FQDN (Fully Qualified Domain Name) du serveur, le client peut obtenir le RR (Resource Record, “enregistrement de ressource”) HTTPS de la réponse DNS. Dans ce cas, il est informé que le serveur supporte HTTP/3 avant de s’y connecter.
HTTP/3 : la future norme de facto ?
HTTP/3 promet de rendre les connexions Internet plus rapides, plus fiables et plus sûres.
Comme indiqué précédemment dans cet article, HTTP/3 est toujours en cours de définition par l’IETF. Aucune date de sortie officielle n’a encore été fixée. Entre-temps, l’adoption de HTTP/3 se développe, avec près de 400 000 services l’utilisant dans le monde. Google est toujours la première organisation à déployer HTTP/3, mais plusieurs autres en prennent une part non négligeable.
Près de 19% des sites web mondiaux prennent en charge HTTP/3 aujourd’hui..
Du point de vue des navigateurs, HTTP/3 est désormais pris en charge par défaut par les dernières versions des principaux navigateurs.
L’adoption de HTTP/3 se développe, mais il reste des défis majeurs à relever avant de voir une évolution massive sur le marché. .
Résumons rapidement certains d’entre eux..
Ossification
L’épine dorsale qui forme l’Internet est remplie d’équipements divers : routeurs, passerelles, pare-feu, équilibreurs de charge, etc.. Ceux-ci exécutent généralement des logiciels pour gérer le trafic réseau, qui sont rarement mis à jour.
Ce phénomène est souvent appelé « ossification ». Cela signifie que beaucoup de ces équipements ne sont pas encore capables de comprendre QUIC.
Les routeurs NAT en sont un exemple. Étant donné que la plupart des routeurs NAT ne comprennent pas QUIC, ils se rabattent généralement sur la gestion par défaut et moins précise des flux UDP, ce qui implique généralement l’utilisation de délais arbitraires, parfois très courts,, qui peuvent affecter les connexions de longue durée.
Problèmes de sécurité
Les fournisseurs de sécurité ne sont pas de grands fans de l’UDP. UDP est souvent utilisé pour des cyberattaques comme DDoS.
En outre, étant donné que QUIC est chiffré par défaut, les fournisseurs de sécurité sont incapables d’analyser les données utiles pour détecter tout comportement anormal et toute menace potentielle pour la sécurité
En conséquence, certains réseaux bloquent sciemment QUIC !
Performance et autres préoccupations
Les dispositifs d’extrémité sont généralement optimisés pour gérer le trafic TCP, mais pas pour UDP.
Par exemple, si la plupart des appareils prennent en charge la fonction de déchargement TCP (“TCP offloading”) au niveau de leurs cartes d’interface réseau, la prise en charge de cette technique d’optimisation des performances pour le trafic UDP n’est pas courante.
Par rapport à son homologue TCP, UDP souffre également d’un manque de support des API. C’est également le cas pour les bibliothèques TLS sur QUIC, car QUIC n’utilise que les messages TLS, et non les enregistrements TLS. TLS est un sujet important qui sera abordé dans les prochains articles du blog.
Récapitulatif : Comment utiliser le protocole HTTP/3 pour améliorer la performance web
HTTP/3 est un protocole très prometteur.
Il permet d’améliorer les performances, notamment en cas de conditions de réseau non optimales.
Grâce à son approche « secure-by-design », il jouera également un rôle important dans la sécurisation de l’internet.
Cela étant dit, il n’existe pas encore de véritable benchmark permettant de mesurer réellement l’augmentation des performances que HTTP/3 pourrait apporter.
En outre, le processus d’adoption de HTTP/3 est nettement plus lent que celui de HTTP/2 en raison de l’absence de prise en charge native de QUIC et des considérations de sécurité liées à l’utilisation de la couche UDP.
