Qu’est-ce que HTTP/3 – Informations sur le nouveau protocole UDP rapide ?

TL;DR

In November 2018, the Internet Engineering Task Force (IETF) met in Bangkok and a new Internet project was adopted. The QUIC transport protocol, the successor to HTTP/2 , has been renamed to HTTP/3.

HTTP/3 relies on UDP and is already used by major Internet companies such as Google and Facebook. If you’re using Chrome and connecting to a Google service, you’re probably already using QUIC.

The new version of the HTTP protocol takes advantage of the bare-metal, low-level UDP protocol, and defines many of the new features that were in previous versions of the HTTP protocol on the TCP layer. This solves the constraints within the existing Internet infrastructure.

Early results are promising, and when the IETF Internet Draft expires in August 2021, we can expect HTTP/3 to be introduced as a new third-generation HTTP standard.

[shareable-quote tweet= »Just like with HTTP/2, HTTP/3 will again build on these achievements to help speed up the web. 🚀 » user= »Kinsta_FR » hashtags= »HTTP3,webperf »]

Progress of HTTP/3 in 2024

Some say the web industry’s thirst for speed and latency is matched only by Google Chrome’s thirst for more RAM.

A few years ago, we published an article on HTTP/2 , a standard which, according to W3Techs , has now achieved a global adoption rate of around 45%. And according to Can I Use , it’s also supported by all modern web browsers. However, here we are writing an article about the next version of the protocol, HTTP/3.

HTTP/3 is, at the time of this writing, an Internet-Draft or IETF ID , which means it is currently under consideration for a future Internet standard by the Internet Engineering Task Force – an international Internet standards body , responsible for defining and promoting approved Internet protocol standards, such as TCP, IPv6 , VoIP, Internet of Things, etc.

It is an open body that brings together the web industry and facilitates discussions on the direction of the Internet. Currently, the « Internet Draft » phase of HTTP/3 is the last phase before proposals are promoted to the Request-for-Comments ( RFC ) level, which we can consider, for all intents and purposes, as official definitions of the Internet protocol.

Although HTTP/3 is not yet an official Internet protocol, many companies and projects have already started adding support for HTTP/3 in their products.

HTTP/3 support by web browsers

As for web browsers , Chrome v87, Firefox v88, and Edge v87 all have HTTP/3 enabled by default. For Safari users, the option to enable HTTP/3 was added in Safari Technology Preview v104. However, HTTP/3 support is not yet available in the stable version of Safari.

Library support for HTTP/3

For developers looking to leverage HTTP/3 technologies, many popular libraries have already added support for HTTP/3. Since HTTP/3 is still in the Internet Draft stage, you should make sure you are aware of the latest updates when working with any of the libraries below.

• Python – http3 and aioquic
• Rust – quiche , neqo , and quinn
• C – nghttp3 and lsquic
• Go – quicgo
• JavaScript- Node.js

Framework support for HTTP/3

On the infrastructure side, Cloudflare led the way by supporting HTTP/3 across its entire edge network. This means sites with Cloudflare enabled can take advantage of the security and performance improvements of HTTP/3 without any additional work.

Chez Kinsta, tous les sites que nous hébergeons sont protégés par notre intégration gratuite de Cloudflare. En plus d’un pare-feu de niveau entreprise et d’une protection DDoS, les clients de Kinsta ont également accès à HTTP/3 !

Pour tester si votre site prend en charge HTTP/3, vous pouvez utiliser l’outil de test HTTP/3 de Geekflare. Il suffit de saisir votre domaine et de cliquer sur le bouton « Check HTTP/3 », et l’outil vous fera savoir si votre site est compatible avec HTTP/3.

Si votre site prend en charge HTTP/3, vous devriez voir un message comme celui ci-dessous. Comme kinstalife.com est hébergé sur Kinsta, HTTP/3 est entièrement pris en charge grâce à notre intégration Cloudflare.

Vous pouvez également utiliser l’inspecteur de votre navigateur pour vérifier la prise en charge de HTTP/3. Pour cet exemple, nous utiliserons la dernière version de Google Chrome qui prend en charge HTTP/3.

