Le protocole QUIC désormais normalisé

119
29
mai
2021
Internet

Le protocole de transport QUIC (couche 4 du modèle OSI) vient d’être normalisé, sous la forme de plusieurs RFC. QUIC, déjà largement déployé, peut changer pas mal de choses sur le fonctionnement de l’Internet, en remplaçant, au moins partiellement, TCP. C’est quoi, QUIC, et à quoi ça sert ? Logo du groupe de travail QUIC

Sommaire

Couche transport

QUIC n’est pas un protocole d’application (couche 7) comme peuvent l’être HTTP ou SSH. Les utilisateurs ordinaires ne verront pas la différence, ils se serviront des mêmes applications, via les mêmes protocoles applicatifs. QUIC est un protocole de transport (couche 4 du traditionnel modèle en couches OSI), donc un concurrent de TCP, dont il vise à résoudre certaines limites, notamment dans le contexte du Web.

Quelles limites ? Pour comprendre, il faut revenir à ce à quoi sert la couche de transport.

Placée entre les paquets d’IP, qui peuvent arriver ou pas, dans l’ordre ou pas, et les applications, qui comptent en général sur un flux d’octets ordonnés, où rien ne manque, la couche transport est chargée de surveiller l’arrivée des paquets, de signaler à l’émetteur qu’il en manque pour qu’il puisse réémettre, et de mettre dans le bon ordre les données. Dit comme ça, cela semble simple, mais cela soulève beaucoup de problèmes intéressants. Par exemple, il ne faut pas envoyer toutes les données sans réfléchir : le réseau n’est peut-être pas capable de les traiter, et un envoi trop brutal pourrait mener à la congestion du réseau. De même, en cas de pertes de paquet, il faut certes ré-émettre, mais aussi diminuer le rythme d’envoi, la perte pouvant être le signal que le réseau est saturé. C’est à la couche transport de gérer cette congestion, en essayant de ne pas la déclencher ou en tout cas de ne pas l’aggraver. En pratique, la couche transport est donc très complexe, comme le montre le nombre de RFC sur TCP.

Maintenant que nous avons révisé les tâches de la couche transport, quelles sont ces limites de TCP dont je parlais, et qui justifient le développement de QUIC ?

Notez d’abord qu’elles ont surtout été mentionnées dans le contexte du Web. Celui-ci pose en effet des problèmes particuliers, notamment le désir d’une faible latence (quand on clique, on veut une réponse tout de suite) et le fait que l’affichage d’une seule page nécessite le chargement de plusieurs ressources (images, vidéos, code JavaScript, CSS, etc). La combinaison de TCP et de TLS n’est pas satisfaisante question latence, puisqu’il faut d’abord établir la connexion TCP, avant de pouvoir commencer la négociation qui mènera à l’établissement de la session TLS. Ensuite, TCP souffre du manque de parallélisme : quand on veut récupérer plusieurs ressources, il faut soit ouvrir plusieurs connexions TCP, qui ne partageront alors plus d’information (délai aller-retour, taux de perte, etc) ou de calculs (cryptographie…), soit multiplexer à l’intérieur d’une connexion TCP, ce que fait HTTP/2 mais, alors, on risque le head-of-line blocking, où la récupération d’une ressource bloque les suivantes, et le fait que la perte d’un seul paquet va faire ralentir tous les téléchargements.

QUIC en deux mots

Quels sont les concepts de base de QUIC ? QUIC gère des connexions entre machines, comme TCP. Par contre, contrairement à TCP, ces connexions portent ensuite des ruisseaux (streams) séparés, ayant leur propre contrôle de congestion, en plus du contrôle global à la connexion. Les ruisseaux peuvent être facilement et rapidement créés. Ce n’est pas par hasard que le concept ressemble à celui des ruisseaux de HTTP/2, dans les deux cas, le but était de s’adapter au désir des navigateurs Web de charger toutes les ressources d’une page en parallèle, sans pour autant « payer » l’établissement d’une connexion pour chaque ressource.

Avec QUIC, le chiffrement est obligatoire. Il n’y a pas de version de QUIC en clair. Non seulement les données applicatives sont chiffrées, comme avec TLS ou SSH mais une bonne partie de la couche transport l’est également. Pourquoi ?

  • En raison de la prévalence de la surveillance massive sur l’Internet ; moins on expose de données, moins il y a de risques.
  • Afin d’éviter que les middleboxes (les boitiers intermédiaires qui regardent au-dessus de la couche 3) ne se croient capables d’analyser le fonctionnement de la couche transport, et ne se croient autorisées à y intervenir, ce qui mènerait à une ossification de l’Internet. Si tout est chiffré, on pourra faire évoluer le protocole sans craindre l’intervention de ces fichus intermédiaires.
  • Certains FAI (Fournisseur d’accès à l’Internet) ont déjà exploité le caractère visible de TCP pour des attaques, par exemple en envoyant des paquets RST (ReSeT) pour couper le trafic BitTorrent. TLS et SSH ne protègent pas contre ce genre d’attaques.
  • L’observation de la couche transport peut permettre d’identifier les services utilisés et d’en dé-prioritiser certains. Le chiffrement du transport peut donc aider à préserver la neutralité du réseau.

