Pourquoi HTTP/3 mange le monde

Le protocole de transfert d'hypertextes (HTTP) est une pierre angulaire de l'internet. Il permet de charger des pages web, de diffuser des vidéos et de récupérer des données pour vos applications préférées.

L'année dernière, une nouvelle version du protocole, HTTP/3, a été normalisée par l'IETF (Internet Engineering Task Force), l'organisation chargée de définir les technologies de l'internet. Depuis lors, HTTP/3 et le protocole QUIC qui lui est associé ont connu un essor rapide sur le web public. Les chiffres exacts dépendent de la source et de la méthode de mesure, la prise en charge de HTTP/3 allant de 19 % à plus de 50 % des serveurs et réseaux web dans le monde.

Étant donné que ces nouveaux protocoles sont largement utilisés par de grandes entreprises telles que Google et Meta, nous pouvons affirmer sans risque qu'une grande partie du trafic Internet actuel utilise déjà HTTP/3 aujourd'hui. En fait, l'article de blog que vous lisez en ce moment même a probablement été chargé via HTTP/3 !

Dans cette série, je vous présenterai le contexte dans lequel HTTP/3 résout les problèmes, comment il fonctionne, pourquoi il a été adopté si rapidement et quelles sont les limites qu'il doit encore surmonter.

Un protocole réseau décrit la manière dont les données sont communiquées entre deux entités du réseau, généralement l'appareil de l'utilisateur et un serveur web. Étant donné qu'un grand nombre d'entreprises différentes conçoivent des logiciels pour le web, le protocole doit être normalisé afin que tous ces logiciels puissent être "interopérables", c'est-à-dire qu'ils puissent tous se comprendre les uns les autres parce qu'ils suivent les mêmes règles.

Dans la pratique, nous n'utilisons pas un seul protocole, mais une combinaison de plusieurs en même temps, chacun ayant ses propres responsabilités et règles (figure 1). Vous pouvez toujours utiliser exactement la même logique HTTP, que vous utilisiez le WiFi, le câble ou la 4G/5G.

Bon nombre des protocoles originaux de l'internet ont été normalisés dans les années 80 et 90, ce qui signifie qu'ils ont été élaborés en tenant compte des objectifs et des restrictions de ces décennies. Si certains de ces protocoles ont résisté à l'épreuve du temps, d'autres ont commencé à montrer leur âge. La plupart des problèmes ont été résolus par des solutions de contournement et des astuces. Cependant, il était clair que quelque chose devait changer. C'est particulièrement vrai pour le protocole de contrôle du transport (TCP), qui garantit que vos données traversent l'internet en toute fiabilité.

HTTP/1.1 et HTTP/2 s'appuient sur le protocole TCP pour mener à bien leur mission : avant qu'un client et un serveur puissent échanger une requête/réponse HTTP, ils doivent établir une connexion TCP.

Au fil du temps, de nombreux efforts ont été déployés pour mettre à jour TCP et résoudre certaines de ses inefficacités - TCP charge toujours les pages web comme s'il s'agissait de fichiers uniques au lieu d'une collection de centaines de fichiers individuels. Certaines de ces mises à jour ont été couronnées de succès, mais la plupart des plus importantes (par exemple, TCP multipath et TCP Fast Open) ont pris près d'une décennie avant d'être pratiquement utilisables sur l'internet public.

La principale difficulté liée à la mise en œuvre des modifications apportées au protocole TCP réside dans le fait que des milliers d'appareils sur l'internet ont tous leur propre implémentation du protocole TCP. Il s'agit notamment de téléphones, d'ordinateurs portables et de serveurs, ainsi que de routeurs, de pare-feu, d'équilibreurs de charge et d'autres types de "boîtes intermédiaires". Ainsi, si nous voulons mettre à jour le protocole TCP, nous devons attendre qu'une grande partie de tous ces appareils mettent à jour leur implémentation, ce qui, dans la pratique, peut prendre des années.