Pour ouvrir l’inspecteur, faites un clic droit sur la page et cliquez sur « Inspecter », puis accédez à l’onglet « Réseau ». Dans la colonne « Protocole », vous pouvez voir le protocole HTTP utilisé pour la connexion. Les connexions HTTP/2 apparaissent sous la forme « h2 », tandis que les connexions HTTP/3 apparaissent sous la forme « h3-XX » (XX fait référence à un projet HTTP/3 spécifique). Comme vous pouvez le voir dans l’image ci-dessous, kinstalife.com prend en charge les connexions sur « h3-29 », ce qui signifie « HTTP/3 Draft 29 ».

Maintenant que nous avons passé en revue l’état actuel de HTTP/3, plongeons dans les différences entre HTTP/2 et HTTP/3 !

Retour en arrière – Ça a commencé avec HTTP/2

HTTP/2 a apporté de sérieuses améliorations avec des téléchargements non bloquants, des pipelines et les serveurs push qui nous ont aidé à surmonter certaines limitations du protocole TCP sous-jacent. Cela nous a permis de réduire au minimum le nombre de cycles de requêtes-réponses.

HTTP/2 permettait de pousser plus d’une ressource dans une seule connexion TCP – le multiplexage. Nous avons également obtenu plus de flexibilité dans l’ordre des téléchargements statiques, et nos pages ne sont maintenant plus limitées par une progression linéaire des téléchargements.

En pratique, cela signifie qu’une ressource javascript importante n’équivaut pas nécessairement à un point d’étranglement pour toutes les autres ressources statiques qui attendent leur tour.

Ajoutez à cela la compression HPACK de l’en-tête HTTP/2 et le format binaire par défaut du transfert de données, et nous avons, dans de nombreux cas, un protocole beaucoup plus efficace.

Major browser implementations made it necessary to implement encryption – SSL – in order to take advantage of the benefits of HTTP/2 – and sometimes this resulted in a computational overhead that made the speed improvements unnoticeable. There have even been instances where users have reported a slowdown after transitioning to HTTP/2.

Let’s just say that the early days of adopting this build weren’t for the faint of heart.

The Nginx implementation also lacked the server push feature, relying on a module. And Nginx modules aren’t the usual Apache modules you can just copy – NGINX needs to be recompiled with those.

Although some of these issues are now resolved, if we look at the entire protocol stack, we see that the main constraint is at a lower level than HTTP/2 dared to attempt.

To elaborate on this, we will dissect today’s Internet Protocol stack from its bottom layer upwards. If you want to know more about the background of HTTP/2, feel free to check out our ultimate HTTP/2 guide .

Internet Protocol (IP)

The Internet Protocol (IP) defines the bottom part of the entire Internet topology. It’s the part of the internet stack that is, we can say, really non-negotiable without changing everything, including replacing all of the hardware infrastructure, from routers to servers and even end-user machines.

So, while protocol review may be due, such a massive undertaking isn’t on the horizon at this time, primarily because we haven’t yet found a viable, game-changing alternative. , but consistent with the past.

The beginnings of the IP protocol date back to 1974, with a paper published by the Institute of Electrical and Electronics Engineers and authored by Vint Cerf and Bob Cahn. It details packets sent over a network, routes them through IP addresses and defined numeric addresses of nodes in a network/networks. The protocol defined the format of these packets, or datagrams – its headers and its payload.

After the definition in RFC 760 of 1980, the IETF adopted the definition widely used to this day, in its Request for Comments 791 . This is the fourth version of the protocol, but we can say that it is the first version in production.

It uses 32-bit addresses, which limits the number of addresses to around 4 billion. This limitation explains the mystery of why non-professional Internet users obtain « dynamic IP addresses » from their ISP, and a static IP is considered « added value » and often subject to additional charges.

They are rationing.

It didn’t take long before it was realized that 32-bit addresses were not enough and the shortage was imminent, so many RFCs were published in an attempt to remedy this. Although these solutions are widely used today and are part of our daily lives, it is probably safe to say that they are very popular.

Internet Protocol version 6 or IPv6 came as a way to address these limitations, including being gradually adopted over the previous version. It became a draft standard for the IETF in 1998 and was elevated to an Internet standard in 2017.

While the IPv4 address space was limited by its 32-bit address length, the IPv6 standard was 128 bits, or 3.4*10^38 possible addresses. That should be enough to last us a while.

According to Google and IPv6 connectivity among its users, IPv6 adoption is just over 35% as of June 2021.

L’IP est une couche rudimentaire de la pile Internet, définissant la plupart des choses de base, sans garantie de livraison, d’intégrité des données, ou de commande des paquets transmis. À lui seul, il n’est pas fiable. Le format d’en-tête d’IPv4 fournit la somme de contrôle d’en-tête que les nœuds de transmission utilisent pour vérifier l’intégrité de l’en-tête. Cela le rend différent de la version IPv6, qui s’appuie sur la couche de liaison en dessous, ce qui lui permet d’être plus rapide.

