Noq: n0の新しいRustベースQUIC実装

• n0チームが開発したnoqは、Rustで書かれた汎用QUIC実装で、マルチパスとNATトラバーサルをサポート
• 既存のirohにおけるQuinnベース構造の限界を解決するため、独立したコードベースへ移行して開発された
• QUIC Multipath、NAT Traversal、Address Discovery、QLog拡張、WeakConnectionHandleなど多様な機能を含む
• iroh v0.96から本番環境で使用中で、picoquicとの相互運用性テストも完了
• 今後はQUICワーキンググループおよびQuinnチームと協力を続け、Rustベースのネットワークアプリケーション開発者のための基盤技術として発展させる予定

---

noq発表

• noqはn0チームが開発した汎用QUIC実装で、マルチパス(multipath)およびNATトラバーサル機能をサポート
• iroh v0.96からトランスポート層として使用されており、irohに限定されず一般用途でも活用可能

Quinnからnoqへの移行

• irohは従来QuinnをベースにQUICを利用していたが、NATトラバーサルや経路切り替えなど、QUICの外側で処理しなければならない複雑な機能が多かった
• このような構造的制約により外部からの修正が難しく、Quinnのハードフォークを決定
• Quinnとの協力は維持しつつ、独立したコードベースによってiroh特有の要件を満たす方向へ移行

noqの主な機能

• QUIC Multipath

  • QUIC Multipath仕様を完全実装し、irohのリレーおよび直接経路(IPV4, IPV6)をQUICの第一級の経路概念として統合
  • 各経路ごとの輻輳制御状態を維持しながら最適な経路を選択可能
  • これまではirohがQUICの下層で経路を操作していたが、今ではQUIC自体がこれを認識して管理
  • iroh以外の一般用途にも使える汎用マルチパス実装として設計

• QUIC NAT Traversal

  • QUIC NATトラバーサル草案を独自に解釈して実装し、本番レベルの安定性を備えた初の事例として言及
  • 数十万台のirohデバイスで実運用テストを実施
  • NATホールパンチングをQUIC層で直接実行することで、輻輳制御器と損失検知がより正確に動作

• QUIC Address Discovery

  • iroh v0.32から**QUIC Address Discovery(QAD)**を使用
  • STUNの代わりにQUIC接続を通じてクライアントのグローバルIPアドレスを学習
  • 暗号化されたパケット送信によりプロトコルの硬直化を防ぎ、プライバシー保護を強化

• QLog拡張

  • QLog標準草案に基づいてQUIC接続のさまざまなイベントを記録
  • 従来よりはるかに多くのイベントをサポートし、マルチパス関連イベントも追加
  • qvisのような可視化ツールと互換性があり、マルチパスのパケットフローを表示するビューアのプロトタイプも提供

• WeakConnectionHandle

  • 接続を保持せずに、必要時にConnectionオブジェクトへ昇格できる型
  • std::sync::Weakに似ているが、Arcを使わなくてもよい
  • 接続マネージャなどで有用に活用可能

本番適用と相互運用性

• noqはiroh v0.96から本番環境で使用中
• 独自のマルチパス実装だけでなく、picoquicとの相互運用性テストも完了

今後の計画

• noqを長期的な基盤技術として発展させる予定
• NATトラバーサルの改善とマルチパスベースの性能最適化を推進
• QUICワーキンググループおよびQuinnチームとの協力を継続
• QUIC実装、P2P転送、多様なネットワーク環境で動作するアプリケーション開発者との協業を拡大
• RustベースのQUICマルチパス実装を直接試せるよう、ドキュメントとサンプルコードを提供

Iroh概要

• Irohは「dial-any-device」ネットワーキングライブラリで、プロトコルの組み合わせによる柔軟なネットワーク構成をサポート
• すでに数十万台のデバイスで運用されており、オープンソースとして公開
• ドキュメント、コード、Discordチャンネルを通じてプロジェクトに参加可能

[GN⁺]

Hacker Newsのコメント

