← 2026-03-20 の一覧へ戻るホーム
Noq：n0がRustで実装した新しいQUIC

2026/03/20 3:17

Noq：n0がRustで実装した新しいQUIC

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

noq（「番号 0 QUIC」）は、Quinn をベースに構築されたオープンソースの QUIC 実装で、QUIC マルチパス仕様と NAT トラバーサルへの完全な対応を追加し、プライバシー強化型公開 IP 発見用 QAD（QUIC アドレスディスカバリ）も備えています。2024 年に Quinn から派生し、パス切替、各パスの輻輳状態、NAT 処理など Quinn が公開していなかった機能を露出させることで、noq は広範な Quinn ユーザー基盤に影響を与えることなく深く変更できます。iroh v0.96 を動かすのは既に数十万台のデバイスで、picoquic との相互運用性テストも行われています。主な追加機能として、新しい 

WeakConnectionHandle
型（軽量接続参照）とマルチパス固有イベントを含む拡張 qlog サポート、およびプロトタイプビューアがあります。今後の作業では NAT トラバーサルの改善、マルチパス性能の向上、QUIC WG および Quinn 開発者との協力強化が予定されています。このプロジェクトは Discord や GitHub の Issue を通じて貢献を歓迎しています。

本文

本日、私たちは noq（“number 0 QUIC”）を発表できることを大変嬉しく思います。これはマルチパスとNATトラバーサルに対応した当社独自の汎用 QUIC 実装です。i‑roh の v0.96 以降で動作しているトランスポートレイヤーですが、i‑roh 固有の用途に限定されるものではありません。

ソフトフォークからハードフォークへ

i‑roh の開発を追ってきた方なら、2024 年に Quinn をフォークした理由をご存知かもしれません。簡潔に言うと、i‑roh は QUIC 周辺で多くの重い処理―リレーとダイレクトパスの切り替え、NATトラバーサルの管理、輻輳状態の調整―を行っていましたが、QUIC 自体はその全てを把握しておらず、その不一致が外部から修正できない問題を生み出しました。

フォークは小さく始めました。Quinn の上流変更を追いかけつつ貢献し、差分を最小限に抑えることが当時の適切な判断でした。しかし、QUIC マルチパス、NATトラバーサル、そして独自のリレー‑アズ‑ア‑パス構成へと進むにつれ、両プロジェクトの開発速度は一致しなくなりました。頻繁に行われる変更は Quinn のメンテナに対して過度なレビュー負担をもたらしました。

n0 チームは QUIC 実装により深い構造的変更を試みたく、これらの影響をすべて Quinn ユーザーに押し付けることは不公平だと判断しました。協力関係を継続しつつハードフォークする方が全体として合理的です。こうして決断しました。

Quinn のマルチパス課題スレッドで私たちの考えを説明しています。これは Quinn を否定するものではなく、解決すべき問題が十分に特異であるため、別々のコードベースで協力し合うことが正しい道だと認めるものです。

noq の主な特徴

ヘッドラインは QUIC マルチパス仕様を完全実装した点です。ここで Quinn / noq 内外に大きなアーキテクチャの転換が起こりました。

  • マルチパス以前、i‑roh はリレー・ダイレクト IPv4・IPv6 など複数パスを QUIC レイヤー下で扱っていました。
    • Quinn は単一 IP アドレス経由とみなしていたのに対し、i‑roh は最適なパスへパケットを振り分けていました――Quinn の上に i‑roh 独自の小規模 NAT を置いているようなものです。
  • マルチパスでこれらは QUIC のファーストクラス概念となります。
    • リレーパスは QUIC パス。
    • ダイレクト UDP パスも QUIC パス。
    • QUIC はすべてを知り、各パスごとの輻輳状態を保持し、どれを使うか判断できます。

これにより、輻輳コントローラのリセットでハックしていたレイテンシ改善が正しく体系的に処理されます。マルチパス実装は汎用的で i‑roh だけではなく、任意の用途向けに QUIC マルチパス仕様を完全に実装することを目指しています。ただし実装はまだ若く、追加 API が必要な場合は遠慮なくご相談ください。

