27mn de lecture
Presque tout le monde utilise le protocole de transfert hypertexte (HTTP) au quotidien. Le protocole est utilisé pour le transfert de fichiers et est principalement utilisé pour envoyer des sites Web vers n’importe quel navigateur. HTTP a été introduit en 1991, mais n’a été normalisé que cinq ans plus tard. Puis, en 2015, est arrivée la grande mise à jour HTTP/2, censée résoudre certains des problèmes du protocole. Cette mise à jour a apportée de nombreux avantages dans le domaine du transfert de flux de données. La principale innovation de HTTP/2 était le multiplexage. Cependant, cette version du protocole ne pouvait être qualifiée de complète. Le protocole a donc été mis à jour pour combler ces insuffisances. C’est ainsi qu’est apparu le protocole HTTP/3, très récemment adopté comme norme par l’IETF (Internet Engineering Task Force).
Développement du protocole HTTP
Étant donné que chaque bon cours d’informatique comprend également une excursion historique, le développement de HTTP devrait également être brièvement abordé. HTTP a été mentionné pour la première fois par Tim Berners-Lee à l’été 1991. Son concept pour le WWW se composait des trois composants HTML, Uniform Resource Locator (à l’époque encore Universal Document Identifier, UDI) et HTTP . À l’époque, HTTP était encore un protocole textuel très simplement structuré qui nécessitait une connexion TCP distincte pour chaque transmission. La demande était une ligne, la réponse du serveur était juste la ressource demandée.
Au cours des années suivantes, HTTP a grandi avec ses tâches et s’est doté de nouvelles fonctions de plusieurs côtés, plus ou moins inorganisées. Cinq ans plus tard, à l’été 1996, l’Internet Engineering Task Force (IETF) a résumé les fonctionnalités les plus courantes et décrit HTTP/1 dans la note RFC1945 . Cependant, il était important de noter qu’il ne s’agissait pas d’une norme : “Ce mémo ne spécifie aucune norme Internet d’aucune sorte”, disait-il succinctement à l’époque.
Les travaux sur une norme officielle ont commencé un an avant ladite note, initialement sous le nom de HTTP/NG ( NG pour Next Generation ). En 1997, en vertu de la RFC2068, celle-ci est devenue la version HTTP/1.1 , qui est désormais également introduite comme un “vrai” standard. Les changements les plus importants ont été la fonction keepalive, qui a permis pour la première fois des connexions persistantes. Il était désormais possible d’utiliser une connexion TCP ouverte pour plus que la simple transmission de données.
Le protocole a également pris en charge l’envoi de données au serveur (méthode PUT) pour la première fois. Théoriquement, le pipeline permettait également d’envoyer des requêtes sans avoir à attendre une réponse – une fonction qui n’était prise en charge que par quelques navigateurs à l’époque.
Après cela, HTTP est resté silencieux pendant un moment. Ce n’est qu’en 2012 qu’un brouillon pour HTTP/2 a suivi, qui était essentiellement basé sur SPDY, un protocole alternatif sur lequel Google travaillait depuis 2009. La norme HTTP/2 a été officiellement introduite en 2015. Les changements les plus importants : un échange de données asynchrone amélioré a été rendu possible grâce au multiplexage. De plus, c’était la première fois un protocole binaire. Les données ne sont donc plus transmises en clair.
Présentation du protocole HTTP/3
HTTP est le protocole de communication sur le World Wide Web (WWW). Avec HTTP, des fichiers ou des flux de données sont demandés par un navigateur Web client) à un serveur Web et affichés ou lus par le navigateur. Le protocole HTTP/3 combine les fonctions individuelles de HTTP, TLS et TCP en un seul protocole et ne sépare pas strictement les protocoles dans le modèle de couche OSI.
En combinaison avec QUIC, le protocole HTTP/3 est globalement plus rapide, peut mieux gérer les pertes de paquets et les changements de réseau avec les changements d’adresse client, ce qui joue un rôle majeur dans l’utilisation mobile. En particulier, le protocole HTTP/3 bénéficie davantage du passage à QUIC que des ajustements de protocole spécifiques à HTTP. Cependant, le protocole HTTP/3 avec QUIC présente également l’inconvénient de rendre le pare-feu plus difficile.
Le protocole HTTP/3 n’est en aucun cas un simple développement ultérieur, mais convertit plutôt une nouvelle approche que Google poursuit expérimentalement depuis 2012 en une norme générale. Il diffère considérablement des méthodes précédentes sur un certain nombre de points et combine les propriétés de HTTP/2 avec le protocole UDP (User Datagram Protocol) vieux de 40 ans. Sur cette base, qui est déjà largement utilisée et, par exemple, pour les requêtes au sein du système de noms de domaine (DNS), Google a activement développé sa propre spécification du protocole Quick UDP Internet Connections (QUIC).
D’autres bases, en revanche, ont été adoptées à partir de HTTP/2 – y compris, par exemple, la compression d’en-tête, le multiplexage pour le flux parallèle de données provenant de différentes sources telles que des images, des vidéos ou du texte et la hiérarchisation des flux de données, qui préfère les fichiers pour CSS et JavaScript, par exemple, s’ils sont utilisés pour la construction de pages, sont généralement indispensables.
Les grandes différences entre HTTP/3 et HTTP/2
Un changement clé entre le protocole HTTP/3 et son prédécesseur, HTTP/2, est l’abandon de TCP pour la transmission, qui se produit plutôt exclusivement sur QUIC. La caractéristique typique de HTTP/2 et des versions antérieures était la communication caractérisée par TCP, qui se déroule de manière strictement séquentielle via des poignées de main à plusieurs niveaux entre le serveur et le client. Tous les paquets de données sont transmis de manière incrémentielle et sont reçus dans un ordre spécifié, de sorte qu’un seul paquet perdu entraînera une interruption de la transmission.
Contrairement à cela, UDP et le QUIC basé sur celui-ci fonctionnent sans connexion. Il n’y a pas de vérification de la réussite de la livraison, mais seulement – si nécessaire – de l’intégrité du paquet et de l’ensemble de la transmission à l’aide d’une somme de contrôle.
De plus, QUIC et donc le protocole HTTP/3 nécessitent un chiffrement via le protocole Transport Layer Security (TLS) utilisé pour les sites Web en HTTPS en version 1.3 ou supérieure. Contrairement à HTTP/2, cela n’est plus effectué par une instance externe au niveau du protocole TCP, mais est fermement intégré dans QUIC et constitue la base d’une communication réussie. Dans le cas de téléchargements plus volumineux, cela ne se fait plus au moyen d’adresses IP, mais d’un identifiant individuel attribué à l’utilisateur. Si le réseau change, par exemple parce qu’un appareil mobile se déplace d’une cellule radio à une autre, les téléchargements et les flux du protocole HTTP/3 peuvent continuer sans interruption ni reconnexion.
Les avantages du nouveau protocole HTTP/3
Les flux de données individuels sont traités séparément avec le protocole HTTP/3. Si un paquet est perdu en cours de route, cela n’affecte plus tous les flux de données, comme c’était le cas avec la transmission TCP. Au lieu de cela, avec le protocole HTTP/3, seul le flux réellement affecté doit attendre que le paquet manquant soit livré. Le protocole HTTP/3 réduit également le temps d’aller-retour des paquets. C’est le temps qu’il faut pour qu’un paquet de données arrive à destination en plus du temps qu’il faudrait pour accuser réception des données.
Une connexion HTTP/3 est établie avec un port UDP et une adresse IP. Dès que la connexion est établie, un identifiant de connexion est attribué. Cet identifiant de connexion est indépendant de votre adresse IP. Il en résulte un autre avantage du protocole HTTP/3 : si vous passez de votre WLAN à une connexion de données mobile, par exemple, tout téléchargement en cours ne doit pas être interrompu.
Le cryptage du protocole HTTP/3
Contrairement à la norme précédente, les connexions HTTP/3 sont toujours cryptées. Le protocole utilise pour cela la norme de cryptage TLS 1.3. D’une part, cela augmente la sécurité car les connexions non chiffrées ne se produisent tout simplement plus. Cependant, le cryptage a également un autre objectif : il est destiné à empêcher ce que l’on appelle l’ossification du protocole. Le terme fait référence à la rigidité croissante des protocoles réseau, causée, par exemple, par les pare-feu ou les NAT. Ils vérifient si le trafic de passage est éventuellement un trafic malveillant et bloquent donc souvent tout écart par rapport à la norme.
Quand le protocole HTTP/3 deviendra t’il le nouveau standard ?
Les navigateurs actuels prennent déjà en charge le protocole HTTP/3 comme standard. Cependant, la transition pose un plus grand défi aux fournisseurs qui doivent mettre en œuvre ce changement dans leur infrastructure. Certains d’entre eux voient également des problèmes de sécurité, car ils craignent que le cryptage intégré n’affaiblisse le contrôle auparavant clair du trafic de données en raison du manque d’authentification TLS. Par conséquent, il ne peut être exclu que le protocole HTTP/3 entrave le travail des fournisseurs s’ils sont infectés par des logiciels malveillants, DDOS veulent bloquer des attaques ou de faux paquets dans le cadre de cyberattaques.
On peut donc s’attendre à une introduction généralisée à moyen terme au mieux, c’est pourquoi HTTP/2 restera probablement utilisé au moins partiellement pendant de nombreuses années à venir. Cela se traduit notamment par le fait que même après plus de 20 ans, HTTP 1.0 et 1.1 sont toujours utilisés sur de nombreux sites Web. La propagation dans les réseaux locaux a même augmenté, car de nombreux appareils IoT avec une interface Web simple n’ont tout simplement pas assez de puissance de calcul pour permettre un cryptage efficace des connexions.
La prise en charge du protocole HTTP/3
Cloudflare prend désormais en charge le nouveau protocole HTTP/3, qui est destiné à remplacer la version HTTP/2 actuelle à l’avenir . De plus, Google et Mozilla ont annoncé leur intention d’intégrer le protocole dans leurs navigateurs Chrome et Firefox. Les clients Cloudflare peuvent désormais activer l’option HTTP/3 dans leurs tableaux de bord, débloquant ainsi la prise en charge de leur domaine. Les visiteurs communiquent ensuite avec le site Web via le nouveau protocole dès que leur client est compatible avec le protocole HTTP/3.
Cela s’applique au moins dans une mesure limitée à Chrome et Firefox. Chrome Canary utilise déjà le protocole HTTP/3 après avoir activé le protocole via le paramètre de ligne de commande « –enable-quic –quic-version=h3-23 ». Firefox bénéficiera du support du protocole HTTP/3 avec une version Nightly à l’automne.
HTTP est le protocole utilisé pour transférer le contenu des serveurs vers les clients. Il est utilisé par les navigateurs, les applications mobiles et d’autres applications pour afficher du contenu. Le protocole HTTP/3 est une réécriture complète du protocole – alors que HTTP/2 n’était qu’une extension.
Un inconvénient de HTTP est qu’il utilise le protocole TCP pour négocier les connexions et transporter les données entre les clients. Cependant, TCP a été développé dans les années 1970. A cette époque, il n’était pas destiné à être utilisé pour la transmission de données en temps réel. Les développeurs ont finalement essayé de développer des alternatives pour TCP. Cela a donné naissance au protocole SPDY inventé par Google, qui a finalement conduit à HTTP sur SPDY et est maintenant connu sous le nom de HTTP/2 et est utilisé par environ 40 % de tous les sites Web sur Internet.
Ce sont également les développeurs de Google qui ont tenté de combiner la fiabilité de TCP avec la rapidité du protocole UDP. Cela a abouti au protocole Quick UDP Internet Connections, ou QUIC en abrégé. HTTP/3, à son tour, est l’implémentation de QUIC dans HTTP, qui a été officiellement approuvée en octobre dernier.
Le protocole HTTP/3 n’est actuellement pris en charge que par 3 % de tous les sites Web. Les annonces de Cloudflare, Google et Mozilla pourraient désormais changer la donne. Parce qu’environ 10 % de tous les sites Web utilisent le réseau de diffusion de contenu de Cloudflare. « Cloudflare a été un acteur clé dans l’adoption de HTTP/2 et a publié son support HTTP/2 pour tous les clients en décembre 2015. En fait, Cloudflare prend toujours en charge la majeure partie du Web HTTP/2 », a expliqué un porte-parole de Cloudflare.
Conclusion
La véritable star derrière la prochaine étape évolutive HTTP est QUIC. Le nouveau protocole de transport est destiné à remplacer le vénérable TCP dans le but d’augmenter la vitesse, la mobilité et la sécurité et mettra ainsi également en œuvre les promesses de HTTP/2 de manière un peu plus cohérente.
Le passage au protocole HTTP/3 ne devrait pas poser de problème. QUIC s’exécute dans l’ espace utilisateur et devrait donc être facile à mettre en œuvre. Étant donné que l’UDP est utilisé comme sous-structure, une mise à jour du logiciel de navigation est suffisante sans avoir à attendre la prochaine version du système d’exploitation. De plus, QUIC est décrit comme rétro-compatible.
Besoin d’un hébergeur web pour votre site ?
Découvrez l'offre exclusive de LWS : hébergement web à -50% ! Commencez dès maintenant à seulement 1,49€/mois au lieu de 2,99€. Profitez de performances optimales et d'un support exceptionnel. 🔥🚀
Vous avez des remarques concernant HTTP/3 ? N’hésitez pas à nous en faire part via la section Commentaires ci-dessous !
