Noq : la nouvelle implémentation QUIC en Rust de n0

• noq, développé par l’équipe n0, est une implémentation QUIC générique écrite en Rust qui prend en charge le multipath et la traversée NAT
• Le développement s’est orienté vers une base de code indépendante afin de dépasser les limites structurelles de l’architecture existante basée sur Quinn dans iroh
• Le projet inclut diverses fonctionnalités comme QUIC Multipath, NAT Traversal, Address Discovery, des extensions QLog et WeakConnectionHandle
• Il est utilisé en production depuis iroh v0.96, et les tests d’interopérabilité avec picoquic sont également terminés
• À l’avenir, l’équipe compte poursuivre la collaboration avec le groupe de travail QUIC et l’équipe Quinn, et faire évoluer noq en technologie de base pour les développeurs d’applications réseau en Rust

---

Annonce de noq

• noq est une implémentation QUIC générique développée par l’équipe n0, avec prise en charge du multipath et de la traversée NAT
• Elle est utilisée comme couche de transport depuis iroh v0.96, mais peut aussi servir à des usages généraux au-delà d’iroh

Du passage de Quinn à noq

• iroh utilisait auparavant QUIC sur la base de Quinn, mais de nombreuses fonctionnalités complexes, comme la traversée NAT et le basculement de chemin, devaient être gérées en dehors de QUIC
• En raison de ces contraintes structurelles, il était difficile d’apporter des modifications externes, ce qui a conduit à la décision de réaliser un hard fork de Quinn
• Tout en maintenant la collaboration avec Quinn, le projet a évolué vers une base de code indépendante afin de répondre aux besoins spécifiques d’iroh

Principales fonctionnalités de noq

• QUIC Multipath

  • Implémentation complète de la spécification QUIC Multipath, intégrant les relais et chemins directs d’iroh (IPV4, IPV6) comme des concepts de chemin de premier ordre dans QUIC
  • Conservation d’un état de contrôle de congestion pour chaque chemin, avec possibilité de sélectionner le chemin optimal
  • Auparavant, iroh manipulait les chemins sous QUIC ; désormais, QUIC les reconnaît et les gère directement
  • Conçu comme une implémentation multipath générique utilisable aussi en dehors d’iroh

• QUIC NAT Traversal

  • Implémentation fondée sur une interprétation propre du brouillon QUIC NAT Traversal, présentée comme le premier cas doté d’une stabilité de niveau production
  • Testée en conditions réelles sur plusieurs centaines de milliers d’appareils iroh
  • Le hole punching NAT est effectué directement au niveau QUIC, ce qui permet un fonctionnement plus précis du contrôle de congestion et de la détection de perte

• QUIC Address Discovery

  • iroh utilise QUIC Address Discovery (QAD) depuis la v0.32
  • L’adresse IP publique du client est apprise via la connexion QUIC plutôt que via STUN
  • L’envoi de paquets chiffrés évite la rigidification du protocole et renforce la protection de la vie privée

• Extensions QLog

  • Enregistrement de divers événements des connexions QUIC sur la base du brouillon standard QLog
  • Prise en charge de beaucoup plus d’événements qu’auparavant, avec ajout d’événements liés au multipath
  • Compatible avec des outils de visualisation comme qvis, avec aussi un prototype de visualiseur affichant les flux de paquets multi-chemins

• WeakConnectionHandle

  • Type permettant d’être promu en objet Connection en cas de besoin, sans maintenir la connexion en permanence
  • Similaire à std::sync::Weak, mais sans nécessiter l’usage de Arc
  • Peut être utile notamment dans un gestionnaire de connexions

Déploiement en production et interopérabilité

• noq est utilisé en production depuis iroh v0.96
• En plus de sa propre implémentation multipath, les tests d’interopérabilité avec picoquic ont également été menés à bien

Feuille de route

• L’objectif est de faire de noq une technologie de base durable
• Amélioration de la traversée NAT et optimisation des performances fondée sur le multipath
• Poursuite de la collaboration avec le groupe de travail QUIC et l’équipe Quinn
• Extension de la collaboration avec les développeurs travaillant sur les implémentations QUIC, le transport P2P et les applications fonctionnant dans divers environnements réseau
• Mise à disposition de documentation et d’exemples de code pour permettre d’utiliser directement cette implémentation QUIC multipath en Rust

Présentation d’Iroh

• Iroh est une bibliothèque réseau de type « dial-any-device », qui prend en charge une configuration réseau flexible par combinaison de protocoles
• Elle est déjà exploitée sur plusieurs centaines de milliers d’appareils et publiée en open source
• Il est possible de participer au projet via la documentation, le code et le canal Discord

[GN⁺]

