Vous vous souvenez peut être de SPDY, le protocole de Google (déjà évoqué dans ce journal) visant à remplacer HTTP. Google souhaite désormais s'attaquer à la couche en dessous, à savoir TCP, et a dans ce sens dévoilé QUIC (Quick UDP Internet Connections) qui se base sur les acquis obtenus lors du développement de SDPY.
NdM : merci à erdnaxeli pour son journal.
Le principal problème auquel veut répondre Google est la latence. S'il est certain que le débit va s'améliorer au fil des années, la latence est elle due à la vitesse de la lumière et ne peut pas être baissée par le réseau physique (ou alors de très peu) : il faut donc améliorer les protocoles. SPDY répond en partie à cela en multiplexant les connexions HTTP dans une seule connexion TCP, mais TCP n'est pas prévu pour cela et un paquet perdu dans une connexion HTTP ralentira toutes les autres passant par cette connexion TCP. De plus une connexion TCP demande de nombreux allers-retours (round trip time ou RTT), encore plus lorsqu'on ajoute le protocole de sécurité TLS, éléments irréductibles qui augmentent la latence.
Il faut donc améliorer TCP, mais s'y attaquer directement nécessiterait beaucoup de temps pour que les modifications soient appliquées sur l'ensemble du réseau et que l'on puisse en profiter (Google estime cette durée à une dizaine d'années). Créer un nouveau protocole pour remplacer TCP ou UDP nécessite aussi de modifier le système d'exploitation et prendrait du temps à être implémenté partout. De plus, ce nouveau protocole risquerait d'être bloqué par les nombreux éléments du réseau qui n'autorisent que les protocoles TCP ou UDP.
Partant de tout cela, Google a choisi d'implémenter QUIC au dessus du protocole UDP afin que les bénéfices puissent en être tiré rapidement (d'ici un à deux ans selon Google), en espérant que les améliorations seront petit à petit incluses dans TCP.
Voici quelques uns des buts de QUIC :
- fonctionner sur l'Internet d'aujourd'hui (d'où le protocole au-dessus de UDP) ;
- sécurité au même niveau que TLS ;
- réduction des RTT, avec pour but de pouvoir rouvrir une précédente connexion avec 0 RTT (utilisation pour cela d'identifiants uniques ou GUID) ;
- mécanisme de congestion, de gestion des erreurs et de retransmission des paquets comme le fait TCP actuellement ;
- meilleurs gestion du multiplexage des connexions ;
- améliorer la connexion sur mobile (TCP se dégrade par ondes radio).
SCTP et DTLS semblent déjà offrir des mécanismes similaires, mais ces protocoles n'ont pas été conçu selon Google pour réduire la latence, et le nombre de RTT d'une connexion SCTP par dessus DTLS est trop élevé pour répondre aux critères fixés.
Si vous voulez en savoir plus, vous pouvez consulter la FAQ ou la description de l'architecture de QUIC. Les premières expérimentations en conditions réelles devraient avoir lieu prochainement avec les canaux dev et canary de Chromium et quelques serveurs de Google.
Aller plus loin
- Journal à l'origine de la dépêche (141 clics)
- Annonce de QUIC (110 clics)
# C'est quoi la différence avec openonload?
Posté par alpha_one_x86 (site web personnel) . Évalué à 3.
C'est quoi la différence avec openonload en terme de réduction des latence?
http://www.openonload.org/
Surtout que le projet est déjà en place.
Ca utilise le mode connecté? Ca peu être utilisé dans les FPS en ligne?
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: C'est quoi la différence avec openonload?
Posté par BFG . Évalué à 6.
Pour les jeux rapides en ligne, la latence est tellement importante que l'on peut se permettre de perdre des paquets : un paquet arrivant trop tard est un paquet de toute manière sans intérêt, le renvoi de paquets (que font TCP et QUIC) n'est donc pas souhaité.
Voir ces deux articles.
[^] # Re: C'est quoi la différence avec openonload?
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
Petite perle dans le deuxième article :
C'est pareil avec le vrai streaming multimédia (je ne parles pas des youtube & co qui sont du téléchargement avec lecture anticipée). les protocoles comme RTP fonctionnent directement sur UDP et on ne veut surtout pas se préoccuper d'un paquet en retard qui n'a plus aucune valeur. D'ailleurs en RTP le client ne fait aucune requête…
ce commentaire est sous licence cc by 4 et précédentes
# QUIC et SSL/TLS
Posté par Almacha (site web personnel) . Évalué à 4.
Je vois que la cryptographie est built-in dans QUIC (et indispensable). Si HTTPS est utilisé au dessus de QUIC est-ce que la crypto est celle de QUIC ou est-ce que la couche SSL/TLS est toujours ajoutée au dessus ?
Cela signifie-t-il qu'il est impossible d'utiliser QUIC sur un serveur si on n'a pas de certificat SSL ? En particulier toutes les utilisations du Web n'ont pas besoin de SSL/TLS, dans tous ces cas QUIC est donc inutilisable ? Ou peut-être qu'après tout ça ne mange pas de pain d'activer SSL partout…
# Latence et vitesse de la lumière
Posté par Jonathan ILIAS-PILLET (site web personnel) . Évalué à 4.
C'est une sérieuse réduction du problème :
- en dessous de la couche 4, il y a encore 3 couches qui ont potentiellement un impact sur la latence ;
- l'infrastructure réseau est constitués d'équipements électroniques (ou ordinateurs peu importe) qui eux-même introduisent une latence (temps de réponse).
Bon, ça ne retire rien au reste de cet article intéressant, c'est juste que j'ai accroché là dessus.
[^] # Re: Latence et vitesse de la lumière
Posté par erdnaxeli (site web personnel) . Évalué à 2.
C'est vrai qui c'est assez réducteur et j'aurais peut être pu mieux le formuler. Google dit à ce propos :
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Latence et vitesse de la lumière
Posté par alpha_one_x86 (site web personnel) . Évalué à 3.
Après rallonger les distances max de fibre permet de contourner le problème (certain bosse dans ce sens). Je note aussi que google fait beaucoup de commit pour améliorer les couches réseaux de linux et des équipement.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
# Typo
Posté par djano . Évalué à 5.
C'est "SPDY".
[^] # Re: Typo
Posté par ariasuni . Évalué à 2.
D’ailleurs ça se prononce «Speedy».
Écrit en Bépo selon l’orthographe de 1990
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.