HTTP/3 : le passé, le présent et l'avenir

Au cours de la Semaine d'anniversaire l’an passé nous avons annoncé la prise en charge préliminaire de QUIC et HTTP/3 (ou « HTTP-over-QUIC », comme on l'appelait depuis un certain temps), la nouvelle norme pour le Web, permettant des connexions plus rapides, plus fiables et plus sécurisées aux points de terminaison Web comme sites les Web et les API. Nous avons également permis à nos clients de s’inscrire sur une liste d'attente pour essayer QUIC et HTTP/3 dès lors qu’ils seraient disponibles.

Depuis lors, nous avons travaillé avec des entreprises du secteur à travers l’Internet Engineering Task Force (IETF), dont Google Chrome et Mozilla Firefox, pour travailler les documents des normes HTTP/3 et QUIC. Parallèlement à l’affinage des normes, nous avons également travaillé à améliorer la prise en charge sur notre réseau.

Nous sommes aujourd’hui heureux d'annoncer que la prise en charge QUIC et HTTP/3 est disponible sur le réseau périphérique Cloudflare. Nous sommes ravis que Google Chrome et Mozilla Firefox, deux des principaux fournisseurs de navigateur et partenaires dans notre effort pour rendre le Web plus rapide et plus fiable, se joignent à cette annonce.

Selon Ryan Hamilton, ingénieur logiciel chez Google, « HTTP/3 devrait améliorer le Web pour tout le monde. Les équipes de Chrome et Cloudflare ont travaillé en étroite collaboration pour faire passer HTTP/3 et QUIC de normes naissantes à des technologies largement adoptées pour améliorer le Web. C’est ce partenariat fort entre les leaders du secteur qui rend possibles les innovations en matière de normes Internet, et nous nous réjouissons de la perspective de poursuivre notre collaboration. ».

Qu'est-ce que cela signifie pour vous, client Cloudflare qui utilisez nos services notre réseau périphérique pour rendre votre présence sur le Web plus rapide et plus sécurisée ? Une fois que la prise en charge HTTP/3 est activée pour votre domaine dans le tableau de bord Cloudflare, vos clients peuvent interagir avec vos sites Web et les API en utilisant HTTP/3. Nous avons en permanence invité nos clients sur la liste d'attente HTTP/3 à activer la fonctionnalité (gardez un œil sur votre messagerie, vous pourriez recevoir un email de notre part), et dans les prochaines semaines, nous allons rendre la fonctionnalité accessible à tous.

Que signifie cette annonce si vous êtes un utilisateur Internet interagissant avec des sites et des API via un navigateur et d'autres clients ? À partir d'aujourd'hui, vous pouvez utiliser Chrome Canary pour interagir avec Cloudflare et d'autres serveurs utilisant le protocole HTTP/3. Pour ceux d'entre vous à la recherche d'un client de ligne de commande, curl fournit également un soutien pour HTTP /3. Les instructions pour l'utilisation de Chrome et curl avec HTTP/3 viendront plus tard dans ce post.