また、私たちは QUIC NAT トラバーサルドラフトを独自解釈して実装しました。現時点で本格的かつ堅牢にこれを行ったのは初めてです。NATトラバーサルは非常に微妙で、野外で遭遇する様々な NAT 動作を網羅するのは困難ですが、i‑roh を稼働させている数十万台のデバイスで実際にテストし続けています。まだ仕様が確定していないため、継続的に改善していきます。

NAT トラバーサル・ホールパンチングを QUIC レベルの操作として直接表現することで、QUIC 輻輳コントローラがそれを認識し、損失検知も向上します。

  • i‑roh はバージョン 0.32 以降 QUIC Address Discovery (QAD) を利用しています。
    • QAD は QUIC 接続を通じてクライアントのパブリック IP を学習し、従来 STUN で行っていた処理を置き換えます。
    • QUIC による暗号化はラウンドトリップ数を削減しつつプロトコルの硬直化を防ぎ、ユーザプライバシーも向上します。

Qlog は QUIC 接続に関する膨大な情報をログするドラフト仕様です。デバッグツールとして優秀で、qvis のような可視化ツールがパケットフローを表示できます。noq では Qlog サポートを拡張し、メインの qlog ロギングスキーマと QUIC イベント定義から多くのイベントを追加しました。またマルチパス用のイベントも導入しています。複数パスでのパケットフローを表示できるビューワープロトタイプもあります。

API の大部分はマルチパス対応ですが、WeakConnectionHandle という新型も追加しました。これは接続自体を保持せず、まだドロップされていない場合にフルの Connection にアップグレードできる型です。

std::sync::Weak
のように振る舞いますが Arc を必要としません。接続マネージャー構築などで役立ちます。i‑roh 内部でも使用しており、他にも有用なユースケースは多数存在します。

既に本番稼働

noq は i‑roh v0.96 とともにリリースされて以降、本番環境で稼働しています。最新バージョンの i‑roh を使用していれば、すでに noq が使われています。noq のマルチパス実装を自己テストしただけでなく、picoquic（QUIC ワーキンググループの相互運用イベントで採用される参照実装）の相互運用テストも実施しています。

今後の展望

noq を長期的基盤として捉えています。NAT トラバーサルのさらなる改善や、マルチパスによって可能になる性能最適化などを継続して行います。また QUIC ワーキンググループと協力し、Quinn チームとも共通関心領域で連携していきます。

QUIC 実装、P2P トランスポート、あるいは多様なネットワーク条件下で動作するアプリケーションを開発中の方はぜひご相談ください。Discord でお会いできるか、GitHub に issue を立てていただければ幸いです。

Rust で書かれた QUIC マルチパス実装に挑戦したい方は、マルチパス noq Connection のドキュメントを参照してください。

Iroh は「どのデバイスでもすぐに接続できる」ネットワーキングライブラリです。既存プロトコルのエコシステムから必要な機能を組み合わせるか、単純パイプ上で完全カスタムな抽象化を構築するか選べます。Iroh はオープンソースであり、数十万台のデバイスで本番稼働しています。始め方はドキュメントを確認したり、コードに直接飛び込んだり、Discord チャンネルでチャットしたりしてください。

同じ日のほかのニュース

一覧に戻る →

2026/03/20 5:33

コックピットは、サーバー用のウェブベースのグラフィカルインターフェイスです。

