HTTP/3

QUIC est un acronyme qui se prononce comme le mot anglais “quick” QUIC est défini https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ celui qui pourrait être perçu comme un moyen de créer un nouveau protocole de transport fiable et sécurisé, qui pourrait s' adopté a n importe quel autre protocole comme le DNS, le HTTP. Dans le cadre de cet article, QUIC vient pour résoudre certains des inconvénients connus de HTTP/2 sur le TCP et TLS ce qui forcement une prochaine étape de l évolution de WEB. Dans le souci de rendre le web et les données en général plus rapides pour les end user est la principale raison qui à initier le développement de ce protocole.

Quel est l intérêt de se nouveau protocole et pourquoi au dessus du protocole UDP?

Définit par le RfC7540 https://tools.ietf.org/html/rfc7540 depuis mai 2015, il a été mis œuvre et déployé largement sur internet et WWW.

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 présentes 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.

le HTTP/2 présente comme caractéristique:

- le multiplexage de flux (nombreux flux logiques soient envoyés sur la même connexion TCP physique)

- Le contrôle de flux de congestion (optimiser la gestion de la bande passante et rendre durables les connexion tcp)

- la compression des entêtes

Http/2 une seule connexion tcp suffit pour établir une liaison entre le navigateur avec chaque hotes au lieu de six comme sur le protocole http/1

il corrige aussi 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.

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.)

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 “#” et un flux “@”:

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 “#” et un flux “@” envoyés entre deux terminaisons.

si nous pouvons résoudre le problème du blocage de la tête de ligne tcp, nous pouvons en théorie créer un protocole de transport parallèle a UDP et TCP dans la couche réseau, mais cela a plusieurs contrainte qui ne vont pas forcement réussir à résoudre le facteur social sur la résistance au changement et la réalité technique sur les question d acceptation, d implémentation, et migration de l ensemble des routeurs, firewalls, terminaux, ou même les noyaux des systèmes d exploitation sur cette base nous avons un taux d’échec de N%.

il existe plusieurs standard améliorer par IETF qui ne sont pas suffisamment déployés ou utilisés

Considéré comme un sécurisé QUIC n pas de version en texte clair ou du clair protocole, ainsi une négociation d “une connexion se fait par la cryptographie et la sécurité TLS1.3, justement pour empêcher l ossification ainsi que d autres types de blocages et traitements spéciaux, à coté de cela il y a quelques paquets handshakes initiaux qui sont envoyés en claire, avant que les protocoles de cryptages 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 rfc7413 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.

Le protocole QUIC originel a été conçu par Jim Roskind chez Google et a été initialement mis en œuvre en 2012, puis annoncé publiquement au monde en 2013 lorsque l'expérimentation de Google s'est élargie.

À l'époque, il était toujours prétendu que QUIC était l'acronyme de “Quick UDP Internet Connections”, mais il a été abandonné depuis.

Google a mis en œuvre le protocole et l'a ensuite déployé à la fois dans son navigateur beaucoup utilisé (Chrome) et dans ses services côté serveur beaucoup utilisés (Google search, gmail, youtube, etc…). Ils ont répété les versions du protocole assez rapidement et, avec le temps, ils ont prouvé que le concept fonctionnait de manière fiable pour une grande partie des utilisateurs.

En juin 2015, le premier brouillon Internet pour QUIC a été envoyé à l'IETF pour une standardisation, mais il a fallu attendre la fin de l'année 2016 pour qu'un groupe de travail QUIC soit approuvé et lancé. Mais ensuite, il a immédiatement décollé avec beaucoup d'intérêt de la part de nombreux partis.

En 2017, des chiffres cités par les ingénieurs de QUIC chez Google ont indiqué qu'environ 7% de tout le trafic Internet utilisait déjà ce protocole. La version de Google du protocole

Le groupe de travail QUIC mis en place pour standardiser le protocole au sein de l'IETF a rapidement décidé que le protocole QUIC devait pouvoir transférer des protocoles autres que “simplement” HTTP. Google-QUIC ne transportait jamais que HTTP - en pratique, il transportait ce qui était en réalité des trames HTTP/2, en utilisant la syntaxe HTTP/2.

Il a également été indiqué que l'IETF-QUIC devrait baser son cryptage et sa sécurité sur TLS 1.3 au lieu de l'approche”personnalisée“ utilisée par Google-QUIC.

Afin de satisfaire la demande d'envoi-plus-que-HTTP, l'architecture de protocole IETF QUIC a été scindée en deux couches distinctes: la couche de transport QUIC et la couche “HTTP sur QUIC” (cette dernière parfois appelée “hq”).