• このスレッドで、Irohチームがforkを決めるまでの過程を互いに敬意を持って議論していたのが良かった

  • 本当に素晴らしいやり取りだった。以前はメンテナがforkを敵対行為や「自分たちのコードを盗まれる」といった形で受け取ることがよくあったが、今回は違った
    内部の変更をupstreamへ戻すのがどれほど難しいかもよく表れている。彼らは自分たちの変更を何百もの小さなPRに分割してレビューしてもらう時間はないと言っていた。企業としてはあまりに大きな時間投資だからだ
    それでも元のプロジェクトと実装の詳細は近い状態に保ってほしい。十分に安定した後なら、小さな単位ではなく大きな塊ごとのマージも可能だと思う
  • こういう礼儀正しい会話は、オープンソースコミュニティでよくあるドラマとは対照的で見ていて気持ちがいい

• irohは、個人向けアプリケーションを素早く作る時代においてうまくポジショニングされた製品のように見える
  これを使って「app relay」を作ってみたいと思っていた。ユーザーが追加設定なしで自分のネットワーク内のアプリやデータにリモートアクセスできるzero-config OSSソリューションを構想している。これはTailscaleのようなネットワークリレーとは異なる

  • 実際、zero-configの実装は厄介だ。私はmDNSベースのディスカバリーをさまざまなホームネットワークで実装したことがあるが、ルーターがマルチキャストをブロックしたり制限したりすることが多かった。結局、複数のフォールバック層を積み上げ、どの経路が実際に動くかを判断するヒューリスティクスを書く必要があった。QUICにmultipathが標準で組み込まれていれば、ずっと楽だったはずだ
  • こうした話題に関心があるなら、awesome-tunnelingリストを参考にするといい。特にOpenZitiはアプリ内部にトンネルを埋め込む似たアプローチを取っている

• n0チームは本当に好きだ。私は彼らのsendme CLIをよく使ってP2Pファイル転送をしている

  • 私も同じだ。彼らのツールキットは速く、安定していて、楽しい開発体験を与えてくれる。本当にゲームチェンジャーだと思う
  • 良い情報をありがとう。私は普段magic wormholeを使っているが、Pythonモジュールが多すぎてサーバーに入れるのが負担だった。だからWindowsのSQLサーバーではtoothpykのような簡単な代替を使ったり、wgetで済ませたりしていた。sendmeはぜひ試してみたい

• noq/irohが**QUICパケットを中継(relay)**する仕組みが気になっていた。QUICは追跡が難しいのに、relayがどのパケットをどこへ送るべきかどうやって知るのか、あるいはQUICを別のプロトコルで包んでいるのか知りたかった

  • noq自体はリレーのロジックを実装していない。iroh relayは単にもうひとつのIPサブネットのように動作する
    実際にはQUIC datagramをWebSocketで包んで送っている。ヘッダーには宛先EndpointId（ed25519公開鍵）が含まれ、ハンドシェイクによって送信元EndpointIdも認証される
    つまり、QUIC datagramをHTTPS over TCPでトンネリングしているようなものだ。二重に暗号化されるが、UDPが遮断された環境でも動作し、通常のトラフィックのように見えるよう設計されている

• irohチームは今も速いペースで進化し続けている
  週末に時間を取って、irohでNebulaのようなオーバーレイネットワークを作ってみるつもりだ

  • 彼らのDiscordで言及されていた関連プロジェクトとして、iroh-lanとironを見てみるといい

• QUICのようなアプローチは、依然として接続の持続性を転送状態に強く結びつける構造になっている
  セッションのアイデンティティを転送層から完全に分離して、転送失敗を単なる回復可能なイベントにできないかと考えている。QUICより一歩進んだ実用的なシステムを見たことがある人はいるだろうか

• noqコードスニペットを参照

• 最近発表されたirohのカスタムトランスポート機能に関する話も興味深い
  iroh 0.97.0のブログ記事で詳しく見られる

• nQUICは確認しただろうか。NoiseをNoqに統合すると面白そうだ

  • 実際に実験はあった → nquinnプロジェクト
    noq（およびその基盤であるQuinn）は独自の「Session」トレイトを実装できるので、TLSとnQUICのどちらを使うか選べる

• tsodingのNoqと混同しないように注意。あちらの名前は「Not Coq」に由来する