Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Google projette de proposer son protocole QUIC à l'IETF
Pour un internet plus rapide

Le , par Stéphane le calme

21PARTAGES

0  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 20/04/2015 à 18:29
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.
1  0 
Avatar de RyzenOC
Inactif https://www.developpez.com
Le 20/04/2015 à 11:48
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 ?
0  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 20/04/2015 à 15:07
Citation Envoyé par sazearte Voir le message
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 :
Citation Envoyé par Stéphane le calme Voir le message
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).
0  0 
Avatar de RyzenOC
Inactif https://www.developpez.com
Le 20/04/2015 à 18:01
En parlant de fiabilité, c'est ce genre de désagrément a qui je faisait allusion.
0  0 
Avatar de tes49
Membre confirmé https://www.developpez.com
Le 21/04/2015 à 19:00
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é !
0  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 21/04/2015 à 19:06
Citation Envoyé par tes49 Voir le message
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.
0  0 
Avatar de tes49
Membre confirmé https://www.developpez.com
Le 21/04/2015 à 19:29
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 !
0  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 21/04/2015 à 19:39
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;}/ {'-_-}
0  0 
Avatar de tes49
Membre confirmé https://www.developpez.com
Le 21/04/2015 à 19:51
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.
0  0