Que sont QUIC et HTTP/3 ?

Quick UDP Internet Connections (QUIC) est un protocole de couche transport à usage général conçu pour remplacer le protocole de contrôle de transmission (TCP) grâce à sa flexibilité, à sa sécurité intégrée, à la réduction des problèmes de performances et à son adoption plus rapide. Initialement développé par Google, QUIC utilise le protocole UDP (User Datagram Protocol) comme mécanisme de transport de bas niveau pour acheminer les paquets entre le client et le serveur. QUIC intègre également le protocole TLS (Transport Layer Security) comme composant à part entière, et non comme une couche supplémentaire à l’instar de HTTP/1.1 et HTTP/2.

HTTP/3, basé sur QUIC, est la troisième version majeure du protocole de transfert hypertexte (HTTP) et a été adopté comme norme de l’IETF en 2022. QUIC+HTTP/3 ont été créés pour remédier aux limitations inhérentes à TCP qui nuisent aux performances et à l’expérience utilisateur.

Comment fonctionnent les API ?

Les API sont la « vitrine » des applications : elles présentent les fonctions qu’elles exécutent et les informations qu’elles peuvent fournir, tout en définissant le format approprié des requêtes. Lorsqu’un développeur crée et expose l’API d’une application, il permet à d’autres applications de communiquer avec celle-ci.

Dans de nombreux cas, les API font gagner un temps précieux aux développeurs en mettant à leur disposition des fonctions couramment utilisées. Plutôt que de reproduire les fonctionnalités d’une application existante, les développeurs peuvent les intégrer à leurs propres applications en effectuant des appels à l’API de l’application existante.

Vue d’ensemble des piles de transport HTTP

Principes de base de QUIC+HTTP/3

L’objectif de QUIC est de fournir un protocole de transport hautement performant, fiable et sécurisé pour HTTP/3 (bien que QUIC convienne également au trafic non-HTTP).

Si vous ne connaissez pas du tout QUIC, nous vous recommandons de regarder la vidéo d’introduction ci-dessous.

UDP, TCP et TLS

UDP est un protocole simple et léger qui, contrairement à TCP, ne nécessite pas de procédure complexe de négociation en trois étapes pour établir la connexion initiale. Cette simplicité rend UDP rapide et lui permet de fonctionner sans connexion, mais elle implique également qu’il ne dispose pas des fonctionnalités essentielles à des communications fiables et sécurisées dont bénéficie TCP.

QUIC se distingue par le fait qu’il combine les avantages des protocoles UDP et TCP. Bien qu’il fonctionne sans connexion et s’appuie sur UDP comme protocole de transport de bas niveau afin de réduire les délais de connexion et de transport, il est orienté connexion dans les couches supérieures grâce à sa réimplémentation des fonctionnalités de TCP relatives à l’établissement de la connexion et à la détection des pertes, qui garantissent la livraison des paquets. Il se charge d’identifier les données perdues et d’effectuer les retransmissions afin d’assurer une expérience utilisateur fluide.

QUIC intègre également TLS en tant que composant à part entière, et non comme une couche supplémentaire, comme c’est le cas avec HTTP/1.1 et HTTP/2. Cette intégration garantit que les messages sont chiffrés par défaut.

Présentation d’un réseau QUIC

Le schéma ci-dessous illustre l’architecture de base d’un réseau QUIC. Comme le montre le schéma, les objets logiques qui contiennent les requêtes et réponses HTTP/3, ou toute autre donnée applicative, sont les flux QUIC. Pour être transmis entre les points de terminaison du réseau, les flux QUIC sont encapsulés dans plusieurs couches logiques.

Anatomie d’un flux QUIC

En partant de l’extérieur vers l’intérieur, les couches et objets logiques sont les suivants :

Datagramme UDP – Contient un en-tête indiquant les ports source et de destination (ainsi que les données de longueur et de somme de contrôle), suivi d’un ou plusieurs paquets QUIC. Le datagramme est l’unité d’information transmise du client au serveur sur le réseau.
Paquet QUIC – Contient un en-tête QUIC et une ou plusieurs trames QUIC.
En-tête QUIC – Contient des métadonnées sur le paquet. Il existe deux types d’en-tête :
- L’en-tête long, utilisé lors de l’établissement de la connexion.
- L’en-tête court, utilisé une fois la connexion établie. Il contient, entre autres, l’identifiant de connexion, le numéro de paquet et la phase de clé (qui permet de déterminer quelles clés ont servi à chiffrer le paquet, afin de prendre en charge la rotation des clés). Les numéros de paquet sont uniques (et toujours croissants) pour une connexion et une phase de clé données.
Trame – Contient le type, l’identifiant du flux, le décalage et les données du flux. Les données du flux sont réparties sur plusieurs trames, mais peuvent être réassemblées à l’aide de l’identifiant de connexion, de l’identifiant du flux et du décalage, qui permet de présenter les blocs de données dans le bon ordre.
Flux – Un flux de données unidirectionnel ou bidirectionnel au sein d’une même connexion QUIC. Chaque connexion QUIC peut prendre en charge plusieurs flux indépendants, chacun possédant son propre identifiant de flux. Si un paquet QUIC contenant certains flux est perdu, cela n’affecte pas la progression des flux qui ne figurent pas dans le paquet manquant (ce point est essentiel pour éviter le blocage en tête de ligne rencontré avec HTTP/2). Les flux peuvent être bidirectionnels et créés par l’un ou l’autre des points de terminaison.