Cette division de couche, bien que cela puisse paraître inoffensif, a entraîné une grande différence entre l'IETF-QUIC etl'original de Google-QUIC.

Cependant, le groupe de travail a rapidement décidé que pour se concentrer correctement et délivrer la version 1 de QUIC à temps, il se concentrerait sur la livraison de HTTP, laissant les transports non-HTTP à un travail ultérieur.

Alors que les travaux sur l’IETF-QUIC ont progressé, l’équipe de Google a incorporé les détails de la version de l’IETF et a commencé à faire progresser lentement sa version du protocole vers ce que pourrait devenir la version de l’IETF. Google a continué d'utiliser sa version de QUIC dans son navigateur et ses services. La plupart des nouvelles implémentations en cours de développement ont décidé de se concentrer sur la version de l'IETF et ne sont pas compatibles avec la version de Google.

le RFC 7540 du protocole HTTP/2 à été publiée en Mai 2015, un mois avant que QUIC ne soit présenté pour la première fois à l IETF

Pour partir de http1 à http2 il a fallu environ 16 ans, les bases de la modification de HTTP sur le réseau ont été aménagés et le groupe de travail qui a créé HTTP/2 était déjà convaincu que cela aiderait à effectuer une itération sur de nouvelles versions HTTP plus rapidement, mais il faut note que l adoption d un protocole nécessite du temps.

Avec HTTP/2, les utilisateurs et les stacks logiciels se sont habitués à l'idée que le protocole HTTP ne peut plus être supposé être exécuté en série avec un protocole texte. HTTP-over-QUIC a été renommé HTTP/3 en novembre 2018

Le groupe de travail de QUIC a travaillé d'arrache-pied depuis fin 2016 pour spécifier les protocoles et le plan est maintenant de le faire d'ici juillet 2019.

En novembre 2018, il n'y avait toujours pas de tests d'interopérabilité plus grands avec HTTP/3 - uniquement avec les deux implémentations existantes et aucun d'entre eux n'est effectué par un navigateur ou un logiciel populaire de serveur ouvert.

Il y a une quinzaine de différentes implémentations de QUIC répertoriées dans les pages de wiki des groupes de travail de QUIC, mais toutes ne peuvent pas interagir sur les dernières revisions des spécifications.

L'implémentation de QUIC n'est pas facile et le protocole a continué à évoluer, même à cette date

Il n'y a eu aucune déclaration publique en termes de soutien à QUIC d'Apache ou de nginx.

Aucun des plus gros éditeurs de navigateurs n’a encore fourni de version, quel que soit son état, pouvant exécuter la version IETF de QUIC ou de HTTP/3.

Google Chrome est livré avec une implémentation fonctionnelle de la version QUIC de Google depuis de nombreuses années, mais cela n'interagit pas avec le protocole QUIC officiel et son implémentation HTTP est différente de HTTP/3.

QUIC a décidé d'utiliser TLS 1.3 comme base pour la couche de chiffrement et de sécurité pour éviter d'inventer quelque chose de nouveau et plutôt s'appuyer sur un protocole fiable et existant. Cependant, ce faisant, le groupe de travail a également décidé que, pour rationaliser réellement l'utilisation de TLS dans QUIC, il ne devrait utiliser que des “messages TLS” et non des “enregistrements TLS” pour le protocole.

Cela peut sembler être un changement anodin, mais cela a en fait créé un obstacle considérable pour de nombreux développeurs de stack QUIC. Les bibliothèques TLS existantes qui prennent en charge TLS 1.3 n'ont tout simplement pas assez d'API pour exposer cette fonctionnalité et permettre à QUIC d'y accéder. Bien que plusieurs développeurs QUIC proviennent de grandes organisations qui travaillent sur leur propre stack TLS en parallèle, cela n’est pas vrai pour tout le monde.

OpenSSL, le poids lourd open source dominant, par exemple, n’a pas d’API et n’a manifesté aucun désir de la fournir dans les meilleurs délais (à partir de novembre 2018).

Cela entraînera éventuellement des obstacles de déploiement puisque les stacks QUIC devront se baser sur d'autres bibliothèques TLS, utiliser une version OpenSSL corrigée ou nécessiter une mise à jour d'une version future d'OpenSSL.

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 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

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.

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é.

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

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 lesautres 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.

https://hpbn.co/http1x/

https://speeder.edm.uhasselt.be/webist/files/h2bestpractices_RobinMarx_WEBIST2017_slides.pdf

https://datatracker.ietf.org/doc/draft-ietf-quic-transport/

https://tools.ietf.org/html/rfc7540