Noq: n0s neue Rust-basierte QUIC-Implementierung

• noq, entwickelt vom n0-Team, ist eine allgemeine QUIC-Implementierung in Rust und unterstützt Multipath sowie NAT Traversal
• Sie wurde als eigenständige Codebasis entwickelt, um die Grenzen der bisherigen Quinn-basierten Struktur von iroh zu überwinden
• Enthält verschiedene Funktionen wie QUIC Multipath, NAT Traversal, Address Discovery, QLog-Erweiterungen und WeakConnectionHandle
• Wird seit iroh v0.96 in Produktionsumgebungen eingesetzt, und Interoperabilitätstests mit picoquic wurden ebenfalls abgeschlossen
• Künftig soll sie sich mit fortgesetzter Zusammenarbeit mit der QUIC Working Group und dem Quinn-Team zu einer Basistechnologie für Entwickler Rust-basierter Netzwerkanwendungen weiterentwickeln

---

Ankündigung von noq

• noq ist eine vom n0-Team entwickelte allgemeine QUIC-Implementierung, die Multipath und NAT Traversal unterstützt
• Sie wird seit iroh v0.96 als Transportschicht eingesetzt und kann nicht nur mit iroh, sondern auch für allgemeine Zwecke genutzt werden

Der Wechsel von Quinn zu noq

• iroh nutzte QUIC bisher auf Basis von Quinn, musste jedoch viele komplexe Funktionen wie NAT Traversal und Pfadwechsel außerhalb von QUIC behandeln
• Aufgrund dieser strukturellen Einschränkungen waren externe Änderungen schwierig, weshalb man sich für einen Hard Fork von Quinn entschied
• Bei fortgesetzter Zusammenarbeit mit Quinn erfolgte der Wechsel zu einer eigenständigen Codebasis, um die speziellen Anforderungen von iroh zu erfüllen

Hauptfunktionen von noq

• QUIC Multipath

  • Vollständige Implementierung der QUIC-Multipath-Spezifikation, die Relay- und Direktpfade (IPV4, IPV6) von iroh als erstklassige Pfadkonzepte in QUIC integriert
  • Der Status der Congestion Control wird für jeden Pfad einzeln verwaltet, sodass der optimale Pfad ausgewählt werden kann
  • Während iroh Pfade bisher unterhalb von QUIC manipulierte, erkennt und verwaltet nun QUIC selbst diese Pfade
  • Entwickelt als allgemeine Multipath-Implementierung, die auch außerhalb von iroh eingesetzt werden kann

• QUIC NAT Traversal

  • Implementiert auf Basis einer eigenen Auslegung des QUIC-NAT-Traversal-Entwurfs und als erster Fall mit produktionsreifer Stabilität beschrieben
  • In realen Einsätzen auf Hunderttausenden iroh-Geräten getestet
  • Führt NAT Hole Punching direkt auf QUIC-Ebene aus, wodurch Congestion Control und Verlusterkennung präziser arbeiten

• QUIC Address Discovery

  • iroh verwendet seit v0.32 QUIC Address Discovery (QAD)
  • Lernt die öffentliche IP-Adresse des Clients über eine QUIC-Verbindung statt über STUN
  • Verschlüsselte Paketübertragung verhindert Protokollverhärtung und verbessert den Datenschutz

• QLog-Erweiterungen

  • Protokolliert verschiedene Ereignisse einer QUIC-Verbindung auf Basis des QLog-Standardentwurfs
  • Unterstützt deutlich mehr Ereignisse als bisher und ergänzt auch Multipath-bezogene Ereignisse
  • Kompatibel mit Visualisierungstools wie qvis; außerdem wird ein Viewer-Prototyp zur Darstellung von Multipath-Paketflüssen bereitgestellt

• WeakConnectionHandle

  • Ein Typ, der eine Verbindung nicht aufrechterhält, bei Bedarf aber zu einem Connection-Objekt hochgestuft werden kann
  • Ähnlich wie std::sync::Weak, jedoch ohne dass Arc verwendet werden muss
  • Nützlich etwa in Connection-Managern

Einsatz in Produktion und Interoperabilität

• noq wird seit iroh v0.96 in Produktionsumgebungen eingesetzt
• Neben der eigenen Multipath-Implementierung wurden auch Interoperabilitätstests mit picoquic abgeschlossen

Ausblick

• noq soll zu einer langfristigen Basistechnologie weiterentwickelt werden
• Verbesserungen beim NAT Traversal sowie Leistungsoptimierung auf Basis von Multipath sind geplant
• Die Zusammenarbeit mit der QUIC Working Group und dem Quinn-Team wird fortgesetzt
• Die Zusammenarbeit mit Entwicklern von QUIC-Implementierungen, P2P-Transporten und Anwendungen für unterschiedliche Netzwerkumgebungen soll ausgebaut werden
• Es werden Dokumentation und Beispielcode bereitgestellt, damit die Rust-basierte QUIC-Multipath-Implementierung direkt ausprobiert werden kann

Überblick über Iroh

• Iroh ist eine „Dial-any-device“-Netzwerkbibliothek, die flexible Netzwerkkonfigurationen durch die Kombination von Protokollen unterstützt
• Sie ist bereits auf Hunderttausenden Geräten im Einsatz und als Open Source veröffentlicht
• Eine Beteiligung am Projekt ist über Dokumentation, Code und den Discord-Kanal möglich

[GN⁺]

Hacker-News-Kommentare

