Le protocole de transfert hypertexte (HTTP) est une pierre angulaire d’Internet, qui permet de charger des pages web, de diffuser des vidos et de rcuprer des donnes pour vos applications prfres. L’anne dernire, une nouvelle version du protocole, HTTP/3, a t normalise par l’IETF (Internet Engineering Task Force), l’organisation charge de dfinir 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 dpendent de la source et de la mthode de mesure, la prise en charge de HTTP/3 allant de 19 % plus de 50 % des serveurs et rseaux web dans le monde. tant donn que ces nouveaux protocoles sont largement utiliss par de grandes entreprises telles que Google et Meta, nous pouvons affirmer sans risque qu’une grande partie du trafic Internet actuel utilise dj 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 problmes que HTTP/3 rsout, 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 rseau dcrit la manire dont les donnes sont communiques entre deux entits du rseau, gnralement l’appareil de l’utilisateur et un serveur web. tant donn que de nombreuses entreprises diffrentes conoivent des logiciels pour le web, le protocole doit tre normalis afin que tous ces logiciels puissent tre « interoprables« , c’est–dire qu’ils puissent tous se comprendre parce qu’ils suivent les mmes rgles.
Dans la pratique, nous n’utilisons pas un seul protocole, mais une combinaison de plusieurs en mme temps, chacun ayant ses propres responsabilits et rgles. Cela permet de rendre les choses flexibles et rutilisables : vous pouvez toujours utiliser exactement la mme logique HTTP, que vous utilisiez le Wi-Fi, le cble ou la 4G/5G.
Bon nombre des protocoles originaux de l’internet ont t normaliss dans les annes 80 et 90, ce qui signifie qu’ils ont t labors en tenant compte des objectifs et des restrictions de ces dcennies. Si certains de ces protocoles ont rsist l’preuve du temps, d’autres commencent accuser leur ge. La plupart des problmes ont t rsolus par des solutions de contournement et des astuces. Cependant, il tait clair que quelque chose devait changer. C’est particulirement vrai pour le protocole de contrle du transport (TCP), qui garantit que vos donnes 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 requte/rponse HTTP, ils doivent tablir une connexion TCP.
Au fil du temps, de nombreux efforts ont t dploys pour mettre jour TCP et rsoudre certaines de ses inefficacits – 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 couronnes de succs, mais la plupart des plus importantes (par exemple, TCP multipath et TCP Fast Open) ont pris prs d’une dcennie avant d’tre pratiquement utilisables sur l’internet public.
La principale difficult lie la mise en uvre des modifications du protocole TCP rside dans le fait que des milliers d’appareils sur l’internet ont tous leur propre implmentation du protocole TCP. Il s’agit notamment de tlphones, d’ordinateurs portables et de serveurs, ainsi que de routeurs, de pare-feu, d’quilibreurs de charge et d’autres types de « botes intermdiaires ». Ainsi, si nous voulons mettre jour le protocole TCP, nous devons attendre qu’une partie importante de tous ces dispositifs mette jour leur implmentation, ce qui, dans la pratique, peut prendre des annes.
La solution QUIC
Le problme est devenu tel que la solution la plus pratique a t de remplacer TCP par quelque chose d’entirement 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 caractristiques de haut niveau de TCP, mais avec quelques changements cruciaux.
Le principal changement est que QUIC intgre fortement le protocole Transport Layer Security (TLS). TLS est responsable du cryptage des donnes sensibles sur le web : c’est lui qui fournit le S (scuris) dans HTTPS. Avec TCP, TLS ne crypte que les donnes HTTP proprement dites . Avec QUIC, TLS crypte galement de grandes parties du protocole QUIC lui-mme. Cela signifie que les mtadonnes, telles que les numros de paquets et les signaux de fermeture de connexion, qui taient visibles (et modifiables) par toutes les botes intermdiaires 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 fonctionnalits : il suffit de mettre jour les clients et les serveurs, car les botes intermdiaires ne peuvent de toute faon pas dcrypter les mtadonnes. QUIC est donc un protocole l’preuve du temps qui nous permettra de relever plus rapidement de nouveaux dfis.
Bien entendu, ce cryptage supplmentaire est galement bnfique pour la scurit gnrale et la confidentialit du nouveau protocole. Si TCP + TLS sont parfaits pour scuriser les donnes personnelles sensibles, telles que les cartes de crdit ou le contenu des courriels, ils peuvent encore tre vulnrables des attaques complexes (contre la vie prive), dont l’excution est devenue de plus en plus pratique grce aux progrs rcents de l’intelligence artificielle. En chiffrant davantage ce type de mtadonnes, QUIC est plus rsistant aux acteurs de menaces sophistiques.
QUIC possde galement de nombreuses autres fonctions lies la scurit, notamment des dfenses contre les attaques par dni de service distribu (DDoS), avec des fonctions telles que la prvention de l’amplification et les paquets RETRY.
Enfin, QUIC comprend galement un grand nombre d’amliorations en termes d’efficacit et de performances par rapport TCP, notamment un change de connexion plus rapide, la suppression du problme du « blocage en tte de ligne », une meilleure dtection/rcupration des pertes de paquets et des moyens de grer les utilisateurs qui changent de rseau.
Nous n’avions pas besoin de HTTP/3 ; ce dont nous avions besoin, c’tait de QUIC
Au dpart, on a essay de conserver HTTP/2 et de faire des ajustements minimes pour pouvoir utiliser QUIC dans les couches infrieures (aprs tout, c’est l tout l’intrt d’avoir ces diffrents protocoles qui cooprent et sont rutilisables). Cependant, il est apparu clairement que QUIC tait suffisamment diffrent de TCP pour le rendre incompatible avec HTTP/2. Il a donc t dcid de crer une nouvelle version de HTTP, uniquement pour QUIC, qui est finalement devenue HTTP/3.
HTTP/3 est presque identique HTTP/2. Ils diffrent principalement dans l’implmentation technique des fonctionnalits au-dessus de QUIC ou de TCP. Toutefois, comme HTTP/3 peut utiliser toutes les nouvelles fonctionnalits de QUIC, on s’attend ce qu’il soit plus performant lors du chargement de pages web et de vidos 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 ?
Quel est votre avis sur le sujet ?
Voir aussi :