HTTP/3, basé sur UDP, est la nouvelle version du protocole HTTP. L’IETF (Internet Engineering Task Force) s’est réuni à Bangkok en novembre 2018 pour adopter ce nouveau brouillon Internet. En mai 2021, le protocole HTTP/3 est encore un brouillon Internet, mais des entreprises comme Google, Microsoft ou Facebook l’utilisent déjà pour accélérer le web. Selon les données relatives à l’utilisation de HTTP/3 sur W3Techs, environ 19 % des sites web prennent déjà en charge HTTP/3.
Qu’est-ce que HTTP/3 ?
Le protocole HTTP/3 est la nouvelle version du protocole de transfert hypertexte (HTTP) et est basé sur le protocole UDP. Il était auparavant connu sous le nom de HTTP-over-QUIC. Le protocole réseau QUIC a été initialement développé par Google et remplacera HTTP/2. Le développement de HTTP/3 a commencé il y a plusieurs années et son objectif est d’accélérer la vitesse de l’Internet en apportant des changements importants dans la façon dont les données sont transférées.
HTTP/3 bénéficie des caractéristiques du protocole UDP et définit un grand nombre de nouvelles fonctionnalités qui se trouvaient dans les versions précédentes de HTTP sur la couche TCP. Cela permet de supprimer les limitations existant au sein de l’infrastructure d’Internet. Alors que HTTP/1.1 et HTTP/2 utilisaient TCP sur la couche transport, HTTP/3 utilise QUIC, visant à résoudre l’un des principaux problèmes de HTTP/2 concernant la progression linéaire des téléchargements.
Bien que HTTP/2 atténue le problème du « blocage en tête de ligne » grâce au multiplexage, il est toujours limité par TCP. En effet, bien qu’il permette l’utilisation d’une connexion TCP unique pour des transmissions multiples, lorsque l’une d’entre elles subit une perte de paquets, toute la connexion s’arrête en attendant que le TCP retransmette le paquet perdu. HTTP/3 n’est pas limité par ce problème de blocage, grâce à son intégration au protocole UDP sans connexion.
En fournissant un multiplexage natif, QUIC permet que les paquets perdus n’aient un impact que sur les transmissions où des données ont été perdues. Ainsi, les nouveaux flux au sein d’une connexion QUIC n’ont pas besoin d’attendre que les autres se terminent. De plus, la surcharge du handshake TCP est également supprimée et, par conséquent, la latence est réduite. En ce qui concerne la fiabilité, QUIC ne comprend pas certaines des caractéristiques du protocole TCP, mais il se rattrape au-dessus de la couche UDP, en assurant la retransmission des paquets, l’ordonnancement, etc.
Couche de transport : TCP vs UDP
TCP : Protocole de contrôle du transport
TCP est l’acronyme de Transport Control Protocol. Ce protocole se situe au-dessus de la couche du protocole Internet (IP). Le TCP est la base de nombreux protocoles et services Internet et il est chargé, entre autres, de :
Assurer la fiabilité nécessaire au web, au transfert de fichiers, etc.
Établir une connexion en plusieurs étapes, garantir l’ordre des paquets et offrir la retransmission des paquets perdus.
Offrir un calcul de somme de contrôle pour la détection des erreurs.
Néanmoins, en termes de fiabilité, le protocole TCP comporte également une limite importante : l’overhead de tous les allers-retours nécessaires pour assurer la livraison correcte de l’information. Pour cette raison, le protocole TCP est devenu un goulot d’étranglement pour l’amélioration de la vitesse. Bien que HTTP/2 offre quelques améliorations à ce sujet, comme expliqué plus loin.
La spécification du protocole TCP remonte à 1974 et 1981 (RFC 675 et RFC 793 respectivement). Depuis lors, ce protocole n’a pas subi de changements significatifs car il est profondément intégré aux systèmes d’exploitation, aux microprogrammes, etc. et le modifier n’est pas une tâche facile.
UDP : User Datagram Protocol (protocole de datagramme utilisateur)
UDP est l’acronyme de User Datagram Protocol. UDP est un protocole sans connexion basé sur des datagrammes, sans garantie de livraison. La livraison de l’information, l’intégrité des données, etc., sont déléguées à la couche application. Le protocole UDP est principalement utilisé pour des applications telles que la VoIP, le DNS, le DHCP et le BOOTP, entre autres. Les spécifications du format des paquets UDP sont minimales. Son en-tête se compose de :
Le port source et le port de destination,
la longueur (en octets) de l’en-tête du paquet et des données du paquet,
et la somme de contrôle pour la vérification de l’intégrité des données (facultative avec IPv4 et obligatoire avec IPv6).
La spécification du protocole UDP date de 1980 (RFC 768) et il est également largement utilisé. Ainsi, toute amélioration substantielle entraînerait également des changements importants sur le firmware des appareils connectés à l’Internet et sur les systèmes d’exploitation.
Le protocole réseau QUIC
QUIC est l’acronyme de Quick UDP Internet Connections. QUIC, conçu par Jim Roskind chez Google en 2012, est un protocole réseau sur la couche de transport UDP. La version QUIC de Google était uniquement axée sur le transport HTTP, en utilisant la syntaxe de HTTP/2. Cependant, pour sa normalisation, l’IETF va plus loin.
Avec QUIC, les limites des couches réseau, des communications, des fonctions de fiabilité et des fonctions de sécurité dans l' »espace utilisateur » sont redéfinies. Cela permet d’éviter de devoir mettre à jour les noyaux des systèmes Internet. Néanmoins, l’utilisation d’UDP apporte à la fois des avantages et des inconvénients à QUIC et à HTTP/3. L’un des inconvénients est la charge CPU, qui peut doubler avec QUIC, par rapport à HTTP/2, selon certaines estimations. Cela est dû au fait que les systèmes d’exploitation et les logiciels ne sont pas optimisés pour l’utilisation d’UDP, puisque TCP est le protocole principal depuis longtemps.
En outre, l’utilisation de TLS est obligatoire pour les connexions QUIC, afin d’empêcher les dispositifs intermédiaires de modifier ou de détecter le trafic. Les flux QUIC ont un ID qui identifie qui commence la transmission et ils sont envoyés sur des connexions QUIC unidirectionnelles ou bidirectionnelles.
Mise en œuvre de HTTP/3
L’implémentation de HTTP/3 promue par l’IETF inclut également les versions précédentes, pour des raisons de compatibilité. Comme défini dans la RFC 7838, un en-tête informe le client de la disponibilité de HTTP/3, ainsi que des détails du port. Depuis mai 2021, les navigateurs Google Chrome, Firefox, Safari et Microsoft Edge prennent déjà en charge HTTP/3, du moins à titre expérimental, en attendant sa normalisation. De même que des serveurs comme Litespeed Web Server, HAProxy 2.3 ou Caddy web server.
En outre, il existe quelques bibliothèques open source d’implémentations de HTTP-over-QUIC, telles que : neqo de Mozilla, Cronet de Google, proxygen de Facebook, lsquic de LiteSpeed, aioquic, quic-go ou nghttp3. Sur GitHub il y a une liste complète des bibliothèques disponibles, développées en utilisant différents langages de programmation (C, C++, Rust, Python…).
Les versions HTTP
La première version de HTTP a été publiée en 1991 sous le nom de HTTP/0.9. Les versions HTTP/1.0 et HTTP/1.1 lui ont succédé en 1996 et 1997 respectivement. Avec l’évolution d’Internet et du web, le protocole a été constamment mis à niveau pour améliorer le transfert de données sur le réseau. Mais, jusqu’à la sortie de HTTP/2 en 2015, il n’y avait pas eu de changement substantiel. Cette nouvelle version a amélioré le transfert de données et, par conséquent, a permis d’accélérer considérablement la vitesse de chargement des pages web. Enfin, HTTP/3 est la prochaine version et elle devrait encore améliorer la vitesse d’Internet.
Améliorations de HTTP/2
Le protocole HTTP/2 a déjà apporté quelques améliorations intéressantes, telles que :
- Surmonter certaines limitations du protocole TCP avec des améliorations comme les téléchargements non bloquants, le pipelining et le server push.
- Minimiser le nombre de cycles demande-réponse et, par conséquent, améliorer la vitesse de chargement.
- Multiplexage ou envoi de plusieurs ressources à l’aide d’une seule connexion TCP.
- Amélioration de la flexibilité lors du téléchargement de ressources statiques et suppression de la limitation de la progression linéaire des téléchargements. Cela signifie qu’une ressource JavaScript importante ne doit pas nécessairement affecter la charge d’autres ressources statiques.
En outre, pour tirer le meilleur parti de HTTP/2, les principaux navigateurs ont rendu l’utilisation de SSL obligatoire, ce qui a rendu les améliorations de vitesse insignifiantes dans certains cas.
En résumé, l’évolution de protocoles essentiels tels que HTTP est indispensable dans le contexte toujours changeant de l’Internet et du web. En ce qui concerne la nouvelle version de ce protocole, les approches sont diverses. Certains pensent que, compte tenu du fait que la norme HTTP/2 n’a pas encore été complètement adoptée, il est peut-être trop tôt pour lancer une nouvelle version. Néanmoins, le succès des tests effectués avec HTTP/3 est encourageant, car il serait très avantageux pour tous les utilisateurs. Comme nous l’avons mentionné précédemment, les principaux navigateurs supportent déjà HTTP/3 et certaines entreprises comme Google, Mozilla, Facebook ou Akamai utilisent ce nouveau protocole depuis des années.