On peut prévoir que les habituels adversaires du chiffrement protesteront d’ailleurs contre QUIC, en l’accusant de gêner la visibilité (ce qui est bien le but).

QUIC utilise le classique protocole TLS pour le chiffrement mais pas de la manière habituelle. Normalement, TLS fait la poignée de main initiale, l’échange des clés et le chiffrement des données. Avec QUIC, TLS ne fait que la poignée de main initiale et l’échange des clés. Une fois les clés obtenues, QUIC chiffrera tout seul comme un grand, en utilisant les clés fournies par TLS.

Les détails de mise en œuvre

Puisqu’on a parlé des middleboxes : déployer un nouveau protocole de transport dans l’Internet d’aujourd’hui est très difficile, en raison du nombre d’équipements qui interfèrent avec le trafic (les routeurs NAT, par exemple). Conceptuellement, QUIC aurait pu tourner directement sur IP. Mais il aurait alors été bloqué dans beaucoup de réseaux. D’où le choix de ses concepteurs de le faire passer sur UDP. QUIC utilise UDP comme il utiliserait IP. On lit parfois que QUIC, ce serait « HTTP au-dessus d’UDP », mais c’est une grosse incompréhension. QUIC est une couche de transport complète, concurrente de TCP, dont le fonctionnement sur UDP n’est qu’un détail nécessaire au déploiement. QUIC n’a aucune des propriétés d’UDP. Par exemple, comme TCP, mais contrairement à UDP, QUIC teste la réversibilité du trafic, ce qui empêche l’usurpation d’adresses IP et toutes les attaques UDP qui reposent dessus.

QUIC est parfois présenté comme « tournant en mode utilisateur et pas dans le noyau du système d’exploitation ». En fait, ce n’est pas spécifique à QUIC. Tout protocole de transport peut être mis en œuvre en mode utilisateur ou noyau (et il existe des mises en œuvre de TCP qui fonctionnent en dehors du noyau). Mais il est exact qu’en pratique la plupart des mises en œuvre de QUIC ne sont pas dans le noyau du système, l’expérience prouvant que les mises à jour du système sont souvent trop lentes, par rapport au désir de faire évoluer en permanence la couche transport. Et puis, sur Microsoft Windows, Google, premier promoteur de QUIC, n’aime pas dépendre de Microsoft pour les performances de son navigateur Chrome.

Les normes

Les RFC normalisant QUIC sont :

  • RFC 9000 est la norme principale, décrivant le socle de base de QUIC ;
  • RFC 9001 normalise l’utilisation de TLS avec QUIC ;
  • RFC 9002 spécifie les mécanismes de récupération de QUIC, quand des paquets sont perdus et qu’il faut ré-émettre, sans pour autant écrouler le réseau ;
  • RFC 8999 est consacré aux invariants de QUIC, aux points qui ne changeront pas dans les nouvelles versions de QUIC.

J’ai dit que QUIC, comme TCP, est un protocole de transport généraliste, et qu’on peut faire tourner plusieurs applications différentes dessus. En pratique, QUIC a été conçu essentiellement en pensant à HTTP mais dans le futur, d’autres protocoles pourront profiter de QUIC, notamment s’ils ont des problèmes qui ressemblent à ceux du Web (désir de faible latence, et de multiplexage).

Pour HTTP, la version de HTTP qui tourne sur QUIC se nomme HTTP/3 et sera normalisée dans un futur RFC. Comme HTTP/2, HTTP/3 a un encodage binaire, mais il ne fait plus de multiplexage, celui-ci étant désormais assuré par QUIC.

Le passé

QUIC a eu une histoire longue et compliquée. À l’origine, vers 2012, QUIC était un projet Google. Si les motivations étaient les mêmes que celles du QUIC actuel, et que certains concepts étaient identiques, il y avait quand même deux importantes différences techniques : le QUIC de Google utilisait un protocole de cryptographie spécifique, au lieu de TLS, et il était beaucoup plus marqué pour son utilisation par HTTP uniquement. Et il y a aussi bien sûr une différence politique, QUIC était un protocole privé d’une entreprise particulière, il est maintenant une norme IETF (Internet Engineering Task Force).

Et pour aller encore plus loin