Le problème est devenu tel que la solution la plus pratique a été de remplacer TCP par quelque chose d'entièrement nouveau. Ce remplacement est le protocole QUIC, bien que beaucoup l'appellent encore (en plaisantant) TCP 2.0. Ce surnom est approprié parce que QUIC comprend un grand nombre de caractéristiques de haut niveau de TCP, mais avec quelques changements cruciaux.

Le principal changement est que QUIC intègre fortement le protocole Transport Layer Security (TLS). TLS est responsable du cryptage des données sensibles sur le web - c'est lui qui fournit le S (sécurisé) dans HTTPS. Avec TCP, TLS ne crypte que les données HTTP proprement dites (Figure 2). Avec QUIC, TLS crypte également de grandes parties du protocole QUIC lui-même. Cela signifie que les métadonnées, telles que les numéros de paquets et les signaux de fermeture de connexion, qui étaient visibles (et modifiables) par toutes les boîtes intermédiaires dans le protocole TCP, ne sont plus accessibles qu'au client et au serveur dans le protocole QUIC.

En outre, comme QUIC est plus largement crypté, il sera beaucoup plus facile que pour TCP de le modifier ou d'ajouter de nouvelles fonctionnalités - il suffit de mettre à jour les clients et les serveurs, car les boîtes intermédiaires ne peuvent de toute façon pas décrypter les métadonnées. QUIC est donc un protocole à l'épreuve du temps qui nous permettra de relever plus rapidement de nouveaux défis.

Bien entendu, ce cryptage supplémentaire est également bénéfique pour la sécurité générale et la confidentialité du nouveau protocole. Si TCP + TLS sont parfaits pour sécuriser les données personnelles sensibles, telles que les cartes de crédit ou le contenu des courriels, ils peuvent encore être vulnérables à des attaques complexes (contre la vie privée), dont l'exécution est devenue de plus en plus pratique grâce aux progrès récents de l'intelligence artificielle. En chiffrant davantage ce type de métadonnées, QUIC est plus résistant aux acteurs de menaces sophistiquées.

QUIC possède également de nombreuses autres fonctions liées à la sécurité, notamment des défenses contre les attaques par déni de service distribué (DDoS), avec des fonctions telles que la prévention de l'amplification et les paquets RETRY.

Enfin, QUIC comprend également un grand nombre d'améliorations en termes d'efficacité et de performances par rapport à TCP, notamment un échange de connexion plus rapide (voir la figure 3), la suppression du problème de blocage en tête de ligne, une meilleure détection/récupération des pertes de paquets et des moyens de gérer les utilisateurs qui changent de réseau (je reviendrai plus en détail sur ce point dans mon prochain article).

Au départ, on a tenté de conserver HTTP/2 et de procéder à des ajustements minimes afin de pouvoir utiliser QUIC dans les couches inférieures (après tout, c'est là tout l'intérêt d'avoir ces différents protocoles qui coopèrent et sont réutilisables). Cependant, il est apparu clairement que QUIC était suffisamment différent de TCP pour le rendre incompatible avec HTTP/2. Il a donc été décidé de créer une nouvelle version de HTTP, uniquement pour QUIC, qui est finalement devenue HTTP/3.

HTTP/3 est presque identique à HTTP/2. Ils diffèrent principalement dans l'implémentation technique des fonctionnalités au-dessus de QUIC ou de TCP. Toutefois, comme HTTP/3 peut utiliser toutes les nouvelles fonctionnalités de QUIC, on s'attend à ce qu'il soit plus performant lors du chargement de pages web et de vidéos en continu. Dans la pratique, c'est surtout cet aspect qui a conduit à l'adoption rapide de HTTP/3.

Dans mon prochain article, j'aborderai plus en détail un problème de connectivité courant que vous avez probablement rencontré et comment QUIC peut aider à réduire les coupures d'appels et de vidéos lorsque votre appareil mobile passe d'une connectivité WiFi à une connectivité cellulaire.

Robin Marx est expert en protocoles et performances web chez Akamai. Les opinions exprimées par les auteurs de ce blog sont les leurs et ne reflètent pas nécessairement celles de l'Internet Society.

Photo par Nick Night sur Unsplash