Protocole de transfert sur UDP

QUIC est un protocole de transfert implémenté au-dessus d'UDP. Si vous surveillez votre trafic réseau par hasard, vous verrez QUIC apparaître sous forme de paquets UDP.

Basé sur UDP, il utilise également les numéros de port UDP pour identifier des serveurs spécifiques sur une machine donnée.

Toutes les implémentations QUIC connues se trouvent actuellement dans l'espace utilisateur, ce qui permet une évolution plus rapide que ne permettent généralement pas les implémentations noyau.

Est-ce que ça va fonctionner ?

Certaines entreprises et autres configurations réseau bloquent le trafic UDP sur des ports autres que 53 (utilisé pour DNS). D'autres limitent ces données de manière à rendre QUIC moins performant que les protocoles basés sur TCP. Il n'y a pas de fin à ce que certains opérateurs peuvent faire.

Dans un avenir prévisible, toute utilisation de transports basés sur QUIC devra probablement être en mesure de faire appel à une autre alternative (basée sur TCP). Les ingénieurs de Google ont précédemment mentionné les taux d'échec mesurés dans de faibles pourcentages à un chiffre.

Cela va-t-il s'améliorer ?

Il est fort probable que si QUIC s'avère être un atout précieux au monde d'Internet, les utilisateurs voudront l'utiliser et le feront fonctionner dans leurs réseaux, ce qui permettra aux entreprises de reconsidérer leurs obstacles. Au fil des années, le développement de QUIC a progressé, le taux de réussite de l’établissement et de l’utilisation de connexions QUIC sur Internet a augmenté.

QUIC offre à la fois des configurations de connexion 0-RTT et 1-RTT, ce qui signifie qu'au mieux, QUIC ne nécessitera aucun aller-retour supplémentaire lors de la configuration d'une nouvelle connexion. Le plus rapide des deux, la négociation 0-RTT, ne fonctionne que si une connexion précédente a été établie avec un hôte et qu'un secret de cette connexion a été mis en cache.

Données précoces

QUIC permet à un client d'inclure des données déjà dans le handshake 0-RTT. Cette fonctionnalité permet à un client de transmettre les données à l'homologue aussi rapidement que possible, ce qui permet bien entendu au serveur de répondre et de renvoyer les données encore plus tôt.

Semblable à SCTP, SSH et HTTP/2, QUIC propose des flux logiques séparés au sein des connexions physiques. Un certain nombre de flux parallèles pouvant transférer des données simultanément sur une seule connexion sans affecter les autres flux.

Une connexion est une configuration négociée entre deux points de terminaison, similaire au fonctionnement d'une connexion TCP. Une connexion QUIC est établie sur port UDP et une adresse IP, mais une fois établie, la connexion est associée à son "ID de connexion".

Sur une connexion établie, chaque côté peut créer des flux et envoyer des données à l'autre terminaison. Les flux sont livrés dans l'ordre et ils sont fiables, mais différents flux peuvent être livrés dans le désordre.

QUIC offre un contrôle de flux sur la connexion et les flux.

Voir plus de détails dans les sections connexion et flux

Le protocole IETF QUIC est un protocole de transport sur lequel d'autres protocoles d'application peuvent être utilisés. Le protocole de couche d'application initial est HTTP/3 (h3).

La couche de transport prend en charge les connexions et les flux.

L'ancienne version de QUIC de Google regroupait le transport et le protocole HTTP dans un même ensemble et constituait un protocole send-http/2-frames-over-udp plus spécifique.

La couche HTTP effectue des transports de style HTTP, y compris la compression d'en-tête HTTP à l'aide de QPACK - ce qui est similaire à la compression HTTP/2 appelée HPACK.

L'algorithme HPACK dépend d'une livraison ordonnée de flux, il n'a donc pas été possible de le réutiliser pour HTTP/3 sans modifications depuis que QUIC propose des flux pouvant être livrés dans le désordre. QPACK peut être considéré comme la version de HPACK adaptée à QUIC.

Bien qu'UDP ne soit pas un transport fiable, QUIC ajoute une couche au-dessus d'UDP qui introduit la fiabilité. Il offre la retransmission de paquets, le contrôle de congestion, la stimulation et les autres fonctionnalités présentes par ailleurs dans TCP.

Les données envoyées sur QUIC depuis un point de terminaison apparaîtront dans l'autre tôt ou tard, tant que la connexion est maintenue.

Les travaux d’envoi de protocoles autres que HTTP sur QUIC ont été reportés après la livraison de la version 1 de QUIC.

Le protocole QUIC d'un niveau élevé.

Illustré ci-dessous, la stack réseau HTTP/2 à gauche et la stack réseau QUIC à droite, quand utilisées comme transport HTTP.

QUIC garantit la livraison des flux dans l'ordre, mais pas entre les flux. Cela signifie que chaque flux enverra des données et maintiendra l’ordre des données, mais chaque flux pourra atteindre la destination dans un ordre différent de celui que l’application a envoyé!

Par exemple: les flux A et B sont transférés d'un serveur à un client. Le flux A est démarré en premier, puis ensuite le flux B. Dans QUIC, un paquet perdu affecte uniquement le flux auquel appartient le paquet perdu. Si le flux A perd un paquet mais pas le flux B, le flux B peut poursuivre ses transferts et se terminer pendant que le paquet perdu du flux A est retransmis. Ce n'était pas possible avec HTTP/2.

Illustré ici avec un flux jaune et un flux bleu envoyés entre deux points de terminaison QUIC sur une seule connexion. Ils sont indépendants et peuvent arriver dans un ordre différent, mais chaque flux est livré de manière fiable, dans l'ordre, à l'application.

La sécurité de transport utilisée dans QUIC utilise TLS 1.3 () et il n'y a jamais de connexions QUIC non chiffrées.

TLS 1.3 présente plusieurs avantages par rapport aux anciennes versions de TLS, mais l'une des principales raisons de son utilisation dans QUIC est que la 1.3 a modifié le handshake pour exiger moins d'allers-retours. Cela réduit la latence du protocole.

L'ancienne version de QUIC de Google utilisait une crypto personnalisée.