Hypertext Transfer Protocol : l'adoption de HTTP/3 croît rapidement
Hypertext Transfer Protocol : l'adoption de HTTP/3 croît rapidement, d'après Robin Marx, expert en protocoles et performances web chez Akamai.
Le protocole de transfert hypertexte (HTTP) est une pierre angulaire d'Internet, qui 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 que vous êtes en train de lire a probablement été chargé via HTTP/3 !
Dans cet article, Robin Marx parle des problèmes que HTTP/3 résout, comment il fonctionne, pourquoi il a été adopté si rapidement et quelles sont les limites qu'il s'efforce encore de surmonter.
Pourquoi avons-nous besoin de HTTP/3 ?
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é que de nombreuses 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 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. Cela permet de rendre les choses flexibles et réutilisables : vous pouvez toujours utiliser exactement la même logique HTTP, que vous utilisiez le Wi-Fi, 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 commencent à accuser 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é.
Pourquoi le TCP n'est pas optimal pour le web d'aujourd'hui ?
Les protocoles 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 du 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 partie importante de tous ces dispositifs mette à jour leur implémentation, ce qui, dans la pratique, peut prendre des années.
La solution QUIC
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 de nombreuses 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 . 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, le QUIC étant plus largement crypté, il sera beaucoup plus facile que pour le 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, la suppression du problème du "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.
Nous n'avions pas besoin de HTTP/3 ; ce dont nous avions besoin, c'était de QUIC
Au départ, on a essayé de conserver HTTP/2 et de faire des ajustements minimes pour 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.
Source : Robin Marx, expert en protocoles et performances web chez Akamai.
Et vous ?
Que pensez-vous de l'HTTP/3 ?
Voir aussi :
Répondre avec citation
Partager