Google projette de proposer son protocole QUIC à l'IETF

Pour un internet plus rapide

Google a annoncé sur son blog dédié à Chromium son intention de proposé à l’IETF (Internet Engineering Task Force, un groupe international qui participe à l’élaboration des standards Internet) son protocole réseau QUIC (Quick UDP Internet Connections) qui est décrit comme étant un protocole de transport basé sur UDP adapté à l’internet moderne.

Pour rappel, c’était en juin 2013 que Google a révélé pour la première fois QUIC et l’a intégré à Chrome Canary. L’année d’avant, l'ingénieur Yuchung Cheng expliquait que pour contourner les limitations de TCP, le navigateur web ouvre plusieurs connexions parallèles ; un mécanisme qui résulterait cependant en plusieurs temps de latence. Le protocole procède en effet à une première vérification en envoyant tout d'abord trois paquets avant de finaliser l'intégralité du transfert. Aussi, même si le protocole est encore en phase expérimentale et qu’il embarque déjà de nombreuses fonctionnalités, son objectif premier est de prendre le meilleur de TCP (pour son mécanisme de vérification et ses possibilités de chiffrement) et d'UDP (pour la rapidité du transfert, un protocole qui est souvent utilisé pour les jeux, les streaming de média mais aussi les services VoIP) avec la mise en place de QUIC.

Il faut dire que UDP est beaucoup plus léger que TCP, mais en contrepartie, il dispose de beaucoup moins de services de correction d'erreur que TCP. Cela signifie que le serveur d'envoi ne communique pas constamment avec le serveur de réception pour vérifier par exemple si les paquets sont arrivés ou s’ils sont arrivés dans le bon ordre. C’est la raison pour laquelle UDP est idéal pour les services de jeux. Lorsque vous sollicitez ce type de service, vous voulez de faible surcharge pour réduire la latence et si le serveur n'a pas reçu votre dernier mouvement de la souris, il n’est pas nécessaire de perdre une seconde ou deux pour résoudre ce problème parce que l'action a déjà évoluée. A contrario, vous ne voudriez probablement pas l'utiliser pour envoyer des requêtes à un site Web parce que vous ne pourrez pas garantir que toutes les données soient effectivement reçues. C’est la raison pour laquelle Google a voulu combiner le meilleur de TCP et UDP avec des outils modernes de sécurité.


Sur une connexion sécurisée typique TCP, il faut généralement deux ou trois aller-retour avant que le navigateur puisse effectivement commencer à recevoir des données. En utilisant QUIC, un navigateur peut immédiatement commencer à communiquer avec un serveur auquel il a déjà eu affaire avant. Le résultat est un chargement plus rapide des pages et Google soutient que 75% des connexions peuvent tirer profit de cette fonctionnalité zéro aller-retour. QUIC introduit également quelques nouvelles fonctionnalités comme le contrôle de congestion et de retransmission automatique, le rendant ainsi plus fiable qu’un protocole purement UDP.

Avec SPDY, qui est devenu plus tard la base de la norme HTTP / 2, Google a déjà développé un autre protocole alternatif qui partage de nombreux objectifs avec QUIC, cependant HTTP / 2 fonctionne toujours avec TCP. Aussi, s’il est raisonnable de se demander pourquoi Mountain View ne s’est juste pas évertué à améliorer le protocole TCP, l’entreprise a souligné un problème selon lequel le support de TCP est souvent embarqué directement dans le noyau des systèmes d’exploitation (et c’est quelque chose qui se trouve en dehors du contrôle de Google). « QUIC nous permet de tester et d’expérimenter de nouvelles idées, et nous pouvons obtenir des résultats au plus vite » a expliqué l’équipe en charge de ce projet pour justifier sa décision. « Nous espérons que les caractéristiques de QUIC vont migrer vers TCP et TLS si elles s’avèrent efficaces » a-t-elle continué.

QUIC traite actuellement « environ la moitié de toutes les demandes » de Chrome vers les serveurs Google. Google voudrait encore effectuer une montée en puissance du trafic QUIC, et prévoit, à terme, de le faire devenir le protocole de transport par défaut des clients de Google (et pas seulement Chrome, mais toutes les applications mobiles de l'entreprise) pour les serveurs de Google.

« Pendant le dernier trimestre, nous avons augmenté la quantité de trafic des services de Google qui font usage de QUIC et nous avons analysé les performances de QUIC. Les résultats sont de très loin positifs, avec des données qui nous montrent que QUIC fournit une réelle amélioration des performances par rapport à TCP grâce à son établissement de connexion à faible latence, son contrôle de congestion amélioré mais également son meilleur recouvrement de perte », a expliqué Google

Google dit qu'il a vu une amélioration de trois pour cent en moyenne sur les temps de chargement avec QUIC sur Google Search. Si cela ne semble pas énorme, il faut se rappeler que Google Search est dans une politique d’optimisation maximale. Les autres sites (et particulièrement les applications Web avec une latence lourde) observeront probablement de meilleures améliorations. Les utilisateurs qui se connectent à YouTube avec QUIC ont rapporté environ 30 pour cent moins de temps à « regarder le spinner et plus de temps à regarder les vidéos ». Notons également qu’en raison de l'amélioration du contrôle et de la perte de la congestion de QUIC, les utilisateurs utilisant une connexion plus lente ont également expérimenté une amélioration des délais de chargement des pages.

Si vous voulez savoir si votre connexion à Chrome utilise QUIC, vous pourrez utiliser une extension Chrome qui vous fournira des détails sur l’utilisation de QUIC. Il vous suffira d’entrer dans la barre d’adresse chrome://net-internals/#quic.

extension indicateur HTTP/2 et SPDY

Source : blog Chromium, FAQ QUIC (Google Doc)

Et vous ?

Que pensez-vous de QUIC ?