Comprendre le rôle du TCP et UDP

Maintenant, il est temps d’explorer où HTTP/3 s’intègre avec TCP et UDP.

TCP

Alors que l’IP est la couche sous-jacente de toutes nos communications en ligne aujourd’hui, le TCP (Transmission Control Protocol) est une partie de plus haut niveau de la suite de protocoles Internet, fournissant la fiabilité nécessaire pour le Web, le courrier, le transfert de fichiers (FTP) – pour les couches d’applications/protocoles de l’Internet.

Cela comprend l’établissement d’une connexion à plusieurs étapes, l’ordre assuré des paquets et la retransmission des paquets perdus. Il fournit un feedback (Acks) de la livraison à l’expéditeur et ainsi de suite. Il y a aussi le calcul de la somme de contrôle pour détecter les erreurs.

Toutes ces choses indiquent un grand nombre d’étapes qui font de TCP un protocole fiable, ce qui en fait le fondement des services Internet les plus célèbres que nous utilisons aujourd’hui.

Ses spécifications remontant à 1974 (RFC 675) et 1981 (RFC 793) n’ont pas beaucoup changé à ce jour.

La fiabilité que fournit TCP n’est cependant pas sans coût. Les frais généraux de tous les allers-retours requis par les prises de contact, les retours de livraison, les commandes de garanties et les sommes de contrôle qui pourraient être considérés comme faibles et redondants. Il a fait de TCP un goulot d’étranglement de la pile de protocoles moderne. HTTP/2 a atteint un plateau d’améliorations de vitesse qui peuvent être réalisées sur TCP.

Changer le TCP de manière substantielle n’est pas une tâche simple, car le protocole fait partie de la pile TCP/IP qui remonte aux années 70. Cela est profondément ancré dans les systèmes d’exploitation, le micrologiciel de l’appareil, etc.

UDP

UDP (User Datagram Protocol) est également l’une des parties de la suite de protocole Internet, avec ses spécifications qui remontent à 1980 (RFC 768).

Il s’agit, comme son nom l’indique, d’un protocole sans connexion basé sur un datagramme. Ce qui signifie qu’il n’y a pas de prise de contact et qu’il n’y a aucune garantie de commande ou de livraison. Cela signifie que toutes les étapes possibles pour assurer la livraison, l’intégrité des données et d’autres choses sont laissées sur la couche application. Cela signifie qu’une application construite sur UDP peut choisir les stratégies qu’elle utilisera en fonction du cas concret, ou qu’elle peut éventuellement utiliser des éléments de la couche de lien, comme les sommes de contrôle, pour éviter les frais généraux.

Étant donné que le protocole UDP est très répandu, tout comme le protocole TCP, il permet d’apporter des améliorations sans nécessiter de mises à jour des firmwares d’un grand nombre d’appareils connectés à Internet, ni de modifications importantes des systèmes d’exploitation.

Le déploiement de nouveaux protocoles est entravé par de nombreux pare-feu, NATs, routeurs et autres middle-box qui n’autorisent que le déploiement TCP ou UDP entre les utilisateurs et les serveurs qu’ils doivent atteindre. – Explication de HTTP/3

Ce fil de discussion sur Hacker News peut nous aider à commencer à comprendre le raisonnement derrière la construction de la nouvelle version HTTP sur la pile réseau existante, plutôt que de la réinventer (bien qu’il y ait plus que cela).

La spécification du format de paquet UDP est plutôt minimale, son en-tête se compose du port source, du port de destination, de la longueur, en octets, de l’en-tête du paquet et des données du paquet et de la somme de contrôle. La somme de contrôle peut être utilisée pour vérifier l’intégrité des données tant pour l’en-tête que pour la partie données du paquet.

La somme de contrôle est facultative lorsque la couche de protocole sous-jacente est IPv4, et obligatoire avec IPv6. Jusqu’à présent, l’UDP a été utilisé pour des choses comme la synchronisation de l’horloge des systèmes informatiques (NTP), applications VoIP, le streaming vidéo, le système DNS et le protocole DHCP.

QUIC et HTTP/3