Historiquement, l'innovation des normes sur Internet est un peu comme le paradoxe de l’oeuf et de la poule : qu’est ce qui doit venir en premier ? La prise en charge par le serveur (comme Cloudflare, ou d'autres grandes sources de données de réponse) ou le soutien aux clients (comme les navigateurs, les systèmes d'exploitation, etc.) ? Les deux côtés d'une connexion doivent prendre en charge un nouveau protocole de communication pour qu’il puisse servir à tout.

Cloudflare a une longue histoire dans le pilotage de la normalisation du Web, depuis HTTP/2 (la version de HTTP qui a précédé HTTP/3), à TLS 1.3, en passant par leSNI chiffré. Nous avons fait progresser les normes en nous associant à des entreprises qui partagent à la fois nos idées et qui veulent contribuer à bâtir un Internet meilleur. Nos efforts pour que HTTP/3 devienne la norme de référence ne sont pas différents.

Tout au long du processus d'élaboration des normes HTTP/3, nous avons travaillé en étroite collaboration avec des partenaires du secteur pour construire et valider la prise en charge HTTP/3 du client compatible avec la prise en charge de notre réseau périphérique. Nous sommes ravis d'être rejoints par Google Chrome et curl, qui peuvent tous deux être utilisés aujourd'hui pour faire des requêtes HTTP/3 au réseau périphérique Cloudflare. Mozilla Firefox devrait également bientôt sortir une prise en charge dans une version nocturne.

Pour dire les choses simplement : aujourd'hui est un grand jour pour les utilisateurs d'Internet ; le déploiement généralisé de HTTP/3 signifiera une expérience Web plus rapide pour tous, et la prise en charge aujourd'hui est un grand pas vers cet objectif.

Tout simplement, aujourd'hui est un grand jour pour Internet : Chrome, curl, Cloudflare et bientôt Mozilla qui déploient tour à tour une prise en charge expérimentale mais fonctionnelle de HTTP/3 montre que le processus de création de normes Internet fonctionne. Coordonné par l’Internet Engineering Task Force, les partenaires, les concurrents et d'autres intervenants-clés du secteur peuvent se réunir pour élaborer des normes qui profitent à l'ensemble d’Internet, et pas seulement aux géants.

Eric Rescorla, CTO chez Firefox, l'a bien résumé en ces termes : « L'élaboration d'un nouveau protocole réseau est difficile, et pour qu'il soit efficace, il faut que tout le monde travaille ensemble. Au cours des dernières années, nous avons travaillé avec Cloudflare et d'autres partenaires du secteur pour tester TLS 1.3 et maintenant HTTP/3 et QUIC. La prise en charge de ces protocoles côté serveur de Cloudflare nous a aidés à résoudre les failles d'interopérabilité de l’implémentation Firefox côté client. Nous sommes impatients de faire progresser ensemble la sécurité et la performance d'Internet. ».

Avant de nous plonger un peu dans HTTP/3, jetons un coup d’œil rapide à l’évolution d’HTTP au fil des ans , pour mieux comprendre pourquoi HTTP/3 est nécessaire.

Tout a commencé en 1996 avec la publication de laspécification HTTP/1.0 qui a défini le format de câble textuel HTTP de base tel que nous le connaissons aujourd'hui (pour ce post, je ferai comme si HTTP/0.9 n’avait pas existé). En HTTP/1.0, une nouvelle connexion TCP est créée pour chaque échange requête/réponse entre les clients et les serveurs, ce qui signifie que toutes les requêtes encourent une pénalité de latence à mesure que les handshakes TCP et TLS sont réalisés avant chaque requête.

Pire encore, plutôt que d'envoyer toutes les données en suspens aussi vite que possible une fois que la connexion est établie, TCP applique une période d’« échauffement » appelée slow start (démarrage lent), qui permet à l'algorithme de contrôle de congestion de TCP de déterminer la quantité de données qui peuvent être envoyées à un moment donné avant que ne se produise une congestion du chemin réseau, et éviter ainsi d'inonder le réseau avec des paquets qu'il ne peut pas gérer. Mais comme les nouvelles connexions doivent passer par le processus de démarrage lent, elles ne peuvent pas utiliser immédiatement toute la bande passante réseau disponible.

La révision HTTP/1.1 de la spécification HTTP a tenté de résoudre ces problèmes quelques années plus tard. Elle introduisait le concept de connexions persistantes (par l'emploi de l'en-tête Connection: « Keep-Alive »), permettant aux clients de réutiliser les connexions TCP et, ainsi, d'amortir le coût de l'établissement de la connexion initiale et le démarrage lent sur plusieurs requêtes. Mais ce n'était pas une solution miracle : alors que plusieurs requêtes pouvaient partager la même connexion, elles devaient tout de même être sérialisées l'une après l'autre, de sorte qu'un client et un serveur ne pouvaient exécuter qu'un seul échange requête/réponse à un moment donné pour chaque connexion.

Alors que le Web évoluait, les navigateurs avaient de plus en plus besoin de simultanéité lorsqu'ils récupéraient et affichaient des pages Web en raison de l’augmentation du nombre de ressources (CSS, JavaScript, images, etc.) requis par chaque site Web au fil des années. Mais puisque HTTP/1.1 ne permettait aux clients de faire qu'un seul échange requête/réponse HTTP à la fois, la seule façon d'obtenir la simultanéité au niveau de la couche réseau était d'utiliser plusieurs connexions TCP de même origine en parallèle, en perdant ainsi la plupart des avantages apportés par les connexions persistantes. Alors que les connexions seraient encore réutilisées dans une certaine mesure (mais moindre), nous étions de retour à la case départ.

Enfin, plus d'une décennie plus tard, SPDY, puis HTTP/2 sont arrivés et introduit entre autres le concept de « flux » HTTP : une abstraction qui permet aux implémentations HTTP de multiplexer simultanément différents échanges HTTP sur la même connexion TCP, en permettant ainsi aux navigateurs de réutiliser plus efficacement les connexions TCP.

Mais, encore une fois, ce n'était pas une solution miracle ! HTTP/2 résout le problème d'origine (utilisation inefficace d'une seule connexion TCP) puisque plusieurs requêtes/réponses peuvent maintenant être transmises sur la même connexion en même temps. Cependant, toutes les requêtes et réponses sont également affectées par la perte de paquets (par exemple, en raison de la congestion du réseau), même si les données perdues ne concernent qu'une seule requête. En effet, tandis que la couche HTTP/2 peut séparer différents échanges HTTP sur des flux distincts, TCP n'a aucune connaissance de cette abstraction, et tout ce qu'il voit est un flux d'octets sans signification particulière.

Le rôle de TCP est de livrer l'ensemble du flux d'octets, dans le bon ordre, d'un point de terminaison à l'autre. Lorsqu'un paquet TCP transportant certains de ces octets est perdu sur le chemin réseau, il crée un vide dans le flux et TCP doit le remplir en renvoyant le paquet affecté lorsque la perte est détectée. Ce faisant, les octets livrés avec succès qui suivent les octets perdus ne peuvent être livrés à l'application, même s'ils n'ont pas été eux-mêmes perdus et appartiennent à une requête HTTP totalement indépendante. Ils finissent donc par être inutilement retardés, car TCP ne peut pas savoir si l'application est en mesure de les traiter sans les bits manquants ou non. Ce problème est connu sous le nom de « blocage de la tête de ligne » (blocage HOL).

C'est là qu’HTTP/3 entre en jeu : au lieu d'utiliser TCP comme couche de transport pour la session, il utilise QUIC, un nouveau protocole de transport Internet qui met avant tout l’accent sur les flux au niveau de la couche de transport. Les flux QUIC partagent la même connexion QUIC, de sorte que qu’aucun handshake et démarrage lent supplémentaire n’est nécessaire pour en créer de nouveaux. Les flux QUIC sont en fait livrés indépendamment de telle sorte que, dans la plupart des cas, la perte de paquets affectant un flux n'affecte pas les autres. Cela est possible parce que les paquets QUIC sont encapsulés au sommet des datagrammes UDP.

L'utilisation d'UDP apporte beaucoup plus de flexibilité que TCP et permet aux implémentations QUIC de vivre pleinement dans l'espace utilisateur. Les mises à jour des implémentations du protocole ne sont pas liées aux mises à jour des systèmes d'exploitation comme c'est le cas avec TCP. Avec QUIC, les flux de niveau HTTP peuvent simplement être mappés au sommet des flux QUIC pour bénéficier de tous les avantages de HTTP/2 sans le blocage HOL.

QUIC combine également le three-way handshake TCP typique avec le handshake TLS 1.3. La combinaison de ces étapes signifie que le chiffrement et l'authentification sont fournis par défaut en permettant également un établissement plus rapide des connexions. En d'autres termes, même lorsqu'une nouvelle connexion QUIC est requise pour la requête initiale dans une session HTTP, la latence encourue avant que les données commencent à circuler est inférieure à celle de TCP avec TLS.

Mais pourquoi ne pas simplement utiliser HTTP/2 au sommet de QUIC, au lieu de créer une toute nouvelle révision de HTTP ? Après tout, HTTP/2 offre également la fonction de multiplexage de flux. En fait, les choses sont un peu plus compliquées qu’il n’y paraît.

S'il est vrai que certaines des fonctionnalités HTTP/2 peuvent être mappées très facilement au sommet de QUIC, ce n'est pas vrai pour toutes. L'une en particulier, le protocole de compression d’en-tête de HTTP/2 appelé HPACK, dépend grandement de l'ordre dans lequel différentes requêtes et réponses HTTP sont livrées aux points de terminaison. QUIC applique l'ordre de livraison des octets dans les flux uniques, mais ne garantit pas le classement entre les différents flux.

Ce comportement a nécessité la création d'un nouveau protocole de compression d’en-tête HTTP, appelé QPACK, qui résout le problème, mais qui nécessite toutefois d’apporter des modifications au mappage HTTP. En outre, certaines des fonctionnalités offertes par HTTP/2 (comme le contrôle du débit par flux) sont déjà offertes par QUIC, de sorte qu'elles ont été retirées de HTTP/3 afin de rendre le protocole moins complexe.

QUIC et HTTP/3 sont des normes passionnantes qui promettent de combler bon nombre des lacunes des normes précédentes et inaugurent une nouvelle ère de performance sur le web. Alors, comment passer de documents de normes passionnantes à la mise en œuvre effective ?

La prise en charge QUIC et HTTP/3 de Cloudflare est optimisée par quiche, notre propre implémentation open-source écrite en Rust.

Vous pouvez la trouver sur GitHub à l’adresse github.com/cloudflare/quiche.

Nous avons annoncé quiche il y a quelques mois et, depuis lors, nous avons ajouté la prise en charge du protocole HTTP/3, au sommet de la prise en charge QUIC existante. Nous avons conçu quiche de manière à qu’il soit maintenant utilisé pour implémenter des clients et des serveurs HTTP/3 ou simplement des clients et serveurs QUIC.

Comme nous l’avons mentionné précédemment, nous avons commencé à intégrer les clients inscrits sur la liste d'attente. Si vous êtes sur la liste d'attente et que vous avez reçu un email de notre part vous indiquant que vous pouvez maintenant activer la fonctionnalité pour vos sites Web, il vous suffit simplement d’aller sur le tableau de bord Cloudflare et de basculer le commutateur de l'onglet « Réseau » manuellement :

Nous prévoyons de rendre la fonctionnalité HTTP/3 accessible à tous nos clients dans un avenir proche.

Une fois activé, vous pouvez expérimenter HTTP/3 de plusieurs façons :

Pour utiliser le navigateur Chrome pour vous connecter à votre site Web en utilisant le protocole HTTP/3, vous devez d'abord télécharger et installer la dernière version Canary. Ensuite, tout ce que vous devez faire pour démarrer la prise en charge de HTTP/3 est de lancer Chrome Canary avec les arguments de ligne de commande« --enable-quic » et « --quic-version=h3-23 ».

Une fois que Chrome est lancé avec les arguments requis, vous pouvez simplement taper votre domaine dans la barre d'adresse et le voir chargé en HTTP/3 (vous pouvez utiliser l'onglet Réseau dans les outils de développement de Chrome pour vérifier la version de protocole qui a été utilisée). Notez qu'en raison de la façon dont HTTP/3 est négocié entre le navigateur et le serveur, HTTP/3 peut ne pas être utilisé pour les premières connexions au domaine, vous devrez par conséquent essayer de recharger la page à plusieurs reprises.

Si cela semble trop compliqué, ne vous inquiétez pas : la prise en charge de HTTP/3 dans Chrome deviendra plus stable avec le temps, permettant à HTTP/3 de devenir plus facile.

Voici ce que l'onglet Réseau dans les outils de développement affiche lorsque vous naviguez sur ce blog en HTTP/3 :

Notez qu'en raison de la nature expérimentale de la prise en charge HTTP/3 dans Chrome, le protocole est en fait identifié comme « http2+quic/99 » dans les outils de développement, mais ne vous y trompez pas, il s’agit bien de HTTP/3.

L'outil de ligne de commande de curl prend également en charge HTTP/3 comme fonctionnalité expérimentale. Vous devrez télécharger la dernière version à partir de git et suivre les instructions sur la façon d'activer la prise en charge de HTTP/3.

Si vous utilisez macOS, nous avons également facilité l’installation d’une version d’HTTP/3 équipée de curl via Homebrew :

Pour effectuer une requête HTTP/3 tout ce dont vous avez besoin est d'ajouter l’indicateur de ligne de commande « --http3 » à une commande curl normale :

 % brew install --HEAD -s https://raw.githubusercontent.com/cloudflare/homebrew-cloudflare/master/curl.rb

 % ./curl -I https://blog.cloudflare.com/ --http3
HTTP/3 200
date: Tue, 17 Sep 2019 12:27:07 GMT
content-type: text/html; charset=utf-8
set-cookie: __cfduid=d3fc7b95edd40bc69c7d894d296564df31568723227; expires=Wed, 16-Sep-20 12:27:07 GMT; path=/; domain=.blog.cloudflare.com; HttpOnly; Secure
x-powered-by: Express
cache-control: public, max-age=60
vary: Accept-Encoding
cf-cache-status: HIT
age: 57
expires: Tue, 17 Sep 2019 12:28:07 GMT
alt-svc: h3-23=":443"; ma=86400
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 517b128df871bfe3-MAN

Enfin, nous fournissons également un exemple client en ligne de commande HTTP/3 (ainsi qu'un serveur en ligne de commande) construit au sommet de quiche, que vous pouvez utiliser pour expérimenter HTTP/3.

Pour le faire fonctionner, clonez tout d’abord le référentiel GitHub de quiche :

Puis, construisez-le. Vous avez besoin d'une installation Rust et Cargo opérationnelle pour que cela fonctionne (nous vous recommandons d'utiliser rustup pour configurer facilement un environnement de développement de travail Rust).

$ git clone --recursive https://github.com/cloudflare/quiche

$ cargo build --examples

$ cargo build --examples

Enfin, vous pouvez exécuter une requête HTTP/3 :

$ RUST_LOG=info target/debug/examples/http3-client https://blog.cloudflare.com/

Au cours des prochains mois, nous travaillerons à améliorer et optimiser notre implémentation de QUIC et HTTP/3, et nous permettrons effectivement à chacun d'activer cette nouvelle fonctionnalité sans avoir à passer par une liste d'attente. Nous continuerons à mettre à jour notre implémentation à mesure que les normes évoluent, ce qui pourrait entraîner des changements entre les versions préliminaires des normes.

Voici quelques nouveautés sur notre feuille de route qui nous enthousiasment particulièrement :

Une caractéristique importante permise par QUIC est la migration fluide et transparente des connexions entre les différents réseaux (tels que votre réseau WiFi domestique et le réseau mobile de votre opérateur lorsque vous partez au travail le matin) sans nécessiter la création d’une nouvelle connexion.

Cette fonctionnalité nécessitera des modifications supplémentaires de notre infrastructure, mais c'est une chose que nous serons heureux d'offrir à nos clients à l'avenir.

Tout comme TLS 1.3, QUIC prend en charge un mode d’exploitation qui permet aux clients de commencer à envoyer des requêtes HTTP avant que le handshake de connexion soit effectué. Nous ne prenons pas encore en charge cette fonctionnalité dans notre déploiement de QUIC, mais nous allons travailler pour qu’elle soit disponible, tout comme nous le faisons déjà pour notre prise en charge de TLS 1.3.

Nous sommes ravis de prendre en charge HTTP/3 et de permettre à nos clients de l'expérimenter, alors que les efforts pour normaliser QUIC et HTTP/3 sont toujours en cours. Nous continuerons de travailler en collaboration avec d'autres entreprises, dont Google et Mozilla, pour finaliser les normes QUIC et HTTP/3 et encourager une large adoption.

Voici une expérience Web plus rapide, plus fiable et plus sécurisée pour tous.