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 Fiable et sécurisé, qui pourrait etre adopté a n importe quel autre protocole comme le DNS, le HTTP, dans le cadre de cet article il 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.

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