QUIC (Quick UDP Internet Connections) a été déployé pour la première fois par Google en 2012. Il redéfinit les limites des couches réseau en s’appuyant sur le protocole UDP de niveau inférieur, en redéfinissant les prises de contact, les fonctions de fiabilité et les fonctions de sécurité dans « l’espace utilisateur », ce qui évite d’avoir à mettre à niveau les noyaux des systèmes Internet.

Tout comme avec HTTP/2, une avancée qui a été menée par Google SPDY ou Speedy, HTTP/3 s’appuiera à nouveau sur ces réalisations.

Bien que HTTP/2 nous ait donné le multiplexage et atténué le blocage en tête de ligne, il est limité par TCP. Vous pouvez utiliser une seule connexion TCP pour plusieurs flux multiplexés ensemble pour transférer des données, mais lorsque l’un de ces flux subit une perte de paquets, toute la connexion (et tous ses flux) sont retenus en otage, pour ainsi dire, jusqu’à ce que TCP fasse son travail (retransmettre le paquet perdu).

Cela signifie que tous les paquets, même s’ils sont déjà transmis et en attente, sont bloqués dans le tampon du noeud de destination jusqu’à ce que le paquet perdu soit retransmis. Daniel Stenberg dans son livre sur http/3 appelle ça un « bloc de tête de ligne basé sur TCP ». Il affirme qu’avec 2% de perte de paquets, les utilisateurs feront mieux avec HTTP/1, avec six connexions pour couvrir ce risque.

QUIC n’est pas contraint par cela. Avec QUIC s’appuyant sur le protocole UDP connectionless, le concept de connexion n’a pas les limites de TCP et les échecs d’un flux n’ont pas à influencer le reste.

Comme l’a dit Lucas Pardue de Cloudflare :

En mettant l’accent sur les flux UDP, QUIC réalise le multiplexage sans avoir à utiliser une seule connexion TCP. QUIC construit sa connexion à un niveau plus élevé que TCP. Les nouveaux flux dans les connexions QUIC ne sont pas obligés d’attendre que les autres se terminent. Les connexions QUIC bénéficient également de l’élimination de la surcharge du handshake TCP, ce qui réduit la latence.

Les gens de Cisco ont fait une vidéo intéressante expliquant la prise de contact à 3 voies de TCP:

Alors que QUIC supprime les fonctions de fiabilité TCP, il compense par la couche UDP, en assurant la retransmission des paquets, la commande, etc. Google Cloud Platform a introduit le support QUIC pour ses load balancers en 2018 et a vu une amélioration du temps moyen de chargement des pages de 8% au niveau mondial, et jusqu’à 13% dans les régions où la latence est plus élevée.

Entre Google Chrome, YouTube, Gmail, la recherche de Google et d’autres services, Google a pu déployer QUIC sur une bonne partie d’Internet, sans attendre l’IETF. Les ingénieurs de Google affirment qu’en 2017, 7% du trafic Internet était déjà réalisé sur QUIC.

La version de QUIC de Google se concentrait uniquement sur le transport HTTP, en utilisant la syntaxe HTTP/2. Les gens de l’IETF (ceux en charge de la standardisation de QUIC), ont décidé que la version IETF de QUIC devrait être capable de transporter plus que seulement HTTP. Pour l’instant, cependant, tout travail sur les protocoles autres que le protocole HTTP sur QUIC est en suspens.

Le groupe de travail de l’IETF a également décidé que la version standardisée utilisera le cryptage TLS 1.3 au lieu de la solution personnalisée de Google. TLS 1.3, par rapport aux anciennes versions, contribue également à la vitesse du protocole, car ses prises de contact nécessitent moins d’aller-retour. Kinsta supporte le TLS 1.3 sur tous nos serveurs et notre CDN Kinsta.

Actuellement, Google continue d’utiliser sa propre version de QUIC dans son produit, tout en orientant ses efforts de développement vers les normes IETF. La plupart des autres acteurs de l’Internet s’appuient sur la version de l’IETF (les deux diffèrent sur d’autres aspects que le cryptage).

Si nous ouvrons Chrome Dev Tools et chargeons certains produits Google, comme Gmail, dans la colonne Protocole de l’onglet Réseau, nous verrons beaucoup de ressources chargées via la version Google du protocole QUIC. C’est également le cas pour les produits Google comme Analytics, Google Tag Manager, etc.

Cloudflare a récemment publié une mise à jour très complète sur les progrès de la normalisation.

Bien que le protocole UDP offre certains avantages inhérents au QUIC et au HTTP/3, il comporte aussi certains défis.

