HTTP/3, nouvelle version du protocole de communication web
Le réseau Internet est composé d'une infrastructure physique (routeurs, câbles, émetteurs et récepteurs d'ondes électromagnétiques...) et de différents protocoles et systèmes de communication (WiFi, TCP, UDP, IP, DNS...). Et les services constitués sur ce réseau (web, email, SSH, FTP, etc.) Ils ont aussi leurs propres protocoles. Or, le web est principalement basé sur le format HTML (format utilisé pour écrire et coder des pages web) et sur le protocole de communication HTTP.
Les acronymes HTTP signifient HyperText Transfer Protocol, c'est-à-dire le protocole de transfert hypertexte. Ce protocole définit la communication entre le navigateur Web et un serveur Web, de sorte que les navigateurs le montrent au début des adresses Web « http:// » (ou « https:// » sur des sites Web sécurisés). Le protocole HTTP établit comment le navigateur doit coder la requête de page au serveur (GET, POST, HEAD, PUT, DELETE ou tout autre type de requête, comment les paramètres et les cookies seront envoyés…) et comment le serveur répondra (une page web codée en HTML ou une erreur: Erreur 404 lorsque l'adresse n'existe pas, 301 lorsque l'adresse a été redirigé, 403 lorsque nous n'avons pas la permission d'accéder à la page, 500 quand une erreur s'est produite sur le serveur, etc. ).
Historique Protocole HTTP
L'inventeur du site Sir Tim Berners-Lee a créé en 1989 le web, le protocole HTTP et le format HTML. W3C ou World Wide Web Consortium, créé par Berners-Lee lui-même et qui dirige actuellement, a guidé l'évolution de trois à des dates récentes: Le format HTML est géré par le groupe WHATWG depuis 2019 et le protocole HTTP est entre les mains de l'IETF ou d'Internet Engineering Task Force ces dernières années.
Dans cette première version, seules les requêtes GET existaient et la réponse était toujours une page web. Cette version a été publiée comme version 0.9 de la norme en 1991. En 1996, la version HTTP 1.0 a été publiée avec plus de types de requêtes et de réponses et d'en-tête. Et en 1997 la version HTTP 1.1 a été lancée, dont la principale nouveauté était que tous les composants qui composent une page web (page HTML, images, fichiers CSS et Javascript...) pouvaient être téléchargés par une seule connexion, contrairement aux versions existantes qui exigeaient une nouvelle connexion pour chacune d'elles.
HTTP/2, publié en 2015. Il était basé sur le protocole expérimental SPDY développé par Google, sur lequel nous avons écrit en 2013. Sa nouveauté et ses avantages consistaient à utiliser une connexion unique pour toutes les requêtes de page effectuées sur un serveur, que le serveur puisse envoyer des notifications push au navigateur et envoyer les en-têtes compressés.
Caractéristiques HTTP/3
Le HTTP/3 a une histoire similaire à HTTP/2, car il a derrière lui un protocole expérimental créé par Google en 2012, dans ce cas QUIC. Les acronymes indiquent Quick UDP Internet Connections, et comme indiqué dans elle, deux sont les principales caractéristiques ou nouveautés du HTTP/3 : rapidité et utilisation du protocole UDP.
En fait, les versions précédentes de HTTP utilisaient le protocole TCP (Transmission Control Protocol) dans la couche de transport inférieure pour amener les paquets de données du navigateur au serveur et vice versa. La caractéristique principale de ce protocole est qu'il garantit la fiabilité des données: les paquets de données sont envoyés ordonnés, disposent de mécanismes pour assurer l'intégrité de chacun d'eux, et après chaque paquet un accusé de réception est attendu avant d'envoyer le suivant; si l'accusé de réception n'est pas reçu, le pack est renvoyé. Il est donc fiable, mais il est également relativement lent en raison des données supplémentaires qu'il envoie et de la nécessité d'attendre les messages de confirmation de réception.
Au contraire, QUIC utilise le protocole UDP (User Datagram Protocol) dans la couche de transport. Dans UDP l'expéditeur envoie les packs et le point, que ce soit arrivé au destinataire ou non et si les packs ont été perdus sur la route ont été perdus. N'ayant pas besoin de confirmation périodique, il est plus rapide. Sur le web, cependant, il est important que tous les paquets de données arrivent bien, pensons s'ils manquent sur un site web ou se trompent des fragments de texte ou des images. Il est certain que lorsque le web a été créé le réseau était différent de l'actuel, il y avait plus d'erreurs dans les communications et c'est pourquoi des mécanismes étaient nécessaires pour assurer la fiabilité, mais aujourd'hui ils sont moins nécessaires. En outre, le QUIC a mis en place plusieurs mécanismes pour demander et renvoyer les parties perdues et éviter ces erreurs.
En 2015, le protocole QUIC a été transmis à l'IETF, en proposant son intégration dans la version suivante du protocole HTTP, et après plusieurs modifications et améliorations, le groupe l'a accepté comme proposition de la nouvelle norme en 2018: Ils ont appelé HTTP/3.
Bien que l'objectif et la principale réalisation du HTTP/3 soit l'augmentation de la vitesse des communications Web, il est évident qu'il ne s'agit pas seulement d'une simple amélioration technique : depuis sa création et après avoir été basé sur le protocole de transport TCP pendant près de 30 ans, le protocole HTTP, base du web, est passé à utiliser UDP.
Mise en œuvre et diffusion
Étant son créateur, Google utilise depuis des années QUIC pour les communications entre son navigateur Chrome et certains de ses services (Gmail, Drive, Youtube...). Chrome lui-même et d'autres navigateurs (Firefox, Safari, Edge...) ont commencé à implémenter HTTP/3 cette année, mais pour l'instant il ne vient pas par défaut, qui veut l'utiliser ou essayer doit changer les paramètres manuellement. Mais, bien sûr, tout le monde utilisera le HTTP/3 par défaut.
Cependant, pour pouvoir utiliser HTTP/3, il est également nécessaire de le placer sur les serveurs web. Vu qu'il améliore la vitesse, les principaux services Web et les réseaux sociaux vont probablement le mettre bientôt. Sur d'autres sites, comme d'habitude, vous aurez besoin de plus de temps.
Dans tous les cas, le changement viendra. En outre, pour les utilisateurs sera inconscient que nous ne remarquerons que la vitesse du web sera améliorée (ou peut-être aussi parce que le poids des sites est de plus en plus). Mais ce type d'amélioration est important pour que le web ne perde pas de compétitivité et donc son influence et sa présence face à des applications qui utilisent d'autres protocoles non standard et cachés.
Zu idazle
Zientzia aldizkaria
