HTTP/3

Pourquoi QUIC

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?

Quelques Rappel sur le HTTP/2

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.

Blocage de tête de ligne TCP

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.

Une solution au problème: Les flux indépendants évitent le blocage

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