La firme Google ne fait pas que proposer un moteur de recherche, des web applications et des smartphones et autres broutilles. Elle cherche aussi à améliorer les transferts entre les serveurs et les ordinateurs. Si elle ne peut pas intervenir dans les infrastructures permettant le transport des données au niveau des pays, elle s’est tout naturellement penchée sur le protocole de transport de celles-ci. Depuis 2013, date de l’annonce publique de ce nouveau protocole réseau à usage général proposé par Google des milliers de tests ont été effectués. Il y a quelques semaines, l’Internet Engineering Task Force (IETF), l’organisation qui définit de nombreux standards pour le web à valider ce nouveau moyen de transport. Son nom ? Quic le protocole de transmission de demain par Google.
Kezako Quic ?
Quic est le nom de ce mode de transports des données et nullement un acronyme. Il a été conçu en 2012 par Jim Roskind employé chez Google et a été nommé un temps TCP / 2, en référence au mode actuel de transmission des données par paquet TCP. Implanté sur le navigateur Google Chrome, il est utilisé actuellement dans la moitié de toutes ses connexions avec les serveurs de Google. Les autres navigateurs Microsoft Edge, Firefox, mais aussi Safari le prennent en charge, mais il n’est pas activé par défaut. Si en juin 2015, une ébauche de spécification a été présentée à l’Internet Engineering Task Force (IETF), c’est en mai 2021 que QUIC est devenu un standard de transport de données.
TCP vs QUIC
Tout d’abord, chaque fois que vous consultez une page web, ne serait-ce qu’en inscrivant l’url dans l’omnibox du navigateur Google Chrome et en appuyant sur la touche Entrée du clavier, vous envoyez une donnée. En retour, s’affiche sur la page du navigateur un certain nombre d’informations qui ont été transmises par ce que l’on appelle des paquets. Ils sont transmis à partir du serveur contenant l’information. Par exemple, une page web, qui va les envoyer vers votre ordinateur en la fragmentant. D’un poids de 512 Ko, chaque paquet comprend un entête avec un numéro de séquence permettant de savoir si l’un d’eux a été perdu ou s’il est arrivé dans le désordre, et une somme de contrôle permettant de détecter les erreurs dans les données des paquets.
La transmission des informations en mode TCP peut être ralentie par l’encryptage des données. Ainsi si elles doivent être cryptées à l’aide de TLS appelée aussi couche de transport sécurisé, une succession d’échange entre le serveur et l’ordinateur auront lieu entraînant une surcharge importante à la transmission globale et donc un temps plus important pour l’affichage complet de la page web demandée.
Avec QUIC ces identifications, mais aussi ces échanges seront plus rapides. En effet, il s’appuie sur la compréhension du comportement du trafic http (Hypertext Transfer Protocol). Ainsi lorsque vous ouvrez une connexion, le paquet de réponse inclut les données nécessaires aux futurs paquets pour utiliser le cryptage. Est éliminé le besoin de configurer la connexion TCP, puis de négocier le protocole de sécurité via des paquets supplémentaires. Ceci entraîne de facto un temps plus court dans l’arrivée des informations qui s’afficheront sur votre écran.
Un second changement pour le protocole de transmission de demain par Google
Le deuxième changement concerne l’utilisation non pas du mode TCP mais d’UDP. Comme l’indique le site Widipédia, “User Datagram Protocol (UDP, en français protocole de datagramme utilisateur) est un des principaux protocoles de télécommunication utilisés par Internet”.” Aucune communication préalable n’est requise pour établir la connexion, au contraire de TCP (qui utilise le procédé de handshaking). UDP utilise un mode de transmission sans connexion.”. L’intérêt d’utiliser l’UDP est que si une erreur se produit dans un flux, la pile de protocoles peut continuer à desservir d’autres flux indépendamment. Cela peut être très utile pour améliorer les performances sur les liaisons sujettes aux erreurs.
Ainsi alors que le protocole TCP va vider ou même bloquer l’arrivée des paquets si une erreur est constatée et tenter de la réparer pour ensuite reprendre l’arrivée des autres paquets, Quic va permettre de continuer à recevoir les données tout en essayant de récupérer le paquet manquant. Vous aurez compris que le gain au niveau de l’affichage des données peut être appréciable.
Quic le protocole de transmission de demain par Google
En standardisant ce protocole de transmission, l’IETF a fait un joli cadeau à Google. Il est certain que demain de nombreux acteurs du web et de l’Internet vont s’élever une nouvelle fois contre la place de plus en plus importante que prend la firme de Mountain View. Il faut quand même reconnaître que personne n’a forcé la main à cet organisme pour officialiser ce protocole de transmission.
Mais soyons honnête avec nous-mêmes. Si Google a voulu ce protocole ce n’est pas pour les beaux yeux des utilisateurs, mais simplement pour ne pas les perdre. En effet, plus vite l’information arrive, plus le “consommateur” reste cantonné à ce qu’il veut lire ou regarder. Ne pas lui proposer dans l’instant, c’est courir le risque qu’il se tourne sur un autre support et donc qu’il ne puisse pas voir la publicité qui lui est destiné. Quic est à rapprocher de FLoC qui individualise et rend anonyme à partir du navigateur les données de l’utilisateur. Quic et FLoC seront-ils les Quick & Flupke de demain ? À suivre !
Que pensez-vous de ce nouveau mode de transport de données ? Est-ce que vous pensez que cela va vous aider à mieux afficher les pages web que vous consultez ?
