Noq: n0의 새로운 Rust 기반 QUIC 구현체
(iroh.computer)- 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의 1급 경로 개념으로 통합
- 각 경로별 혼잡 제어 상태를 유지하며 최적의 경로 선택 가능
- 기존에는 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 채널을 통해 프로젝트 참여 가능
Hacker News 의견들
-
이 스레드에서 Iroh 팀이 fork를 결정하는 과정을 서로 존중하며 논의하는 모습이 보기 좋았음
- 정말 멋진 상호작용이었음. 과거에는 유지보수자들이 fork를 적대적 행위나 “우리 코드를 훔친다”는 식으로 받아들이는 경우가 많았는데, 이번엔 달랐음
내부 변경사항을 upstream으로 다시 올리는 게 얼마나 어려운지도 잘 드러남. 그들은 자신들의 변경을 수백 개의 작은 PR로 쪼개서 리뷰받을 시간이 없다고 했음. 회사 입장에서는 너무 큰 시간 투자이기 때문임
그래도 원 프로젝트와 구현 세부사항을 가깝게 유지하길 바람. 충분히 안정화된 후에는 작은 단위가 아닌 큰 덩어리 단위 병합도 가능할 것 같음 - 이런 예의 바른 대화는 오픈소스 커뮤니티의 흔한 드라마와는 대조적이라 보기 좋았음
- 정말 멋진 상호작용이었음. 과거에는 유지보수자들이 fork를 적대적 행위나 “우리 코드를 훔친다”는 식으로 받아들이는 경우가 많았는데, 이번엔 달랐음
-
iroh는 개인용 애플리케이션을 빠르게 만드는 시대에 잘 포지셔닝된 제품처럼 보임
나는 이를 이용해 “app relay”를 만들어보고 싶었음. 사용자가 별도 설정 없이 자신의 네트워크 내 앱이나 데이터를 원격으로 접근할 수 있는 zero-config OSS 솔루션을 구상 중임. 이는 Tailscale 같은 네트워크 릴레이와는 다름- 실제로 zero-config는 구현이 까다로움. 나는 mDNS 기반 디스커버리를 다양한 홈 네트워크에서 구현해봤는데, 라우터들이 멀티캐스트를 차단하거나 제한하는 경우가 많았음. 결국 여러 fallback 계층을 쌓고, 어떤 경로가 실제로 동작하는지 휴리스틱을 짜야 했음. QUIC에 multipath가 기본 내장돼 있었다면 훨씬 수월했을 것임
- 이런 주제에 관심 있다면 awesome-tunneling 리스트를 참고하면 좋음. 특히 OpenZiti가 앱 내부에 터널을 임베딩하는 비슷한 접근을 하고 있음
-
n0 팀을 정말 좋아함. 나는 그들의 sendme CLI를 자주 써서 P2P 파일 전송을 함
- 나도 마찬가지임. 그들의 툴킷은 빠르고 안정적이며 즐거운 개발 경험을 줌. 진짜 게임 체인저 같음
- 좋은 정보 고마움. 나는 보통 magic wormhole을 쓰는데, 파이썬 모듈이 너무 많아 서버에 설치하기 부담스러웠음. 그래서 Windows SQL 서버에서는 toothpyk 같은 간단한 대안을 쓰거나 wget으로 해결했음. sendme를 꼭 써봐야겠음
-
noq/iroh가 QUIC 패킷을 중계(relay) 하는 방식이 궁금했음. QUIC은 추적이 어려운데, relay가 어떤 패킷을 어디로 보내야 하는지 어떻게 아는지, 혹은 QUIC을 다른 프로토콜로 감싸는지 궁금했음
- noq 자체는 릴레이 로직을 구현하지 않음. iroh 릴레이는 단순히 또 다른 IP 서브넷처럼 동작함
실제로는 QUIC datagram을 WebSocket으로 감싸서 전송함. 헤더에는 대상 EndpointId(ed25519 공개키)가 포함되어 있고, 핸드셰이크를 통해 송신자 EndpointId도 인증됨
즉, QUIC datagram을 HTTPS over TCP로 터널링하는 셈임. 이중 암호화이지만, UDP 차단 환경에서도 동작하고 일반 트래픽처럼 보이도록 설계했음
- noq 자체는 릴레이 로직을 구현하지 않음. iroh 릴레이는 단순히 또 다른 IP 서브넷처럼 동작함
-
iroh 팀은 여전히 빠른 속도로 발전 중임
주말에 시간을 내서 iroh로 Nebula 같은 오버레이 네트워크를 만들어볼 계획임 -
QUIC 같은 접근법은 여전히 연결 지속성을 전송 상태에 강하게 묶어두는 구조임
나는 세션 아이덴티티를 전송 계층과 완전히 분리해, 전송 실패가 단순한 복구 가능한 이벤트가 되게 할 수 있을지 고민 중임. QUIC보다 더 나아간 실용적 시스템을 본 사람이 있는지 궁금함 -
noq 코드 스니펫을 참고함
-
최근 발표된 iroh의 커스텀 트랜스포트 기능 관련 소식도 흥미로움
iroh 0.97.0 블로그 포스트에서 자세히 볼 수 있음 -
혹시 nQUIC을 확인해봤는지? Noise를 Noq에 통합하면 흥미로울 것 같음
- 실제로 실험이 있었음 → nquinn 프로젝트
noq(그리고 그 기반인 Quinn)는 자체 “Session” 트레이트를 구현할 수 있어서, TLS나 nQUIC 중 원하는 걸 선택할 수 있음
- 실제로 실험이 있었음 → nquinn 프로젝트
-
tsoding의 Noq와 혼동하지 말아야 함. 그건 “Not Coq”에서 따온 이름임