HTTP/3 : le protocole origine Google est dans les starting-blocks

HTTP/3 ? C’est désormais une réalité chez Cloudflare.

Après un an d’expérimentation, le groupe américain annonce que ses infrastructures prennent en charge ce protocole en cours de normalisation.

HTTP/3 arrive, en parallèle, dans Google Chrome Canary. Mozilla compte l’intégrer « bientôt » dans Firefox Nightly.

Cloudflare a codé son implémentation en Rust.
Nommée Quiche, elle permet aussi la simple mise en place de la couche de transport QUIC, sur laquelle repose HTTP/3.

QUIC (Quick UDP Internet Connections) est le fruit des travaux Google. L’Internet Engineering Task Force a entrepris d’en standardiser une version dérivée.

Sur le volet sécurité, le mécanisme de prise de contact de TCP s’associe à celui de TLS 1.3. Résultat : les connexions sont chiffrées par défaut et plus rapides (moins d’allers-retours client-serveur).

UDP : flexible… sous conditions

HTTP/3 apporte aussi une meilleure gestion des erreurs.
Son prédécesseur HTTP/2* avait introduit le principe de multiplexage des flux. Ou comment pousser plusieurs requêtes / réponses sur une même connexion TCP pour optimiser la bande passante. Problème : lorsqu’un flux subit une perte de paquets, la connexion dans son ensemble est affectée. C’est le phénomène dit de « blocage en tête de ligne ».

QUIC reprend ce multiplexage, mais au lieu de s’appuyer sur TCP, il exploite UDP. En plus de résoudre le blocage en tête de ligne, cette solution permet de redéfinir les prises de contact, la fiabilité et la sécurité dans l’espace utilisateur. Et donc de ne pas dépendre des mises à jour des firmwares et des systèmes d’exploitation.

QUIC gère par ailleurs la migration entre réseaux grâce à des identifiants de connexion qui « survivent » aux changements d’adresse IP. L’intégration de TLS 1.3 autorise en outre la transmission de requêtes avant la fin de la prise de contact.

Pourquoi ne pas avoir simplement adapté HTTP/2 à QUIC ? Certaines fonctionnalités sont difficiles à répliquer, affirme Cloudflare.
C’est le cas du système de compression HPACK. Il historise, dans des tables dynamiques, les en-têtes des requêtes et des réponses HTTP, auxquelles clients et serveurs peuvent alors se référer.

Avec HTTP/2, TCP permet d’intégrer les instructions de mise à jour des tables dans les requêtes et les réponses, dont l’acheminement se fait dans l’ordre.
QUIC, de par son architecture sur base UDP, n’offre pas cette garantie d’acheminement ordonné entre plusieurs flux. Ainsi a-t-il fallu développer un « HPACK bis » : QPACK, qui élimine cet écueil tout en évitant le blocage en tête de ligne. L’idée générale : un client ne peut se référer à une table qu’après y avoir été autorisé par le serveur.

* Moins de la moitié des sites web (41 %) utilisent HTTP/2, d’après les dernières statistiques de W3Techs.

Photo d’illustration © AFANASEV IVAN – Shutterstock.com