En 2016, Google passe les documents de ce protocole au groupe de travail de l’IETF (Internet Engineering Task Force – groupe chargé d’établir des standards pour la suite de protocoles du modèle Internet) pour qu’il poursuive son évolution et qu’il soit intégré à la suite de protocoles du modèle Internet.
L’objectif premier de QUIC est d’améliorer les performances des applications Web orientées connexion qui utilisent actuellement TCP en utilisant des connexions multiplexées et en réduisant la latence durant la connexion et le transport notamment.
En effet, l’un des principaux objectifs de HTTP/2 était d’éviter le blocage en tête de ligne (« head of line blocking » ou blocage HOL). Le blocage en tête de ligne est un phénomène limitant les performances qui se produit lorsqu’un ensemble de paquets (et donc de requêtes) est bloqué par le premier paquet (et donc la première requête), c’est-à-dire par le paquet en « tête de ligne ».
Pour résoudre ce problème, HTTP/2 a implémenté le multiplexage au-dessus de TCP. Le multiplexage HTTP correspond à la réutilisation des connexions de serveur établies pour les connexions de plusieurs clients. Grosso modo, l’idée est de laisser une connexion au serveur ouverte un certain temps plutôt que de la fermer immédiatement afin de pouvoir réutiliser cette même connexion dans le cas où le client effectue une nouvelle requête au serveur. Le multiplexage permet ainsi d’effectuer plusieurs requêtes sur une même connexion et permet de réduire la latence.
Le problème avec HTTP/2 est que la correction du blocage de tête de ligne dans HTTP a repoussé une partie du problème au niveau de la couche transport. En effet, lorsqu’un paquet est perdu, TCP met en tampon tous les paquets suivants jusqu’à ce qu’il soit retransmis avec succès, même lorsque l’application pourrait utiliser certaines de ces données mises en mémoire tampon (comme c’est le cas lorsque le multiplexage est activé avec HTTP). Ainsi, certaines connexions HTTP avec pertes inhérentes comme le streaming vidéo par exemple ont vu constaté des performances réduites avec HTTP/2.
Le protocole TCP garantit l’intégrité des données. Pour ce faire, TCP décompose les données en paquets réseau et ajoute de petites quantités de données à chaque paquet. Ces données supplémentaires comprennent un numéro de séquence utilisé pour détecter les paquets perdus ou transmis dans le désordre, et une somme de contrôle qui permet de détecter les erreurs dans les données de paquet. Si un problème survient, TCP utilise un procédé de répétition automatique de requête (ARQ = automatic repeat request) pour dire à l’expéditeur de renvoyer le paquet perdu ou endommagé.
Les erreurs sont bloquantes pour TCP dans la plupart des implémentations, ce qui signifie que les autres transferts vont être mis en attente jusqu’à ce que l’erreur soit résolue ou que la connexion soit considérée comme ayant échoué. Si une seule connexion est utilisée pour envoyer plusieurs flux de données, comme c’est le cas dans le protocole HTTP/2, tous ces flux sont bloqués bien qu’un seul d’entre eux puisse avoir un problème.
TCP est conçu pour ressembler à un flux de données et contient délibérément peu de compréhension des données qu’il transmet. Si ces données ont des exigences supplémentaires, comme le chiffrement à l’aide de TLS, cela doit être configuré par des systèmes fonctionnant au-dessus de TCP. Ce type d’opération nécessite d’établir une nouvelle liaison (un handshake) à chaque fois et on va donc souvent avoir plusieurs allers-retours de requêtes et de réponses jusqu’à ce que la connexion soit établie. En raison de la latence inhérente des communications à longue distance, cela peut ajouter une surcharge importante à la transmission globale.
QUIC se base sur le modèle de flux HTTP/2 et l’intègre dans la couche de transport, de sorte qu’une seule connexion puisse progresser sur un flux même si des paquets contenant des données provenant d’autres flux sont perdus, atténuant ainsi le problème de blocage en tête de ligne dans le transport ainsi que dans la couche d’application.
Pour faire cela, QUIC est construit sur le protocole UDP (User Datagram Protocol) plutôt que sur TCP et intègre le cryptage par défaut.
Aujourd’hui, la plupart des connexions HTTP sont sécurisées (HTTPS) via TLS. QUIC intègre l’échange des clés de configuration et des protocoles pris en charge dans le processus de prise de contact initial. Ainsi, lorsqu’un client ouvre une connexion, le paquet de réponse inclut les données nécessaires pour que les futurs paquets puissent utiliser le chiffrement. Cela élimine le besoin de configurer la connexion TCP, puis de négocier le protocole de sécurité via des paquets supplémentaires.
QUIC est également construit sur UDP qui n’inclut pas de mécanisme de récupération des pertes. Pour contourner ce problème, chaque flux QUIC est contrôlé indépendamment et les données perdues sont retransmises au niveau de QUIC et non pas de UDP.
Cela signifie que si une erreur se produit dans un flux la pile de protocoles peut continuer à desservir d’autres flux indépendamment. Cela améliore grandement les performances sur les liaisons sujettes aux erreurs puisque dans la plupart des cas une quantité non négligeable de données peuvent être reçues avant que TCP ne remarque qu’un paquet est manquant ou cassé et ces données vont alors être bloquées voire effacées pendant que l’erreur est corrigée tandis qu’avec QUIC ces données sont libres d’être traitées pendant que le flux multiplexé unique est réparé.
En octobre 2018, les groupes de travail HTTP et QUIC de l’IETF ont décidé conjointement d’appeler le mappage HTTP sur QUIC « HTTP/3 » avant d’en faire une norme mondiale. HTTP/3 est dont bâti sur QUIC et fonctionne avec UDP plutôt qu’avec TCP comme protocole de transport des données.
TCP est aujourd’hui encore considéré comme étant la norme et l’infrastructure Internet en général est configurée pour fonctionner avec ce processus et dans certains cas certains composants peuvent bloquer UDP. Dans ces cas, un système de repli rapide vers TCP qui n’entraine pas de latence est utilisé.