TCP est le protocole courant depuis des années, alors que UDP ne l’est pas, de sorte que les systèmes d’exploitation et la pile logicielle n’est généralement pas aussi optimisée. Par conséquent, il y a beaucoup plus de charge/besoins CPU avec QUIC, selon certaines estimations, deux fois plus qu’avec HTTP/2.

Les optimisations vont en profondeur jusqu’au noyau des systèmes d’exploitation et aux différents routeurs et micrologiciels des appareils. Ce guide Red Hat Tuning peut apporter plus de lumière sur le sujet pour ceux qui sont plus enclins sur le plan technique.

Nous pourrions dire que QUIC tente de réinventer les fonctionnalités TCP en plus d’un protocole plus minimal et plus flexible.

Les connexions QUIC, que nous avons mentionnées plus haut, combinent le TLS et les poignées de main de transport. Une fois établis, ils sont identifiés par des CIDs uniques (ID de connexion). Ces IDs persistent à travers les changements d’IP et peuvent aider à sécuriser les téléchargements ininterrompus sur, par exemple, un passage de la 4G vers le WiFi. Cela est d’autant plus important que le trafic Internet est de plus en plus important sur les appareils mobiles. On peut se demander si cet élément est conçu par Google pour faciliter un meilleur suivi des utilisateurs entre les différentes connexions et les différents fournisseurs d’accès à Internet.

Le protocole TLS est obligatoire et vise à empêcher les périphériques situés au milieu d’altérer ou de snifer le trafic. C’est pourquoi il n’est pas rare de voir des fournisseurs de pare-feu comme Cisco voir le protocole UDP comme un problème, et de fournir des moyens de le désactiver. Il est plus difficile pour les intermédiaires d’inspecter et de superviser ou de filtrer le trafic QUIC.

Les flux QUIC sont envoyés via des connexions QUIC, unidirectionnelles ou bidirectionnelles. Les flux ont des IDs qui identifient l’initiateur et indiquent si le flux est unidirectionnel ou bidirectionnel, et servent également au contrôle du débit dans le flux.

Alors que QUIC est un protocole de couche de transport, HTTP est la couche supérieure, un protocole de couche d’application, ou protocole d’application.

Comme la rétrocompatibilité est de la plus haute importance, l’IETF a encouragé la mise en œuvre de HTTP/3 en incluant l’ancienne version (HTT1 ou HTTP/2) dans la réponse. Il comprendra un en-tête qui informe le client que HTTP/3 est disponible, ainsi que des informations sur le port/hôte, comme décrit dans la RFC 7838.

C’est différent de HTTP/2, dans lequel le transport peut être négocié dans le cadre de la prise de contact TLS. Mais comme l’IETF a pratiquement adopté le protocole HTTP/3 basé sur QUIC comme norme suivante, nous pouvons nous attendre à ce que les clients Web anticipent de plus en plus le support de HTTP/3. Il est possible pour les clients de mettre en cache les données des connexions HTTP/3 précédentes, et de se connecter directement (zero-round-trip, ou 0-RTT) lors de visites ultérieures sur le même hébergeur.

Résumé

Il y a ceux qui pensent qu’avec l’adoption incomplète de la norme HTTP/2, il est peut-être trop tôt pour faire pression en faveur de HTTP/3. C’est un point valable, mais, comme nous l’avons mentionné, ce protocole a déjà fait l’objet d’essais et de mises en œuvre à grande échelle. Google a commencé à le tester dès 2015, ainsi que Facebook en 2017.

En 2024, les principaux navigateurs comme Google Chrome et Brave prennent en charge HTTP/3. Sur le plan de l’infrastructure, des serveurs web comme Litespeed et Nginx disposent tous deux d’implémentations fonctionnelles de HTTP/3, tandis que des fournisseurs de réseaux comme Cloudflare ont déjà déployé un support complet de HTTP/3.

Currently, HTTP/3 is still in the Internet Draft phase, and the latest revision is due to expire in August 2021. This year will be exciting, as we can expect to see major software vendors implementing the new standard.

Tonino Jankov

Tonino is an entrepreneur, Linux & OSS enthusiast, developer, and tech educator. He has over ten years of experience in development and has been in the blockchain space for 3+ years. When he's not coding, he writes for SitePoint and Alibaba Cloud, binge-watches the newest works of fiction on Netflix, and explores new travel destinations.

• Twitter