Discussion :

[Hinault Romaric]

Google dévoile son nouveau protocole QUIC dans Chrome
qui combine le meilleur de TCP et UDP

Après le protocole SPDY, permettant d’accélérer le Web en compressant les requêtes d’une page Web, Google expérimente un nouveau protocole qui offrira comme le précédent une vitesse de chargement des pages optimisée.

Le géant de la recherche vient de dévoiler un premier aperçu du protocole expérimental Quick UDP Internet Connections (QUIC), dans la dernière version de son navigateur sur le canal Canary.

QUIC a pour objectif de faire évoluer le protocole TCP en tirant parti des avantages qu’offre UDP. Le protocole repose sur un multiplexage de flux au dessus d’UDP, pour permettre des transmissions fiables en mode connecté, avec une rapidité comparable à UDP.

Le protocole permettrait de n’effectuer aucun aller-retour pour l’envoi des fichiers et optimiserait la connexion depuis un terminal mobile, selon Google.

Google affirme avoir travaillé à la fois sur une implémentation côté client de QUIC et sa mise en œuvre côté serveur depuis février. Les premiers tests de connectivité UDP ont été prometteurs, ce qui a poussé la firme à ouvrir le protocole à un pourcentage d’utilisateurs abonnés aux canaux « canary » et « developer ».

La firme souhaite obtenir un retour sur les avantages et les inconvénients de son nouveau protocole dans le monde réel. Le protocole devrait offrir :

• une haute sécurité similaire à TLS ;
• une rapide connectivité comme TLS Snapstart combiné à TCP Fast Open ;
• la stimulation de paquets afin de réduire la perte de ceux-ci ;
• la correction d'erreur des paquets pour réduire la latence de retransmission ;
• le transport UDP pour éviter les blocages TCP ;
• Un mécanisme de contrôle de congestion fiable.

Google espère mettre QUIC à la disposition des utilisateurs dans la prochaine version stable de Chrome et faire évoluer le Web vers celui-ci.

Un pari que la firme a déjà gagné avec SPDY, qui est désormais supporté par les navigateurs Firefox, Opera et tout récemment Internet Explorer.

Source : Google


Et vous ?

Que pensez-vous de ce nouveau protocole ?

[shkyo]

Et avec la backdoor qui va bien pour la NSA?...

Bon ok je sors...

[Linunix]

Et vous ?

Que pensez-vous de ce nouveau protocole ?

L'idée en soit, est plus qu'intéressante, combiner les possibilités du TCP, avec la rapidité de l'UDP est vraiment bien.

Je pense aussi, que ça pourrait être utiliser pour d'autres projets, et pourquoi pas par d'autres industries... Qui sait (?)

En général, je trouve que ce protocole doit être bien. ^^

[Stéphane le calme]

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 ?

[RyzenOC]

Juste une question: il y'a un risque pour que l'on se retrouve avec une moitié de site ?
Ou bien ils contrôle les données ?

[Matthieu Vergne]

Juste une question: il y'a un risque pour que l'on se retrouve avec une moitié de site ?
Ou bien ils contrôle les données ?

Si j'en crois l'article, a priori c'est fiable :

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.

Par contre je sais pas si c'est une fiabilité stricte (qui garantie la réception) ou non (qui garantie jusqu'à un certain taux).

[RyzenOC]

En parlant de fiabilité, c'est ce genre de désagrément a qui je faisait allusion.

[Matthieu Vergne]

Ah ben après il y a les erreurs de transmission, et pour ça il y a des techniques. Mais la fiabilité 100% partout n'existe pas. Le tout est de savoir si le protocole QUID assure la fiabilité comme TCP, n'assure rien comme UDP, ou fait un entre deux. Les erreurs de transmission n'en resteront pas moins présentes.

Edit: après relecture mon post reste assez interprétable, dans le sens ou TCP gère les erreurs de transmissions aussi, mais c'est au niveau de la communication. Si un bug arrive avant ou après la transmissions du paquet, TCP ne le gère pas. C'est dans ce sens plus large que je parlais d'erreurs de transmission : sur toute la chaîne de traitement (partout) et non juste entre l'envoi et la réception.

[tes49]

Salut

C'est beau tout ça, mais comme j'ai pus le voir ses derniers temps sur un autre forum, Chrome autorise la connexion à des sites dont le système de chiffrement est obsolète !... et c'est bien dommage pour l'utilisateur que celle-ci ne soit pas bloqué ! Et en plus cela pousserait les sites en question à se mettre à jour plus rapidement et à mieux sécuriser la connexion !! Surtout quand il s'agit de sites liés à nos finances !

Bref Chrome fait le beau devant l'utilisateur en autorisant de telles connexions, mais en ce qui concerne ce qui n'est pas en vue, l'utilisateur n'est pas vraiment protégé !

[Matthieu Vergne]

Salut

C'est beau tout ça, mais comme j'ai pus le voir ses derniers temps sur un autre forum, Chrome autorise la connexion à des sites dont le système de chiffrement est obsolète !... et c'est bien dommage pour l'utilisateur que celle-ci ne soit pas bloqué ! Et en plus cela pousserait les sites en question à se mettre à jour plus rapidement et à mieux sécuriser la connexion !! Surtout quand il s'agit de sites liés à nos finances !

Bref Chrome fait le beau devant l'utilisateur en autorisant de telles connexions, mais en ce qui concerne ce qui n'est pas en vue, l'utilisateur n'est pas vraiment protégé !

Ce que, tu en conviendras, est un peu hors sujet. {'^_^}

Ce n'est pas parce que Chrome fait de la merde quelque part qu'il fait de la merde partout. Personne n'est parfait, et il est toujours facile de trouver au moins un défaut à critiquer, quel qu'il soit. Cela dit, ça n'apporte rien à la discussion (à part du troll si mal utilisé) si le sujet est tout autre.

[tes49]

Oh-la-la, faut pas t’exciter !! je donnais juste un avis, même si ce n'est pas un avis technique en ce qui concerne le sujet exacte, ce qui n'empêche pas de faire du croisé... mais en tout cas, ce n'est pas pour troller !

D'ailleurs, tu t'emporte à mettre le mot "merde" à 2 fois, alors que je n'ai pas insulté Chrome une seule fois ! Donc un peu de respect dans tes propos serait bienvenu. Et avec de simples remarques comme j'ai fais, non ce n'est pas de la critique facile, mais de la critique constructive pour l'utilisateur.

Bref, je vous dire simplement que c'est bien beau de sortir de nouvelles technologies, mais ne faudrait-il pas appliquer celles déjà existantes !? Et pour le bien de l'utilisateur !

[Matthieu Vergne]

Mais je m'excite pas, enfin ! {'>.<}

J'espérais que mon émoticone serait assez explicite pour ça, mais c'est visiblement pas le cas. Maintenant si mon message te donne cette impression, alors relis le tiens avec tous ses points d'exclamations, et je pense que tu pourras en dire autant si ce n'est plus.

Faut-il spammer d'émoticones pour pas se faire taxer d'excité ? {;o;}/ {'-_-}

[tes49]

Désolé si je n'ai pas compris ton émoticône qui pour moi est un peu passé inaperçu ! Genre d'émoticônes qui je penses que tu conviendras, ne sont plus vraiment utilisés, moi-même ne les utilisant plus très souvent... et donc j'ai fais plus attention à tes propos.

Bon j'arrête là, parce que maintenant on est vraiment hors-sujet.

Bonne soirée.