QUIC

QUIC est un ce protocole via de la couche transport initié par Jim Roskind chez Google. Il est repris par l'IETF en 2015 dans le but de le normaliser par les RFC 8999, 9000, 9001 et 9002 et le rendre ainsi utilisable par n'importe quel protocole de la couche application. Les acteurs impliqués veulent que QUIC soit plus que « HTTP sur UDP », là où Google désire prioriser le web. Initialement QUIC signifie « Quick UDP Internet Connections », mais l'IETF ne le considère pas comme un acronyme et il n'y en a aucune trace dans les RFC. Le protocole est destiné à remplacer TCP (HTTP/3) dont il reprend la plus grande partie des fonctionnalités comme la réémission des paquets perdus et le contrôle de congestion, ce qui lui vaut le surnom de TCP/2. QUIC ajoute de nouvelles fonctionnalités telles qu'une réémission des paquets perdus non bloquante, une gestion de la couche transport par l'application et non par le noyau, un chiffrement TLS complet obligatoire alors qu'il est optionnel avec TCP. Cet ajout du protocole TLS au sein de QUIC permet également un handshake TLS plus rapide avec trois messages contre six pour TCP. Par construction, il lutte également contre l'ossification. QUIC est encapsulé dans UDP afin de pouvoir passer les équipements intermédiaires qui n'autorisent que le trafic connu comme TCP ou UDP. Un flux de données dans le protocole QUIC est une liste ordonnée d'octets. Un flux est créé au sein d'une connexion et est identifié par un stream ID mais chaque flux est indépendant et peut échanger des données en concurrence des autres. Contrairement au protocole TCP qui assure l'ordre d'arrivée des paquets pour la connexion entière, les flux QUIC ne dépendent pas de la bonne transmission des autres flux. Un flux peut être unidirectionnel ou bidirectionnel. Dans un flux unidirectionnel, seul le créateur peut envoyer des données et le receveur renvoie des acquittements et des messages d'erreur. Le flux fragmenté dans des paquets UDP est reconstitué dans l'ordre grâce à un offset.