## Japanese Translation: **Cockpit** は、Linux 管理者がオペレーティングシステムから直接サーバーを管理できる軽量でブラウザベースのインターフェイスです。OS 内で動作し、Debian、Fedora、および RHEL など主要なディストリビューションに対応しており、コンテナの起動、ストレージやネットワークの設定、ログの確認、ブラウザを離れずにターミナルとグラフィカルコントロール間で切替えなどが可能です。 ユーザーは Cockpit からでも従来のシェルからでもサービスをシームレスに開始・停止でき、端末で発生したエラーは自動的に Cockpit のジャーナルインターフェイスに表示されます。 プロジェクトはリモート管理もサポートしており、ユーザーは SSH 経由で Cockpit がインストールされた他のマシンを追加・管理できるため、ホスト切替が簡単です。コミュニティサポートは Matrix チャネル（#cockpit:fedoraproject.org）とメールリストで提供されます。ドキュメントにはツールの使い方だけでなくコードベースへの貢献方法も網羅しており、ガイディングプリンシプル、リリースノート、およびプライバシーポリシーが含まれています。 複数の Linux ディストリビューションにわたる統一で使いやすい GUI を提供することで、Cockpit はサーバー管理を効率化し、ドキュメントと活発なコミュニケーションチャネルを通じて継続的な開発者貢献を促進することを目指しています。

2026/03/19 22:05

**Astral が OpenAI に参入**

## Japanese Translation: **（欠落していた詳細を補完）** ### 要約 Astral は、オープンソースの Python ツールを存続させつつ OpenAI の Codex チームに参加することに合意し、そのツールチェーンをモダンな Python 開発の中心に位置付けました。この取引は Astral の創業者が発表し、Python エコシステムの生産性を少なくとも 1 % 向上させる高レバレッジ戦略を強調しています。Ruff（高速リンター）、uv（依存関係解決ツール）、ty といった人気ツールへの継続的なサポートが含まれ、これらを Codex の AI コーディングアシスタントに統合する計画です。Astral のツールチェーンはゼロから数億件の月間ダウンロードへと成長し、Accel が主導した Casey Aylward 氏によるシード資金調達と Andreessen Horowitz が牽引した Jennifer Li 氏によるシリーズ B 資金調達で支えられています。創業者は Astral チームのユーザー重視の製品品質に感謝し、今後も高い基準を維持するとともに、ユーザーの信頼への感謝を表明しました。買収後、Astral はオープンソース提供物の開発を継続し、それらを Codex と統合し、ソフトウェアエンジニアリングにおける影響力を拡大します。これにより、開発者・企業・広範なエコシステムは、生産性を加速させる AI 強化型の堅牢な Python ユーティリティ―基盤となるツールセット―を享受できます。

2026/03/20 2:16

Google、未認証Androidアプリをサイドロードするための新しい24時間プロセスを発表

## Japanese Translation: Googleは2025年後半にAndroid向けの開発者認証プログラムを開始し、開発者が認証されていない場合はサイドロードされたアプリをブロックすることでマルウェアリスクを低減することを目指します。開発者は本人確認書類を提出し、アプリ署名キーをアップロードし、25ドルの手数料を支払う必要があります。 ユーザーは「未認証パッケージを許可」オプションを有効にして認証を回避できます。設定方法は、ビルド番号を7回タップして開発者向けオプションを解除し、スイッチを切り替えてPIN/パスワードで確認し、デバイスを再起動します。その後24時間待ち、次に「一時的に許可」または「無期限に許可」を選択します。24時間の遅延は、高度なソーシャルエンジニアリング攻撃を抑止するためです。 Googleは非Playソースからマルウェアに遭遇する確率が約50倍高いと引用し、このプログラムでそのリスクを低減すると主張しています。検証機能はすでにAndroid 16.1（2025年後半にリリース）に組み込まれており、全てのサポート対象デバイスで利用可能です。実施開始はブラジル、シンガポール、インドネシア、タイで2025年9月から行われ、2026年には世界中へ展開されます。 このプログラムは手数料などのハードルを追加するため、制裁対象国の開発者にとって不利になる可能性がありますが、Googleはその方針がそのような開発者を排除することを意図していないとし、検証済み開発者リストを非永続化に保ち法的課題を回避すると述べています。プライバシー擁護派は検証済み開発者のデータベースについて懸念を示し続けています。