Aller plus loin

  • # Belle rédaction

    Posté par  . Évalué à 10 (+8/-0).

    Et bien si avec tout ce travail de documentation sur QUIC (la version sur le blog est bien longue et multiple), il y a fort à parier que QUIC est populaire.

    Après, va falloir que ça s'installe… Déjà, ce n'est pas facilement disponible en tant que serveur. Heureusement, les clients populaires le supporte.

    Et enfin… Faut que le pare-feu de ma boîte accepte de faire passer l'UDP. C'est pas gagné.

    • [^] # Re: Belle rédaction

      Posté par  (site Web personnel) . Évalué à 8 (+6/-0).

      Pour les serveurs, ça se fera au fur et à mesure. Il y a de très nombreuses mises en œuvre qualité production, il reste à en faire de belles bibliothèques facilement disponibles sur le système d'exploitation de votre choix, puis à intégrer cela dans les logiciels serveurs (si on a déjà du HTTP/2, ce n'est pas trop difficile).
      Pour les pare-feux àlakon, oui, c'est une plaie classique de l'Internet (et une des raisons pour lesquelles on fait tout tourner sur HTTP).

    • [^] # Re: Belle rédaction

      Posté par  . Évalué à 4 (+4/-0).

      Ça me fait penser à la migration vers IPv6 (sans vouloir troller), et du coup, je me demande si le passage de HTTP à QUIC sera utile et généraliser à tous ce qui est Web.
      J'ai en tête plusieurs exemples :
      - les interfaces Web d'administration d'équipements
      - des sites avec peu d'utilisateurs

      Et est-ce que ça ne serait même intéressant que pour les gros site des GAFAM ?

      • [^] # Re: Belle rédaction

        Posté par  . Évalué à 5 (+3/-0).

        C'est intéressant pour les sites web en général, c'est juste que les interfaces de boxes d'une part utilisent de vieux logiciels d'autre part ont des contraintes de déploiement (et encore).

        C'est intéressant dès que le multiplexage est intéressant, donc pour les webservices ça va dépendre de tes usages (si tu as plusieurs appels parallèles ou pas).

        Après on peut en imaginer des choses :

        • ssh peut avoir un stream par shell plus un par tunnel plus un par fichier transmis par sftp
        • xmpp peut avoir une séparation pour chaque média et chaque channel
      • [^] # Re: Belle rédaction

        Posté par  (site Web personnel) . Évalué à 10 (+11/-0).

        La grosse différence avec IPv6 est que la couche 3 affecte tous les routeurs sur le trajet alors que la couche 4 est de bout en bout. Il suffit que client et serveur le fassent.

      • [^] # Re: Belle rédaction

        Posté par  . Évalué à 4 (+3/-1).

        J'ai peut-être mal compris mais QUIC semble aussi intéressant pour avoir des flux cryptés et donc moins sensibles à différents désagréments au niveau des intermédiaires.

        Surtout, ne pas tout prendre au sérieux !

    • [^] # Re: Belle rédaction

      Posté par  (site Web personnel) . Évalué à 8 (+7/-1).

      Clair, les DSI bloquent UDP. C'est déjà galère pour la visio… Les DSI n'aime pas UDP en général ! Au final, on se retrouve souvent à faire des tunnels SSH donc TCP dans TCP pour bosser ;-)

      Bref, ce n'est pas gagné… On voit que TCP et le web (80/443) ont tué tous les autres protocoles / ports !

  • # Chiffrement

    Posté par  . Évalué à 6 (+4/-0).

    Merci pour la dépêche.

    Avec QUIC, le chiffrement est obligatoire.

    Je me demandais à quel point ce serait contraignant. Par exemple pour étudier tcp et udp (en TP), c'est assez facile. Ajouter l'utilisation de certificats (pour ceux qui se demandent on peut créer des certificats pour des adresses ip) va complexifier un peu (ne pas présumer des difficultés que peuvent rencontrer des étudiants…).

    Je présume qu'ils vont contraindre http/3 à fonctionner sur quic, ce qui va poser pas mal de question coté load balancer et terminaison tls. Je ne doute pas que google s'est posé la question, mais je n'ai rien trouvé dessus.

    • [^] # Re: Chiffrement

      Posté par  . Évalué à 4 (+3/-0). Dernière modification le 30/05/21 à 05:48.

      Un load balancer est agnostique. L'IP destination ne sera pas chiffré sinon comment expédier un paquet.

      • Un load balancer entre plusieurs chemins qui mênent à la même destination se fiche de l'IP.
      • Un load balancer qui redirige le trafic entre plusieurs serveurs peut très bien avoir déchiffré le paquet puisqu'il est arrivé à destination. S'il y a trop de trafic pour qu'il soit déchiffré, ce sera en amont, le "DNS" qui aura répartis les IP en fonctions du trafic (Tu te doute que "www.google.com" n'a pas la même IP en France qu'au Japon…). Mais ce dernier cas doit pas concerné beaucoup de site juste les GAFAM et quelques Twitter.
      • [^] # Re: Chiffrement

        Posté par  . Évalué à 3 (+2/-1).

        S'il is très bien tout ça, mais s'il déchiffre (s'il est la terminaison tls), il doit passer à tcp ou udp de l'autre côté. Soit il reimplemente les différences, soit on s'aligne sur tcp avec http…

        J'ai pas de doute que l'IETF a eu le concours de personnes dont c'est la problématique. Je pense surtout à haproxy parce qu'il ne fait que ça (et que je m'en sert), mais il y a aussi varnish dont l'un des dev avait beaucoup parlé lors des travaux sur http2.

        • [^] # Re: Chiffrement

          Posté par  (site Web personnel) . Évalué à 3 (+1/-0). Dernière modification le 30/05/21 à 08:57.

          Et d'ailleurs, c'est un des soucis, c'est compliqué de faire du haproxy avec SSH et je n'ai pas encore trouvé comment, avec du logiciel libre, faire un répartiteur de charge SSH avec gestion de la session (envoyer la personne toujours sur le même nœud s'il avait une connexion pas trop ancienne précédemment…).

          Si le répartiteur de charge voit tout, c'est pas forcément terrible. S'il ne voit rien, c'est pas terrible du tout.

          Bref, sujet complexe.

          • [^] # Re: Chiffrement

            Posté par  . Évalué à 3 (+3/-0). Dernière modification le 30/05/21 à 19:51.

            Le probleme avec un loadbalancer pour du ssh, c'est les clés ssh des serveurs cibles ( les "real servers" en vocabulaire Kemp).

            exemple :
            ssh.toto.com => Load Balancer
            -> Noeud1.internal
            -> Noeud2.internal

            Une fois on va se connecter via le load balancer a Noeud1.internal et recevoir sa clé, un autre jour pour une nouvelle session, on sera dispatché sur Noeud2.internal et le client ssh qui avait associé la clé de Noeud1.internal à ssh.toto.com va se prendre la clé de Noeud2.internal et demander confirmation puisque la clé à changé voire refuser la connexion.

            J'ai le probleme au boulot avec un Kemp Loadmaster (basé sur du Linux avec du haproxy il me semble mais avec interface web et payant) qui repartit la charge sur 2 bastions pour accéder à tous mes serveurs Linux.

            Avec certains clients ssh on peut ignorer la signature mais c'est dommage.

            Probleme absent pour HTTPS puisque le Loadbalancer peut gérer le chiffrement/dechiffrement (exemple publication sur internet il porte un certificat payant ou let's encrypt et les serveurs internes portent des certificat privés donc non soumis à la limite de validité de 13 mois : si public non let's encrypt, moins de serveurs à traiter lors du deploiement du certificat à chaque renouvellement).

            • [^] # Re: Chiffrement

              Posté par  . Évalué à 3 (+2/-1).

              Tu peux utiliser la même clef sur tes nœuds ssh.

              • [^] # Re: Chiffrement

                Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

                Ou tu peux utiliser l’équivalent de DANE pour SSH, à savoir SSHFP.

                • [^] # Re: Chiffrement

                  Posté par  . Évalué à 3 (+1/-0).

                  Je ne connaissais pas, c'est bien plus propre. Il faut avoir dnssec, mais c'est cool. Merci

                • [^] # Re: Chiffrement

                  Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

                  Je n'ai pas compris en quoi ça permet de résoudre le problème ?

                  • [^] # Re: Chiffrement

                    Posté par  . Évalué à 5 (+3/-0).

                    Tu utilise un nom de domaine avec une entrée pour indiquer l’empreinte de leur clef et un domaine principale qui sera un alias des autres (avec CNAME).

                    A moins que je ne me trompe.

                  • [^] # Re: Chiffrement

                    Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

                    Le commentaire de barmic résume bien, mais je veux juste ajouter quelques détails.

                    Le fonctionnement est le suivant : quand tu te connectes à un serveur (ssh root@server.example.com), SSH récupère une les clefs que présente le serveur, mais au lieu suivre le fonctionnement TOFU où tu dois valider manuellement que l’empreinte de la clef est correcte (si elle n’est pas déjà dans le fichier known_hosts), SSH va faire requête DNS pour SSHFP? server.example.com, vérifier que les données sont valides grâce à DNSSEC et comparer l’empreinte de la clef du serveur avec ce qui est configuré dans le DNS.

                    L’avantage c’est que tu contourne complètement TOFU donc tu évites à l’utilisateur de devoir bêtement accepter une clef qu’il ne vérifiera jamais, tu n’as plus besoin de maintenir un known_hosts et tu peux facilement remplacer les clefs d’hôtes au besoin.

                • [^] # Re: Chiffrement

                  Posté par  (site Web personnel) . Évalué à 10 (+8/-0).

                  Ou bien des certificats SSH : des clefs différentes sur chaque machine mais signées par une même clef de confiance, qui est la seule que le client a besoin d’accepter dans son known_hosts.

    • [^] # Re: Chiffrement

      Posté par  (site Web personnel) . Évalué à 9 (+7/-0).

      Il est certain que le chiffrement ajoute de la complexité (dans le contexte des TP, utiliser Wireshark devient plus compliqué, il faut demander une écriture des clés dans un fichier, qu'on fera relire par Wireshark pour qu'il déchiffre le contenu). Mais c'est inévitable de nos jours, les connexions en clair sont vraiment trop vulnérables.
      Philosophons un peu : c'est le sort de toutes les techniques. Au début du 20e siècle, un bricoleur pouvait construire un avion acceptable en assemblant un moteur, des ailes et hop. Aujourd'hui, ce n'est pas envisageable, et les TP pour les étudiants sont donc bien plus difficiles. Même l'ultra-simple Gemini impose TLS :-)
      Et, oui, HTTP/3 ne fonctionne que sur QUIC, dont il utilise toutes les fonctions (vrai parallélisme, QPACK).
      Si le répartiteur de charge termine TLS, pas de problème, il peut relayer comme il veut derrière (nouvelle session QUIC, HTTP/1 ou 2). Sinon, il peut utiliser le Connection ID de QUIC, qui est en clair, pour envoyer tous les paquets d'une même connexion au même dorsal. (Petit piège toutefois car le Connection ID n'est pas forcément constant.)

      • [^] # Re: Chiffrement

        Posté par  . Évalué à 6 (+4/-0).

        Oui oui je suis d'accord, mais dans la pratique je pense que la plupart des étudiants ne verront jamais quic sauf s'il supplente ces prédécesseurs. Je m'occupe uniquement des tp et je fais pas les programmes, mais quand je vois les difficultés pour tcp/udp avec un peu de routage (aussi à cause de la mauvaise image que les gens ont du réseau), je ne les vois pas découvrir tls et quic dans la foulée.

        Oui la traduction de protocole est possible, mais on voit que ça n'a pas été un travail anodin pour y passer avec http2.

        Le coût du connexion id, c'est super cool par contre :) Si ssh y passe n'est là fin de mosh.

      • [^] # Re: Chiffrement

        Posté par  . Évalué à 10 (+11/-0).

        Il est certain que le chiffrement ajoute de la complexité […] mais c'est inévitable de nos jours, les connexions en clair sont vraiment trop vulnérables.

        Oui et justement, peut-être que ce sera une charnière définitive dans l'éducation des informaticiens : "chiffrement first". Je suis de la vieille école qui code d'abord et ajoute la sécurité après. C'est mauvais, très mauvais, mais c'est comme ça : je n'ai jamais parlé de chiffrement lors de mes études, d'aucune manière que ce soit.

        Un élève qui a toujours appris à mettre un certificat de chiffrement dans Wireshark sera déjà bcp plus enclin à changer de paradigme et réellement mettre la sécurité au coeur de son développement.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Chiffrement

          Posté par  . Évalué à 6 (+4/-0).

          Je suis plus pessimiste que toi amha ça va juste réduire ta compréhension initiale. C'est déjà le cas, en soit même pour du réseau simple, peu de gens s'y intéressent.

          Je lui souhaite sincèrement plus de succès qu'ipv6, mais je doute qu'il ai entre dans la majorité des formations (tls n'y figurent pas par exemple).

  • # Origine du nom ?

    Posté par  (site Web personnel) . Évalué à 5 (+4/-0).

    J'ai trouvé bizarre que l'origine du nom QUIC ne soit pas précisée dans la dépêche (intéressante au demeurant) mais je ne l'ai pas trouvée ailleurs non plus.

    Quelqu'un sait ?

    « J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »

    • [^] # Re: Origine du nom ?

      Posté par  (site Web personnel) . Évalué à 10 (+10/-0). Dernière modification le 30/05/21 à 09:57.

      https://en.wikipedia.org/wiki/QUIC Although its name was initially proposed as the acronym for "Quick UDP Internet Connections", IETF's use of the word QUIC is not an acronym; it is simply the name of the protocol. Donc c'était un acronyme, puis on a gardé le nom, mais avec les majuscules, parce que les autres qui sont des acronymes étaient comme ça ?

      La version acronyme était présente dans les documents de 2012 / 2013 de Jim Roskind de Google. Et elle disparaît de la version IETF ensuite.
      https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-34#section-1 (janvier 2021)
      « QUIC: The transport protocol described by this document. QUIC is a name, not an acronym. »

      QUIC est donc rapide et FORT.

      • [^] # Re: Origine du nom ?

        Posté par  (site Web personnel) . Évalué à 4 (+3/-0).

        Thanks. J'aurais pas dû m'arrêter à la page WP française.

        « J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »

      • [^] # Re: Origine du nom ?

        Posté par  . Évalué à 5 (+4/-0).

        J'ai l'impression que QUIC (quick) est dans la continuité de SPDY (speedy), c'est-à-dire des travaux de Google visant l'amélioration des communications. SPDY est devenu http/2 et QUIC devrait être le support de http3. Un simple hasard ou c'est le même communiquant qui a choisi les noms des projets chez Google ?

        • [^] # Re: Origine du nom ?

          Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

          Oui, QUIC et HTTP/3 empruntent pas mal d'idées à HTTP/2, notamment celles des ruisseaux parallèles à l'intérieur d'une même connexion. Et le champ lexical de la vitesse n'a sans doute pas été choisi par hasard :-)

  • # [Quic-Transport] Contrôle d'erreurs

    Posté par  . Évalué à 2 (+2/-0).

    Endpoints SHOULD prioritize retransmission of data over sending new
    data, unless priorities specified by the application indicate
    otherwise; see Section 2.3.

    https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-29#section-13.3

    Donc pour tout ce qui s'appuie sur RTP, par exemple, QUIC pourrait faire office d'un udp chiffré. En plus de remplacer TCP pour les tunnels http.

  • # "ruisseaux"

    Posté par  (site Web personnel) . Évalué à 10 (+16/-3).

    Qui utilise le mot "ruisseau" pour traduire "stream"? Est-ce que "flux" ne serait pas plus usité en français?

    Je veux bien qu'on essaie d'éviter les anglicismes, mais les traductions littérales approximatives, c'est pas toujours mieux pour rendre les choses lisibles et compréhensibles…

    • [^] # Re: "ruisseaux"

      Posté par  . Évalué à 6 (+6/-2).

      Moi j'ai bien aimé. Ça nous changeait un peu. Ce ruisseau m'évoquait un printemps sans orages de grêle.

    • [^] # Re: "ruisseaux"

      Posté par  . Évalué à 10 (+12/-0). Dernière modification le 31/05/21 à 06:02.

      Je ne doute pas que cette traduction ait été choisie volontairement, mais ça reste une faute de traduction qui fait très 'traduction automatique'.
      Les dictionnaires donnent les traductions suivantes pour stream:

      • Ruisseau: (small river)
        A stream flows behind their house.
        Il y a un ruisseau derrière leur maison.

      • Flot: (current flowing steadily)
        There was a stream of good news.
        Il y eut un flot de bonnes nouvelles.

      • Flux: (data: real-time audio or video)
        The audio stream from the web radio station was cut after 20 minutes.
        Le flux audio de la station de radio Internet a été interrompu après 20 minutes.

      La traduction correcte dans ce cas est clairement flux.

      Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.

      • [^] # Re: "ruisseaux"

        Posté par  (site Web personnel) . Évalué à 5 (+6/-3).

        Je trouve que ruisseau est bien approprié, au contraire. Avec cette image, je visualise bien la rivière (la connexion principale) et les ruisseaux (des connexions plus petites et rapides) qui en découlent. C'était très élégant comme analogie.

        • [^] # Re: "ruisseaux"

          Posté par  (site Web personnel) . Évalué à 10 (+14/-0).

          Si l'analogie est élégante, elle est incomplète en plus de ne pas sauter à l'oeil. Il faudrait décrire la connexion en tant que rivière, ce qui n'est pas le cas.

          Ici, on a plus l'impression d'un problème de traduction de stream. Dans dans un contexte informatique, on parle bien de flux. C'est aussi important d'utiliser les termes couramment utilisés pour éviter les ambiguïtés.

          Avec l'usage de ruisseau, sans la traduction entre parenthèse, je n'aurais pas compris la phrase. Alors qu'avec flux cela aurait coulé de source (ou encore cela aurait été claire comme de l'eau de roche) xD

        • [^] # Re: "ruisseaux"

          Posté par  . Évalué à 10 (+8/-0). Dernière modification le 31/05/21 à 10:11.

          Pour ma part, j'avais cru qu'il s'agissait d'un nouveau vocabulaire, référant à une nouvelle logique. J'ai donc été voire la RFC pour voir de quoi il s'agissait et me rendre compte que c'était simplement un "stream" et rien de nouveau :(

          edit : je n'avais pas vu/lu la parenthèse

        • [^] # Re: "ruisseaux"

          Posté par  (site Web personnel) . Évalué à 8 (+6/-0).

          Oui, les petits ruisseaux font une grande rivière.

          En fait, c'est la faute d'Abba "I cross the stream \ I have a dream », ce qui est mieux que « Je traverse la rue \ Je trouve un boulot ».

      • [^] # Re: "ruisseaux"

        Posté par  . Évalué à 3 (+2/-1).

        Une «traduction automatique» venant de Monsieur Bortzmeyer ça m'étonnerait :-)

      • [^] # Re: "ruisseaux"

        Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

        Et comment on traduit "flow", très utilisé dans le RFC ?

    • [^] # Re: "ruisseaux"

      Posté par  (site Web personnel) . Évalué à 6 (+6/-2).

      Qui utilise le mot "ruisseau" pour traduire "stream"?

      Stéphane Bortzmeyer.

    • [^] # Re: "ruisseaux"

      Posté par  (site Web personnel) . Évalué à 7 (+6/-1).

      Flux désigne autre chose. « À l'intérieur d'un ruisseau circule un flux ordonné d'octets. » Le gros problème de flot ou flux, c'est qu'ils sont utilisés pour des tas de choses différentes en réseau.

    • [^] # Re: "ruisseaux"

      Posté par  . Évalué à 1 (+2/-2).

      Le coup de la rivière et des ruisseaux, c'est évocateur, mais pas tant que ça. Le fait que l'eau s'écoule permet au cerveau de se représenter la transmission des données, mais c'est à peut près tout. En plus, ça oriente la visualisation sur un flux unidirectionnel.

      Une analogie avec des torons qui forment une corde me semble pas mal pour parler de la connexion et du multiplexage.

  • # QoS

    Posté par  . Évalué à 3 (+2/-0).

    Il y a quelque-chose de prévu pour faire de la qualité de service? Par exemple pour différencier un paquet qui peut partir à la poubelle ou pour indiquer le besoin en latence?

    • [^] # Re: QoS

      Posté par  . Évalué à 3 (+3/-0).

      Non

    • [^] # Re: QoS

      Posté par  . Évalué à 1 (+2/-1).

      diffserv est au niveau de la couche 3 (IP), donc quic devrait pouvoir en bénéficier

  • # Transfert sur liaison haut débit haute latence

    Posté par  . Évalué à 4 (+3/-0).

    Je suis curieux de voir si ça peut concurrencer UDT/UDR, HPN-SSH ou Aspera pour le cas des transferts sur des grosses liaisons intercontinentales (10Gbps ou plus, 100ms de ping).

    • [^] # Re: Transfert sur liaison haut débit haute latence

      Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

      Déjà, FASP (le protocole derrière Aspera) est un truc privé, fermé et breveté.

      Ensuite, faire passer davantage d'octets par seconde est facile si on ne tient pas compte des autres. Un protocole égoïste va toujours pouvoir faire mieux. Ce n'est pas grave si on a des liens dédiés mais QUIC est fait pour l'Internet ouvert.

      UDT est abandonné, non ?

      HPN-SSH utilise TCP, donc hérite des avantages et inconvénients de TCP. https://linuxfr.org/users/obsider/journaux/high-performance-ssh

      • [^] # Re: Transfert sur liaison haut débit haute latence

        Posté par  . Évalué à 3 (+2/-0).

        Je me suis mal exprimé je crois. Je vais donner des exemples pour clarifier ma question.

        Cas d'usage 1 : J'utilise UDT au quotidien via le wrapper UDR (rsync+udt), ça m'a permis de passer de 6-10 heures de temps de synchro à 30-45 minutes, sur une ligne 1Gbps avec 90ms de RTT. Donc je dirais que l'outil est peut-être abandonné, mais en tout cas il marche d'enfer !

        Cas d'usage 2 : J'ai un serveur de fichiers (genre NextCloud File Drop, donc https) sur Internet en France, mes clients sont à Los Angeles et doivent récupérer 500Go de fichiers (RTT=140ms). En faisant des downloads en parallèle on peut accélérer le transfert, mais ce n'est pas toujours supporté côté client ou pas pratique.

        Ma question donc : dans ce genre de cas, est-ce qu'un protocole comme QUIC me permet d'aller presque à la vitesse du lien sans bricoler ? Genre avec un "bête" curl, et surtout sans truc compliqué et cher comme FASP.

        • [^] # Re: Transfert sur liaison haut débit haute latence

          Posté par  . Évalué à 3 (+2/-0).

          À relire la chouette dépêche, je crois que la réponse est partiellement dedans :
          « En pratique, QUIC a été conçu essentiellement en pensant à HTTP mais dans le futur, d’autres protocoles pourront profiter de QUIC, notamment s’ils ont des problèmes qui ressemblent à ceux du Web (désir de faible latence, et de multiplexage). »

  • # Inconvénients ?

    Posté par  . Évalué à 5 (+3/-0).

    Bonjour, en tant que béotien, quand je lis cette dépêche, je retiens que QUIC est très bien car il résout beaucoup de problème de TCP. J'ai également noté qu'il est surtout pensé pour les applications qui nécessite une faible latence (HTTP par exemple).

    Du coup, est ce que ce protocole n'a aucun défaut ? Est ce qu'il offre de moins bonnes performances (lesquelles ?) pour les applications qui se foutent de la latence ?

    • [^] # Re: Inconvénients ?

      Posté par  . Évalué à 5 (+3/-0).

      Du coup, est ce que ce protocole n'a aucun défaut ? Est ce qu'il offre de moins bonnes performances (lesquelles ?) pour les applications qui se foutent de la latence ?

      Par rapport à ses 2 grands frères (c'est à prendre comme un point de vu) :

      • il est supérieur à TCP en tout points, les seuls cas où TCP reste pertinent sont des cas particuliers lié au chiffrement ou à la possibilité d'utiliser des implémentations déjà existantes de tcp/tls
      • par rapport à UDP ce ne sont pas des concurrents ou des alternatives, udp est très utile dans des cas où tu n'a pas besoin d'aquitement. Ça le rend plus léger quoi qu'il arrive (au détriment d'autres choses). Par exemple moi je m'en sert pour envoyer des logs sur un serveur de log. Je veux que ça coûte le moins chère possible à ceux qui envoient les logs et que si le serveur de logs tombe je préfère perdre les logs plutôt qu'impacter les services (le coup très drôle d'un service en galère qui flood le serveur de log qui impact toute la plateforme).
      • [^] # Re: Inconvénients ?

        Posté par  . Évalué à 9 (+7/-0).

        Utilisant UDP, il en reprends aussi les défauts. Je pense surtout au problème pour les attaques DoS.

        QUIC peut déjà être utilisé comme amplification d'attaque DoS. L'entête de première réponse du serveur contient le certificat du serveur pour ouvrir la session TLS au plus tôt. L'effet est limité en demandant au client d'envoyer un gros premier paquet d'ouverture de session.

        Le port QUIC peut-être simplement flooder aussi comme le ferai une attaque de type TCP-SYNFLOOD. Je suppose que les serveurs auront un moyen de se protéger (limitation par ip, SNI ou autre) mais il va être difficile de faire grands chose au niveau d'un firewall avant un serveur. Avec TCP, on peut faire un proxy tcp-syn avec iptables par exemple qui vérifie la véracité d'une connexion TCP avant de la donner au serveur. Avec QUIC, je ne sais pas si cela est possible sans avoir recours à un vrai proxy logiciel qui devra avoir au moins les certificats pour chaques SNI. Les premiers paquets des sessions QUIC devant être plus gros pour limiter l'amplification en cas d'attaque par rebond, une attaque DoS de type TCP-SYNFLOOD utilisant QUIC pourra viser la saturation du serveur et la saturation des liens réseaux.

        Je ne doute pas que les gros vont avoir des solutions pour cela. Mais en tant que petit, quel seront les solutions pour se protéger de ces attaques ?

        • [^] # Re: Inconvénients ?

          Posté par  (site Web personnel) . Évalué à 8 (+7/-1).

          Utilisant UDP, il en reprends aussi les défauts. Je pense surtout au problème pour les attaques DoS.

          Non, c'est faux. Beaucoup de gens ne connaissent de QUIC que le « il tourne sur UDP » et se disent « ah mon Dieu, ça va servir pour des attaques par réflexion ». Ce serait comme de dire de TCP qu'il permet des attaques par réflexion car il tourne sur IP, qui permet ces attaques.

          QUIC, comme TCP, teste la réversibilité ("returnability") et ne peut donc pas servir pour des attaques par réflexion.

          Pour le premier datagramme (pour lequel on n'a pas encore pu tester la réversibilité), QUIC limite le BAF (Bandwith Amplification Factor) à trois. C'est pour cela que le premier datagramme du client est souvent si gros (le RFC recommande 1 200 octets), afin d'être sûr que les certificats tiendront dans la réponse. Rappelons que TCP, sur Linux, a un PAF (Packet Amplification Factor) de 5 (oui, 5 datagrammes TCP sont envoyés en réponse au premier datagramme, pour lequel la réversibilité n'a pas été testée).

    • [^] # Re: Inconvénients ?

      Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

      Du coup, est ce que ce protocole n'a aucun défaut ?

      A vue de nez, ça se paie au moins en complexité d'implantation. Pas dit qu'on fasse du quick avec un petit micro contrôleur pour lequel la gestion de tcp est déjà parfois un exploit technique.

      Adhérer à l'April, ça vous tente ?

    • [^] # Re: Inconvénients ?

      Posté par  (site Web personnel) . Évalué à 9 (+7/-0).

      Une partie des défauts ne seront découverts qu'avec le temps (comme cela a été le cas pour TCP). Le retour d'expérience existe mais ne doutons pas qu'on verra des problèmes à l'usage quand il sera plus massif et plus distribué.

      Un défaut possible, mais pas encore exploré, est la facilité de suivre un utilisateur donné au cours du temps, puisque les sessions peuvent être longues (et survivent aux changements d'adresses IP). QUIC protège mieux contre un surveillant extérieur mais moins bien contre l'extrémité (le serveur). En pratique, ce n'est sans doute pas un vrai problème car HTTP, notamment grâce aux cookies, transmet déjà largement assez pour le suivi de l'utilisateur (suivi qui, contrairement à QUIC, s'étend au-delà d'un seul serveur, grâce à Google Analytics et aux boutons de partage des GAFA). Par contre, si on développe un système tout nouveau et orienté vie privée, le client devra veiller à ne pas laisser les sessions QUIC durer trop longtemps et survivre aux changements d'adresses IP. Bref, QUIC sur Tor ne serait sans doute pas pertinent.

      • [^] # Re: Inconvénients ?

        Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

        J'ai détaillé cette analyse dans un article.

        • [^] # Re: Inconvénients ?

          Posté par  . Évalué à 2 (+0/-0).

          Un client QUIC soucieux de ne pas être suivi à la trace peut donc, une fois qu'il a géré les problèmes bien plus énormes que posent les cookies et le fingerprinting, envisager des solutions comme de ne pas laisser les connexions QUIC durer trop longtemps et surtout ne pas utiliser la migration (qui permet de maintenir la connexion lorsque l'adresse IP change). Cela peut se faire en raccrochant délibérement la connexion, ou simplement en ne prévoyant pas de réserve de connection IDs (RFC 9000, section 5.1.1). Ceci dit, c'est plus facile à dire qu'à faire car une application n'est pas forcément informée rapidement d'un changement d'adresse IP de la machine.

          Je ne comprends pas très bien l'implémentation est au courante de du changement d'adresse puisqu'elle doit changer d'identifiant, non ?

  • # Et SCTP

    Posté par  . Évalué à 3 (+1/-0).

    Je n'ai pas vu mentionné SCTP en fr qui semble prometteur sur le papier. Multiplexage, échange de messages de taille arbitraire, répartition vers plusieurs serveurs cibles… Ça semble bien adapté pour un serveur web.

    J'imagine qu'il souffre méchamment du filtrage à outrance. J'ai l'impression que ça stagne depuis des années.

    • [^] # Re: Et SCTP

      Posté par  . Évalué à 3 (+0/-0).

      Il me semble que c'est le cas d'école qui montre qu'il est impossible de se passer de tcp/udp pour pouvoir joindre des machines hors de réseaux entièrement maîtrisé.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Et SCTP

      Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

      Le fait de gérer les frontières de message n'a pas en pratique convaincu tellement de monde. Sinon, SCTP n'a pas d'avantage suffisamment écrasant sur TCP. Mais il est dans le noyau Linux depuis un certain temps, donc vous pouvez l'utiliser.
      Victime du filtrage massif fait par les opérateurs, il a en effet du mal à passer partout. Aujourd'hui, il est en général employé sur UDP (RFC 6951).

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.