• Es war schön zu sehen, wie das Iroh-Team in diesem Thread den Prozess respektvoll diskutierte, der zur Entscheidung für einen Fork führte

  • Das war wirklich eine großartige Interaktion. Früher haben Maintainer Forks oft als feindseligen Akt oder als eine Art „Die stehlen unseren Code“ aufgefasst, aber diesmal war es anders
    Es zeigt auch gut, wie schwierig es ist, interne Änderungen wieder in das Upstream-Projekt zurückzuführen. Sie meinten, sie hätten keine Zeit, ihre Änderungen in Hunderte kleiner PRs aufzuteilen und reviewen zu lassen. Aus Unternehmenssicht ist das einfach ein zu großer Zeitaufwand
    Trotzdem hoffe ich, dass sie in Bezug auf die Implementierungsdetails nah am ursprünglichen Projekt bleiben. Sobald alles ausreichend stabilisiert ist, könnte vielleicht auch eine Zusammenführung in größeren Blöcken statt in kleinen Einheiten möglich sein
  • Solch höfliche Gespräche waren angenehm zu sehen und stehen im Kontrast zum üblichen Drama in Open-Source-Communitys

• iroh wirkt wie ein gut positioniertes Produkt für ein Zeitalter, in dem persönliche Anwendungen schnell entwickelt werden
  Ich wollte damit einmal ein „App-Relay“ bauen. Ich denke über eine Zero-Config-OSS-Lösung nach, mit der Nutzer ohne zusätzliche Einrichtung aus der Ferne auf Apps oder Daten in ihrem eigenen Netzwerk zugreifen können. Das unterscheidet sich von Netzwerk-Relays wie Tailscale

  • In der Praxis ist Zero Config schwer umzusetzen. Ich habe schon Discovery auf Basis von mDNS in verschiedenen Heimnetzwerken implementiert, und oft blockieren oder begrenzen Router Multicast. Am Ende muss man mehrere Fallback-Ebenen aufbauen und Heuristiken schreiben, um herauszufinden, welcher Weg tatsächlich funktioniert. Wenn QUIC Multipath standardmäßig eingebaut hätte, wäre das deutlich einfacher gewesen
  • Falls dich das Thema interessiert, ist die awesome-tunneling-Liste einen Blick wert. Vor allem OpenZiti verfolgt einen ähnlichen Ansatz, bei dem Tunnel direkt in Apps eingebettet werden

• Ich mag das n0-Team wirklich sehr. Ich nutze ihr sendme CLI oft für P2P-Dateiübertragungen

  • Geht mir genauso. Ihr Toolkit bietet eine schnelle, stabile und angenehme Entwicklererfahrung. Fühlt sich wirklich wie ein Gamechanger an
  • Danke für den Tipp. Ich nutze normalerweise magic wormhole, aber die vielen Python-Module waren mir für die Installation auf Servern zu schwergewichtig. Deshalb habe ich auf Windows-SQL-Servern einfache Alternativen wie toothpyk genutzt oder es mit wget gelöst. sendme muss ich unbedingt ausprobieren

• Ich hatte mich gefragt, wie noq/iroh QUIC-Pakete weiterleitet (relay). QUIC ist schwer nachzuverfolgen, daher fragte ich mich, wie das Relay weiß, welches Paket wohin gesendet werden muss, oder ob QUIC in ein anderes Protokoll verpackt wird

  • noq selbst implementiert keine Relay-Logik. Das iroh-Relay verhält sich einfach wie ein weiteres IP-Subnetz
    Tatsächlich werden QUIC-Datagramme in WebSocket gekapselt und so übertragen. Im Header steht die Ziel-EndpointId (ed25519-öffentlicher Schlüssel), und über den Handshake wird auch die EndpointId des Senders authentifiziert
    Im Grunde werden QUIC-Datagramme also über HTTPS over TCP getunnelt. Das ist doppelt verschlüsselt, funktioniert aber auch in Umgebungen, in denen UDP blockiert ist, und wurde so entworfen, dass es wie normaler Traffic aussieht

• Das iroh-Team entwickelt sich weiterhin in hohem Tempo weiter
  Ich plane, mir am Wochenende Zeit zu nehmen und mit iroh ein Nebula-ähnliches Overlay-Netzwerk zu bauen

  • Als verwandte Projekte, die in ihrem Discord erwähnt wurden, sind iroh-lan und iron einen Blick wert

• Ein Ansatz wie QUIC bindet die Verbindungsbeständigkeit weiterhin stark an den Transportzustand
  Ich überlege, ob man die Sitzungsidentität vollständig von der Transportschicht trennen könnte, sodass ein Transportfehler nur ein einfach behebbares Ereignis wäre. Mich würde interessieren, ob jemand ein praktisches System gesehen hat, das über QUIC hinausgeht

• Siehe auch dieses noq-Code-Snippet

• Interessant sind auch die kürzlich angekündigten Neuigkeiten zu irohs Custom-Transport-Funktion
  Mehr dazu im iroh-0.97.0-Blogpost

• Hat sich jemand schon nQUIC angesehen? Es könnte spannend sein, Noise in Noq zu integrieren

  • Damit wurde tatsächlich experimentiert → nquinn-Projekt
    noq (und Quinn, auf dem es basiert) erlaubt die Implementierung eines eigenen „Session“-Traits, sodass man zwischen TLS und nQUIC wählen kann

• Nicht mit tsodings Noq verwechseln. Der Name dort leitet sich von „Not Coq“ ab