Commentaires sur Hacker News

• C’était agréable de voir, dans ce fil, l’équipe d’Iroh discuter avec respect du processus qui les a conduits à décider d’un fork

  • C’était vraiment une belle interaction. Par le passé, il arrivait souvent que des mainteneurs considèrent un fork comme un acte hostile ou comme une forme de « vol de notre code », mais cette fois c’était différent
    Cela montre aussi bien à quel point il est difficile de faire remonter des changements internes vers l’upstream. Ils disaient ne pas avoir le temps de découper leurs modifications en centaines de petites PR pour les faire relire. Du point de vue d’une entreprise, c’est un investissement en temps trop important
    J’espère quand même qu’ils garderont une certaine proximité avec le projet d’origine et ses détails d’implémentation. Une fois les choses suffisamment stabilisées, il sera peut-être possible de fusionner à nouveau par gros blocs plutôt que par petites unités
  • Ce type d’échange courtois fait plaisir à voir, en contraste avec le drama habituel des communautés open source

• iroh semble être un produit bien positionné à l’ère où l’on crée rapidement des applications personnelles
  J’aimerais m’en servir pour construire un « app relay ». J’imagine une solution OSS zero-config permettant aux utilisateurs d’accéder à distance aux applications ou aux données présentes sur leur réseau, sans configuration particulière. Ce n’est pas la même chose qu’un relais réseau comme Tailscale

  • En pratique, le zero-config est difficile à mettre en œuvre. J’ai déjà implémenté de la discovery basée sur mDNS sur divers réseaux domestiques, et beaucoup de routeurs bloquent ou limitent le multicast. Au final, j’ai dû empiler plusieurs couches de fallback et écrire des heuristiques pour déterminer quel chemin fonctionnait réellement. Si QUIC avait eu le multipath intégré nativement, cela aurait été bien plus simple
  • Si le sujet vous intéresse, la liste awesome-tunneling vaut le détour. En particulier, OpenZiti adopte une approche similaire en embarquant le tunnel directement dans l’application

• J’aime vraiment beaucoup l’équipe de n0. J’utilise souvent leur CLI sendme pour des transferts de fichiers P2P

  • Pareil pour moi. Leur boîte à outils offre une expérience de développement rapide, stable et agréable. Franchement, ça change la donne
  • Merci pour l’info. J’utilise d’habitude magic wormhole, mais il y a trop de modules Python et c’était pénible à installer sur un serveur. Du coup, sur un serveur SQL Windows, j’utilisais une alternative simple comme toothpyk, ou je m’en sortais avec wget. Il faut absolument que j’essaie sendme

• Je me demandais comment noq/iroh relaye les paquets QUIC. QUIC est difficile à inspecter, alors je me demandais comment le relay sait quels paquets envoyer où, ou s’il encapsule QUIC dans un autre protocole

  • noq lui-même n’implémente pas la logique de relais. Le relais d’iroh se comporte simplement comme un autre sous-réseau IP
    En pratique, il transporte les datagrammes QUIC encapsulés dans WebSocket. L’en-tête inclut l’EndpointId de destination (clé publique ed25519), et le handshake authentifie aussi l’EndpointId de l’émetteur
    En d’autres termes, cela revient à tunneliser des datagrammes QUIC via HTTPS over TCP. C’est un double chiffrement, mais cela fonctionne même quand l’UDP est bloqué et c’est conçu pour ressembler à du trafic ordinaire

• L’équipe d’iroh continue d’avancer à grande vitesse
  Je compte prendre un peu de temps ce week-end pour essayer de construire avec iroh un réseau overlay de type Nebula

  • Parmi les projets liés mentionnés sur leur Discord, on peut regarder iroh-lan et iron

• Une approche comme QUIC reste une structure où la persistance de la connexion est fortement couplée à l’état du transport
  Je me demande s’il est possible de séparer complètement l’identité de session de la couche transport, afin qu’un échec du transport ne soit qu’un événement récupérable. Je serais curieux de savoir si quelqu’un a déjà vu un système pratique allant plus loin que QUIC

• Voir aussi cet extrait de code de noq

• Les récentes annonces autour de la fonction de transports personnalisés d’iroh sont également intéressantes
  Voir le billet de blog sur iroh 0.97.0 pour plus de détails

• Quelqu’un a-t-il regardé du côté de nQUIC ? Intégrer Noise à Noq pourrait être intéressant

  • Il y a effectivement eu une expérimentation → projet nquinn
    noq (et Quinn, sur lequel il repose) permet d’implémenter son propre trait « Session », ce qui laisse le choix entre TLS et nQUIC

• À ne pas confondre avec le Noq de tsoding, dont le nom vient de « Not Coq »