QUIC est un nom, pas un acronyme. Il se prononce exactement comme le mot anglais "quick".
QUIC est à bien des égards ce qui pourrait être perçu comme un moyen de créer un nouveau protocole de transport fiable et sécurisé, adapté à un protocole comme HTTP et pouvant résoudre certains des inconvénients connus de HTTP/2 sur TCP et TLS. La prochaine étape logique dans l'évolution du transport Web.
QUIC n'est pas limité au seul transport de HTTP. La volonté de rendre le web et les données en général plus rapides aux utilisateurs finaux est probablement la raison principale et la poussée qui a initialement déclenché la création de ce nouveau protocole de transport.
Alors pourquoi créer un nouveau protocole de transport et pourquoi le faire par dessus UDP?
Si nous ne pouvons pas résoudre le blocage de la tête de ligne dans TCP, nous devrions théoriquement pouvoir créer un nouveau protocole de transport à côté de UDP et TCP dans la stack réseau. Ou peut-être même utilisez-vous SCTP qui est un protocole de transport normalisé par l'IETF dans la RFC 4960 avec plusieurs des caractéristiques souhaitées.
Cependant, au cours des dernières années, les efforts pour créer de nouveaux protocoles de transport ont été presque complètement arrêtés en raison de la difficulté de les déployer sur Internet. Le déploiement de nouveaux protocoles est entravé par de nombreux pare-feu, NATs, routeurs et autres boîtes centrales qui autorisent uniquement le protocole TCP ou UDP déployés entre les utilisateurs et les serveurs qu’ils doivent atteindre. L'introduction d'un autre protocole de transport provoque l'échec de N% des connexions car elles sont bloquées par des boîtes ne la voyant pas comme étant UDP ou TCP et donc malfaisantes ou erronés d'une manière ou d'une autre. Le taux d'échec de N% est souvent jugé trop élevé pour en valoir la peine.
De plus, les modifications apportées à la couche de protocole de transport de la stack réseau impliquent généralement des protocoles implémentés par les noyaux de système d'exploitation. La mise à jour et le déploiement de nouveaux noyaux de système d'exploitation est un processus lent qui nécessite des efforts importants. De nombreuses améliorations TCP normalisées par l'IETF ne sont pas beaucoup déployées ou utilisées car elles ne sont pas énormément prises en charge.
SCTP est un protocole de transport fiable avec des flux, et pour WebRTC, il existe même des implémentations existantes qui l'utilisent via UDP.
Cela n’a pas été jugé suffisant comme alternative à QUIC pour plusieurs raisons, notamment:
SCTP ne résout pas le problème de blocage de tête de ligne pour les flux
SCTP exige que le nombre de flux soit déterminé lors de l'établissement de la
connexion
SCTP n'a pas un solide concept TLS/de sécurité
Pour plus de détails sur les différences, voir .
QUIC est un flux par octet comme TCP, SCTP est basé sur des messages
Les connexions QUIC peuvent migrer entre les adresses IP, mais SCTP ne peut pas
QUIC est toujours sécurisé. Il n'y a pas de version en texte clair du protocole, donc négocier une connexion QUIC signifie faire de la cryptographie et de la sécurité avec TLS 1.3. Comme mentionné ci-dessus, cela empêche l'ossification ainsi que d'autres types de blocages et traitements spéciaux, et garantit que QUIC possède toutes les propriétés sécurisées de HTTPS auxquelles les utilisateurs Web s'attendent et souhaitent.
Il n’y a que quelques paquets handshake initiaux qui sont envoyés en clair, avant que les protocoles de cryptage aient été négociés.
QUIC offre à la fois des handshakes 0-RTT et 1-RTT qui réduisent le temps nécessaire pour négocier et établir une nouvelle connexion. Comparez avec le handshake à 3 voies du TCP.
En plus de ça, QUIC offre une prise en charge des "données antérieures" dès le départ, ce qui est fait pour autoriser plus de données et est utilisé plus facilement que TCP Fast Open.
Avec le concept de flux, vous pouvez établir une autre connexion logique avec le même hôte sans avoir à d'abord attendre la fin de la connexion existante.
TCP Fast Open a été publié en décembre 2014 en tant que la RFC 7413 et cette spécification explique comment les applications peuvent transmettre des données au serveur afin qu'elles soient déjà livrées dans le premier paquet TCP SYN.
La prise en charge effective de cette fonctionnalité a pris du temps et pose encore de nombreux problèmes, même aujourd'hui en 2018. Les responsables de la mise en œuvre de la stack TCP ont rencontré des problèmes, tout comme les applications qui ont essayé de tirer parti de cette fonctionnalité, en sachant dans quelle version d'OS essayer pour l'activer mais également pour savoir comment revenir en arrière avec élégance et régler les problèmes qui surviennent. Plusieurs réseaux ont été identifiés pour interférer avec le trafic TFO et ont donc activement ruiné de telles handshakes TCP.
Internet est un réseau de réseaux. Il y a des équipements installés sur Internet dans de nombreux endroits pour assurer le fonctionnement de ce réseau de réseaux. Ces périphériques, les boîtiers distribués sur le réseau, sont ce que nous appelons parfois des boîtiers centraux. Les zones situées quelque part entre les points terminaisons sont l'une des deux parties principales impliquées dans un transfert de données réseau traditionnel.
Ces boîtes servent à de nombreuses fins spécifiques, mais je pense que nous pouvons dire qu'universellement, elles sont placées là parce que quelqu'un pense qu'elles doivent être là pour que les choses fonctionnent.
Les boîtiers centraux routent les paquets IP entre les réseaux, bloquent le trafic malveillant, effectuent la traduction d'adresses réseau (en anglais Network Address Translation (NAT)), améliorent les performances, tentent parfois d'espionner le trafic en passant, etc...
Afin de s'acquitter de leurs tâches, ces boîtiers doivent connaître la mise en réseau et les protocoles qu'ils surveillent ou modifient. Ils exécutent des logiciels à cette fin. Logiciels qui ne sont pas toujours mis à jour fréquemment.
Bien qu'ils soient des composants essentiels qui maintiennent Internet attaché, ils ne sont pas souvent en phase avec les dernières technologies. Le milieu du réseau ne se déplace généralement pas aussi vite que les bords, comme les clients et les serveurs du monde.
Tous les protocoles de réseau que ces boîtes pourraient vouloir inspecter et qui ont des idées sur ce qui est ok et ce qui ne l'est pas alors ont ce problème: ces boîtes ont été déployées il y a quelque temps, alors que les protocoles avaient un ensemble de fonctionnalités de cette époque. L'introduction de nouvelles fonctionnalités ou de changements de comportement inconnus auparavant risquerait d'être considérée comme mauvaise ou illégale par de telles boîtes. Ce trafic peut tout simplement être supprimé ou retardé dans la mesure où les utilisateurs ne souhaitent vraiment pas utiliser ces fonctionnalités.
C'est ce qu'on appelle "l'ossification du protocole".
Les modifications apportées au protocole TCP souffrent également d’ossification: certaines boîtes entre un client et le serveur distant détectent de nouvelles options TCP inconnues et bloquent ces connexions car ils ne savent pas quelles sont les options. S'ils sont autorisés à détecter les détails de protocole, les systèmes apprennent le comportement typique des protocoles et, avec le temps, il devient impossible de les modifier.
Le seul moyen véritablement efficace de "combattre" l'ossification consiste à chiffrer le plus possible la communication afin d'empêcher les boîtes moyennes de voir beaucoup du protocole la traversant.
HTTP/2 est réalisé sur TCP et avec beaucoup moins de connexions TCP que lors de l'utilisation de versions HTTP antérieures. TCP est un protocole pour des transferts fiables et vous pouvez le considérer comme une chaîne imaginaire entre deux machines. Ce qui est mis sur le réseau d'un côté finira par se retrouver à l'autre bout, dans le même ordre - à terme. (Ou la connexion est rompue.)
Avec HTTP/2, les navigateurs classiques effectuent des dizaines, voire des centaines de transferts parallèles sur cette seule connexion TCP.
Si un seul paquet est abandonné ou perdu sur le réseau quelque part entre deux terminaisons qui parlent HTTP/2, cela signifie que toute la connexion TCP est interrompue et que le paquet perdu doit être retransmis et doit retrouver son chemin jusqu'à la destination. Puisque TCP est cette "chaîne", cela signifie que si un lien manque soudainement, tout ce qui viendrait après le lien perdu doit attendre.
Illustration utilisant la métaphore de la chaîne lors de l'envoi de deux flux sur cette connexion. Un flux rouge et un flux vert:
Cela devient un bloc de début de ligne basé sur TCP!
À mesure que le taux de perte de paquets augmente, HTTP/2 est de moins en moins performant. Avec 2% de perte de paquets (ce qui est une qualité de réseau épouvantable, remarquez-vous bien), des tests ont montré que les utilisateurs de HTTP/1 sont généralement mieux lotis - car ils disposent généralement de six connexions TCP pour répartir le paquet perdu donc pour chaque paquet perdu, les autres connexions sans perte peuvent toujours continuer.
Résoudre ce problème n’est pas facile, et si tout de même possible, à faire avec TCP.
Avec QUIC, il existe toujours une connexion configurée entre les deux terminaisons qui sécurise la connexion et la livraison des données.
Lors de la configuration de deux flux différents sur cette connexion, ils sont traités indépendamment. Ainsi, si un lien manque à l'un des flux, seul ce flux, cette chaîne particulière, doit s'interrompre et attend que le lien manquant soit retransmis.
Illustré ici avec un flux jaune et un flux bleu envoyés entre deux terminaisons.
La spécification HTTP/2 RFC 7540 a été publiée en mai 2015 et le protocole a depuis été mis en œuvre et déployé largement sur Internet et sur le World Wide Web.
Début 2018, près de 40% des 1 000 meilleurs sites Web utilisaient HTTP/2, environ 70% de toutes les demandes HTTPS de Firefox recevaient des réponses HTTP/2 et tous les principaux navigateurs, serveurs et proxies le prenaient en charge.
HTTP/2 corrige toute une série de lacunes presentes dans HTTP/1 et avec l'introduction de la deuxième version de HTTP, les utilisateurs peuvent cesser d'utiliser toute une série de solutions de contournement. Certaines sont assez pénibles pour les développeurs Web.
L'une des principales caractéristiques de HTTP/2 est qu'il utilise le multiplexage, de sorte que de nombreux flux logiques soient envoyés sur la même connexion TCP physique. Cela rend beaucoup de choses meilleures et plus rapides. Le contrôle de congestion fonctionne bien mieux, il permet aux utilisateurs d’utiliser bien mieux le protocole TCP et ainsi de saturer correctement la bande passante, de rendre les connexions TCP plus durables - ce qui est bien pour qu’ils atteignent la vitesse maximale plus souvent qu’avant. La compression d'en-tête lui fait utiliser moins de bande passante.
Avec HTTP/2, les navigateurs utilisent généralement une connexion TCP avec chaque hôte au lieu des précédents six. En fait, les techniques de fusion et de "désarchivage" des connexions utilisées avec HTTP/2 peuvent même réduire beaucoup plus que ça le nombre de connexions.
HTTP/2 a corrigé le problème de blocage de tête de ligne HTTP, dans lequel les clients devaient attendre la fin de la première requête en ligne avant que la suivante ne puisse être envoyée.