Fonctionnement de QUIC avec une négociation TLS

Une négociation TLS établit une connexion sécurisée entre le client et le serveur. Le chiffrement fourni par QUIC nécessite TLS v1.3. Comme l’illustre le schéma ci-dessous, QUIC conserve la « couche de contenu » de TLS, qui fournit les clés cryptographiques, mais remplace la « couche d’enregistrement » par son propre mécanisme de transport.

QUIC s’appuie également sur TLS pour l’authentification et la négociation de paramètres essentiels à la sécurité et aux performances. Plutôt que de suivre une architecture en couches stricte, les deux protocoles coopèrent : QUIC utilise la négociation TLS pour établir une connexion sécurisée, tandis que TLS exploite la fiabilité, la livraison ordonnée et la couche d’enregistrement fournies par QUIC.

Globalement, il existe deux interactions principales entre les composants TLS et QUIC :

Le composant TLS envoie et reçoit des messages par l’intermédiaire du composant QUIC, qui fournit à TLS une abstraction de flux fiable.
Le composant TLS fournit une série de mises à jour au composant QUIC, notamment (a) de nouvelles clés de protection des paquets à installer et (b) des changements d’état tels que la fin de la négociation, le certificat du serveur, etc.

Options de prise en charge de HTTP/3 pour QUIC TLS

QUIC TLS est une variante de TLS spécialement conçue pour le protocole QUIC. Actuellement, deux options s’offrent aux utilisateurs qui souhaitent bénéficier de la prise en charge de HTTP/3 dans QUIC TLS :

Implémentation QUIC d’OpenSSL – OpenSSL travaille actuellement à la mise en œuvre de sa propre pile QUIC complète. Cette évolution intégrera toutes les fonctionnalités QUIC au sein de l’implémentation, ce qui permettra aux utilisateurs de HTTP/3 d’utiliser beaucoup plus facilement l’API TLS d’OpenSSL sans avoir à se soucier des fonctionnalités propres à QUIC.
Bibliothèques prenant en charge l’API QUIC de BoringSSL – Diverses bibliothèques SSL telles que BoringSSL, quicTLS et LibreSSL (initialement issue d’un fork d’OpenSSL) proposent désormais des fonctionnalités TLS pour QUIC en implémentant l’API QUIC de BoringSSL. Il s’agit actuellement de la seule option pour les utilisateurs souhaitant utiliser HTTP/3, car l’implémentation QUIC TLS d’OpenSSL n’est pas encore prête.

Avantages de QUIC+HTTP/3

QUIC+HTTP/3 visent à améliorer les performances des applications web en réduisant la latence et en optimisant la transmission des données sur les réseaux peu fiables. Leurs avantages sont notamment les suivants :

Latence réduite – Les protocoles traditionnels tels que TCP souffrent d’une certaine latence en raison de leur processus d’établissement de connexion. Les capacités de multiplexage de QUIC+HTTP/3 permettent d’établir les connexions plus efficacement, réduisant ainsi la latence lors de l’établissement des connexions et de la transmission des données.
Établissement plus rapide de la connexion – QUIC+HTTP/3 combine la négociation TLS et la configuration du chiffrement en une seule étape, réduisant ainsi le nombre d’allers-retours nécessaires pour établir une connexion sécurisée.
Multiplexage – En gérant plusieurs flux de données au sein d’une même connexion, QUIC+HTTP/3 permettent d’utiliser plus efficacement les ressources réseau et contribuent à éviter le problème de blocage en tête de ligne, où un flux lent pourrait retarder les autres dans les connexions TCP traditionnelles.
Correction d’erreurs améliorée – QUIC intègre des techniques de correction d’erreurs sans voie de retour, qui permettent de récupérer les paquets perdus sans avoir à les retransmettre, réduisant ainsi l’impact de la perte de paquets sur les performances.
Impact réduit de la perte de paquets – UDP fonctionne sans connexion et permet une transmission plus rapide sans nécessiter les contrôles d’erreurs rigoureux de TCP. Cela est particulièrement avantageux lorsque les conditions du réseau sont moins stables.
Contrôle adaptatif de la congestion – QUIC+HTTP/3 sont conçus pour être plus efficaces et réactifs que le mécanisme de contrôle de la congestion de TCP, ce qui améliore les performances dans des environnements réseau variables.
Prise en charge de la migration – QUIC+HTTP/3 permet de passer de manière fluide d’une connexion réseau à une autre (par exemple, du Wi-Fi au réseau mobile) sans perturber les performances de l’application.
Sécurité renforcée – QUIC+HTTP/3 intègrent le chiffrement par défaut, ce qui améliore la sécurité et la confidentialité de la transmission des données. Ce chiffrement empêche l’interception et l’altération des données en transit.
Traversée de NAT – L’utilisation d’UDP par QUIC+HTTP/3 peut faciliter la traversée de la traduction d’adresses réseau (NAT), ce qui simplifie l’établissement de connexions dans les situations où les connexions TCP traditionnelles pourraient rencontrer des difficultés.
Évolution constante – Comme QUIC+HTTP/3 ont été conçus pour être déployés et mis à jour par voie logicielle, sans nécessiter de modifications de l’infrastructure réseau sous-jacente, ils peuvent être actualisés et améliorés plus rapidement afin de s’adapter à l’évolution des conditions du réseau et des enjeux de sécurité.

Contenu associé