Iroh 1.0 - IP가 아니라 키로 연결 - 임의 기기 연결용 네트워킹 라이브러리

 (iroh.computer)
1P by GN⁺ | ★ favorite | 댓글 2개
  • Iroh 1.0은 첫 안정 릴리스이며, wire protocol과 언어 API 안정성을 보장해 iroh v1 endpoint끼리 minor version이나 언어와 관계없이 통신 가능함
  • Rust crate에 더해 Python, Node.js, Swift, Kotlin을 공식 지원하며, Swift iOS 애플리케이션과 Kotlin Android 앱에 iroh를 임베드할 수 있음
  • wire 안정성에 영향을 주는 변경은 항상 major release와 함께 발생하며, 향후 언어 API 버전과 wire 호환성은 독립적으로 버전 관리될 수 있음
  • 1.0 이후 major와 minor version은 지원 일정에 따라 지원되며, 0.35 minor version은 추가 릴리스를 받지 않음
  • Public relay 지원은 v1.0은 End of Life까지, v0.35x는 2026년 12월 31일까지, v0.9x와 v1.0.0-rcX는 2026년 9월 30일까지 운영됨
  • public relay는 각 릴리스 직후 보통 24시간 안에 최신 버전으로 올라가며, wire-breaking relay 변경은 기존 클라이언트가 계속 동작하도록 새 URL을 사용함
  • 연결 기능은 QUIC multipath, QUIC NAT traversal, local-first 구성, WASM 및 브라우저 실행, 연결 제어 hook, custom transport 지원을 포함함
  • 연결에서 데이터의 95%가 기기 간 직접 전송되는 것이 일반적이며, 직접 연결은 클라우드 경유 hop과 egress 비용을 줄인다는 설명임 {p:95}
  • public relay의 relayed traffic에는 rate limit이 있으며, 해당 제한은 언제든 변경될 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Iroh를 처음 본다면 대략 네트워크 계층이 아니라 애플리케이션 계층의 Tailscale로 이해하면 됨
    “그냥 Tailscale 쓰면 되지 않나?”는 앱 개발자 관점에서 보면 다름. 앱 인스턴스끼리 쉽게 연결되게 하려면 이론상 Tailscale 기능을 앱에 내장할 수 있지만, 그러면 사용자에게 Tailscale 계정이 필요하고 앱도 Tailscale에 의존하게 됨
    Iroh는 이 기능을 직접 내장할 수 있게 해주고, 공개 예비 릴레이도 제공함. 앱이 공개 릴레이로 감당하기 어려울 만큼 커지면 자체 릴레이로 바꾸는 것도 스위치 하나에 가까움

    • 이 설명을 보고서야 Iroh가 뭘 하는지 영상보다 더 잘 이해됨. 이제 궁금한 건 Iroh가 이걸 어떻게 구현하는지임
    • 이제 가치 제안이 이해됨. 랜딩 페이지보다 설명을 훨씬 잘했으니 마케팅 문구를 맡겨도 될 정도임
    • “왜 Tailscale을 쓰지 않나”에 대한 답은, Tailscale이 돈을 벌려는 회사이고 우리가 분산 기술을 소수의 중앙 소유자에게 계속 집중시키는 건 어리석기 때문이기도 함
      특히 Iroh가 올바른 방식으로 하기를 이렇게 쉽고 훌륭하게 만들어준다면 더 그렇다
    • 정확히 그거임. “우리 앱에 Tailscale을 같이 배포할 수 있을까?”라고 생각하다가 Iroh를 찾았던 것 같음
      사용자가 로컬 인스턴스에 접근해야 하는 환경에서는 Iroh가 게임 체인저가 될 수 있다고 봄. 우리에게는 휴대폰이나 다른 기기에서 소프트웨어를 쉽게 제어하게 해주는 용도임
      예전에는 같은 LAN에 있는지 확인해야 했을 수 있지만, Iroh를 쓰면 어떤 환경에서도 동작함
    • 가장 가까운 비교 대상은 OpenZiti임
      Iroh와 OpenZiti는 둘 다 앱에 내장 가능하고, 서비스에 내장하려는 앱 개발자에게 둘 다 좋은 사용 사례가 됨
      OpenZiti는 규모와 보안이 중요한 서비스에 쓰이고, Iroh는 사전 관계가 없는 참여자도 함께할 수 있게 해줘서 매우 편리할 수 있음

  • Iroh 개발자 중 한 명임
    자주 나오는 질문은 Iroh가 언제 WebRTC, BLE, LoRa 등을 지원하느냐임
    현재 Iroh는 기본으로 IPv4, IPv6, 릴레이 전송만 지원함. 흥미로운 전송 방식이 너무 많아서 전부 지원하려 들면 코드베이스가 유지보수 불가능한 기능 플래그 미로가 됨
    대신 사용자 정의 전송을 구현할 수 있게 했고, 전송 구현은 완전히 별도 크레이트에 둘 수 있음
    기존 실험적 사용자 정의 전송에는 Tor, Nym, BLE가 있음. https://github.com/mcginty/iroh-ble-transport
    내부 동작 방식은 여기서 볼 수 있음: https://www.iroh.computer/blog/iroh-0-97-0-custom-transports...

    • 문서를 보다가 꽤 멋진 프로젝트처럼 보였고, P2P 채팅 예제도 찾았음
      이걸로 P2P 클라이언트/서버 구성이나 두 피어 머신을 만들면, 두 애플리케이션 사이 연결을 위해 추가로 뭘 설정해야 하는지 한계가 궁금함
      예를 들어 휴대폰에서 실행되는 앱과 노트북에서 실행되는 앱을 만들면 둘 사이에 직접적이고 안전한 연결을 실제로 얻을 수 있는 건지, 아니면 다른 문제를 푸는 건지 알고 싶음
      -[0]: p2p chat, in rust, from scratch: https://www.youtube.com/watch?v=ogN_mBkWu7o
    • 예전에 libp2p 기반으로 많이 만들어본 입장에서, 앱 개발자 중심의 최신 비교를 보고 싶음
      작년에는 둘 중 하나를 고르다 익숙한 쪽을 택했지만, 지금은 Iroh 쪽에 확실한 추진력이 있는 느낌임
    • 공개 릴레이를 운영할 때 위험이 있다면 무엇인지 궁금함. 개념적으로 Tor Guard Node나 릴레이를 운영하는 것과 비슷한지 알고 싶음
    • Tor 전송은 https://github.com/n0-computer/iroh-tor-transport에 있음
      여기서는 Tor 데몬을 쓰고 있음. Tor에는 Rust 구현이 있고 Rust에서 쓰면 스트림 객체 같은 형태로 사용할 수 있음
      사용 예시는 https://gitlab.torproject.org/tpo/core/oniux에서 볼 수 있음
    • 유지보수 불가능해질까 걱정된다면 기능 플래그 API를 고려해볼 만함
      전략 패턴과 중앙화된 기능 관리가 좋음

  • “Dial keys”가 영상에 있었는지는 모르겠지만, 첫 문단에서 어떤 종류의 키이고 왜 필요한지 분명히 해야 한다고 봄
    암호학적 키인지, 비대칭 키인지, 가장 기본 수준에서라도 어떻게 동작하는지 설명이 없음. 곧바로 추상적인 우월성 주장과 사용량 통계로 들어감
    릴레이가 관련된 것 같은데, HN 토론에서 찾아내게 만들 게 아니라 처음부터 말해주는 편이 좋음

    • 첫 페이지가 깊이 들어가지는 않지만 문서는 금방 설명함
      먼저 https://docs.iroh.computer/what-is-iroh가 있고, 이어서 작동 방식 섹션이 있음. 지금까지 보기에는 문서가 실제로 괜찮고, 나온 질문들은 꽤 빨리 답해주는 듯함
    • 영상을 봤는데도 그것들이 뭔지 아직 모르겠음. 또 “절대 종속되지 않는다”고 하면서 “pricing”이 있고, 릴레이는 셀프 호스팅한다면서 왜 “apps”에 돈을 내는지도 모르겠음
    • “Dial keys. Not IPs.”라는 설명은 내게 DNS 재구현처럼 들림
      분산형일 수도 있고 무료일 수도 있고 단일체가 아닐 수도 있지만, 넓게 보면 같은 범주임
    • “keys”를 읽었을 때는 .ssh/config의 이름 붙은 호스트처럼 키로 접근하는 “이름”이라고 생각했음
      그런데 더 들어보니 QUIC 위에서 네트워킹하는 새로운 방식처럼 들림
    • 한동안 이해하려고 해본 결과, 이 키들은 암호화 키이자 WebRTC 영상 통화에 쓰일 수 있는 세션 쿠키 같은 안정적 식별자라는 이중 역할을 하는 것 같음
      전문가도 아니고 오늘 처음 본 프로젝트라는 점을 감안한 Lobste.rs 요약은 이렇다: 이는 클라이언트에 지속 ID를 배정하는, 의견이 강한 WebRTC 설정에 더 가까움. 시그널링 서버를 만드는 작업이 처리되어 있고, 해결책이 충분히 범용적이고 저렴해서 커뮤니티 호스팅 서버를 써도 됨. Steam의 독점 P2P gamenetworkingsocket 인프라에서 얻는 것과 약간 비슷함
      https://lobste.rs/s/cslljn/iroh_1_0_dial_keys_not_ips#c_s3na...

  • 애초에 어떤 문제를 풀려는지 이해가 안 됨. IP와 DNS는 잘 동작함
    이미 IPv6와 QUIC가 있고, 이 분야에서 의미 있는 견인을 얻으려면 벤더와 주요 소프트웨어가 필요함

    • Iroh는 QUIC임. 바퀴를 다시 발명하려는 게 아니라 기존 IETF RFC들을 창의적으로 조합하는 것임
      구체적으로, 집 WLAN의 NAT 뒤에 있는 기기 하나와 4G 네트워크나 회사의 다른 NAT 뒤에 있는 다른 기기가 있다고 해보자
      대부분의 경우 홀 펀칭으로 두 기기 사이에 매우 빠르게 직접 연결을 만들어줄 수 있고, 가능한 최고 대역폭과 최저 지연 시간을 얻음
      이 문제는 지금까지 해결된 문제가 아니었음
    • Iroh와 관련도 없고 쓰고 있지도 않지만, “IP가 잘 동작한다”는 말은 말이 안 됨. 이건 해결된 문제가 아님
    • 반대로 직접 연결을 수립하는 일은 현재 인터넷 인프라에서는 훨씬 어려운 문제임
    • 내가 보기에는 Iroh가 OSI 모델에서 빠진 세션 계층을 만들려는 것 같음. Cisco의 Location-Identity Separation Protocol도 비슷한 시도임
      TCP/IP에 진짜 세션 계층이 없기 때문에 vMotion이 보통 단일 브로드캐스트 도메인에서만 가능함. 이 상황에서는 주소 지정에 사실상 MAC 주소만 쓰고, vMotion 뒤 MAC 주소가 바뀌어도 IP를 안정적 식별자로 쓸 수 있음. 매핑은 스위치의 MAC 주소 테이블이 처리함
    • DNS는 탈중앙화라기보다 연합형에 가까움. 적어도 마지막으로 봤을 때 Iroh는 여기서 DHT를 사용할 수 있는 옵션이 있었던 걸로 앎

  • 네트워킹의 미래는 탈중앙화임. Yggdrasil과 I2P를 아주 좋아함
    24시간 돌릴 미니 PC를 사서 필요한 것을 호스팅하고, 다른 사람들과 매끄럽게 연결할 수 있어야 함. 많은 기술자들은 이미 먼지만 쌓이는 오래된 예비 머신을 갖고 있고, 이걸 서버로 만들 수 있음
    장기적으로는 도메인과 서버 호스팅을 다루는 것보다 훨씬 저렴하고 유지보수도 쉬움. Iroh 팀의 작업을 진심으로 높이 평가함

    • 그건 적어도 20년째 미래였음

  • Iroh는 작업하기 정말 좋았고 Discord 채널의 엔지니어들도 매우 친절했음
    P2P를 그냥 동작하게 만드는 실용적 접근이 이해하기 쉬웠고, YouTube 채널 콘텐츠도 훌륭함. v1 출시를 축하함
    https://youtube.com/@n0computer

  • IP 주소와 비슷한 기능을 하려는 프로토콜에 가격표가 있는 건 이상해 보이지 않나? 뭔가 오해하고 있는 걸 수도 있음

    • 이미 다른 사람들이 말했듯이 iroh의 핵심 라이브러리와 프로토콜은 완전 오픈소스임
      다만 개발 비용을 충당하기 위해, 특히 더 크거나 특수한 사용 사례에서 배포와 운영을 쉽게 해주는 추가 서비스를 제공함
    • Tailscale 증후군임
      “사람들에게는 인프라가 되고, 전문가에게는 비즈니스가 되고 싶다”는 상태임
      “운영하려면 돈이 필요하다”와 “공공재 인프라 시스템이 되고 싶다” 사이에 끼어 있고, 영리 기업의 부정적인 부분은 “그래도 오픈소스잖아”로 치워짐
      “오픈소스”라는 단서가 완전히 맞춤형이고 이해 불가능한 코드베이스를 동반하지 않는 한, 이런 비즈니스 개념은 어느 정도 괜찮다고 봄
    • 같은 가격 페이지를 보면 모두 추가 서비스임. 관측성, 릴레이 호스팅, 지원 엔지니어 같은 것들임
    • 이들이 제공하는 것을 IP 주소에 비유하면 BGP 라우터나 ISP를 운영하거나, 데이터센터 네트워킹을 위해 네트워크 엔지니어와 계약하는 것에 더 가까움
      ISP나 AS를 운영하려면 상당한 돈이 든다는 건 확실함
    • “Iroh 앱을 위한 맞춤형 호스팅과 모니터링”을 제공하는 것으로 보임

  • 회사에서 Iroh를 프로덕션에 쓰고 있고 정말 마음에 듦
    주로 Rust 크레이트로 제공되는 Tailscale식 홀 펀칭이라고 설명하겠지만, 물론 기본 QUIC 연결 위에 멋진 P2P 기능을 많이 얹을 수 있음

  • 우리 회사는 프로덕션 분산 머신러닝 학습 시스템에 Iroh를 썼고 정말 만족했음
    엔터프라이즈 지원 계약을 맺기 전부터 팀이 믿을 수 없을 만큼 빠르게 대응했고, 지식도 매우 깊었으며 라이브러리 자체도 놀랍게 잘 동작했음. libp2p보다 언제든 다시 이 라이브러리를 쓰겠음

  • 출시 축하함
    tailscale/netbird/netmaker/zerotier/twingate/openziti와 비교하는 versus 페이지가 시급히 필요함
    사용 사례만 보면 지금은 Tailscale로 못 하는 게 보이지 않음

답변달기
GN⁺   [-]
Lobste.rs 의견들

  • 여기와 HN 모두에서 Iroh가 VPN 위에 얹은 메시 네트워크(Tailscale, ZeroTier, Netbird 등)와 어떻게 다른지 헷갈려 하는 것 같음. 내 해석으로는 Iroh는 자기 앱을 실행하는 기기끼리 P2P 통신을 하고 싶은 애플리케이션 개발자를 위한 것이고, 메시 네트워크는 자신이 소유·관리하는 장비들을 서로 연결하려는 네트워크 관리자를 위한 것임
    예를 들어 P2P 메시징 앱을 만든다고 해보면, 한쪽 사용자는 WiFi와 모바일 데이터를 계속 오가는 모바일 기기라 안정적인 주소가 없고, 다른 쪽은 NAT와 CGNAT 뒤에 있는 노트북일 수 있음. IP 주소가 바뀌어도 이 둘이 통신하게 하려면 이를 처리할 메커니즘이 필요함
    예전에는 보통 앱 개발자가 운영하는 중개 서버에 양쪽 엔드포인트가 접속해 상태를 공유하는 방식이었는데, Iroh는 이를 표준화하고 서비스로 제공하려는 쪽에 가까움

    • 이해한 게 맞다면, 지속적인 ID를 클라이언트에 붙여주는 의견 있는 WebRTC 구성에 더 가까워 보임. 시그널링 서버를 만드는 작업을 대신 처리해주고, 충분히 범용적이고 저렴해서 커뮤니티 호스팅 서버를 써도 되는 구조라는 뜻임
      Steam의 독점 P2P gamenetworkingsocket 인프라에서 얻는 것과도 약간 비슷함
    • 목표 시장을 어떻게 잡는지는 알겠는데, 가격표를 보면 동시 사용자 수 기준으로 확장되고 일반 티어 상한이 5,000명임. 이건 꽤 낮은 것 아닌가 싶음

  • 뭔가 놓쳤을 수도 있지만, 모든 걸 단일 키에 걸어두는 건 굉장히 위험해 보임. 그 키를 잃어버리거나 탈취당하면 어떻게 되는지 궁금함
    Iroh 문서에서 “key rotation”을 빠르게 검색해봤지만 찾지 못했음

    • 그 키들은 공개 키임. Iroh에서는 다른 노드에 도달하기 위한 방법으로, 역시 공개 정보인 IP 주소를 대체하는 역할임
    • 키를 어떻게 저장하거나 회전할지는 개발자가 정해야 함. 여기서 키는 Ed25519 키 쌍이고, 공개 키가 신원으로 쓰이기 때문에 키를 회전한다면 새 공개 키를 어떤 방식으로든 피어들에게 알려야 함
      Iroh를 쓰는 일부 애플리케이션은 키를 영구 저장하고, 일부는 세션마다 새로 생성함
      개인 키가 유출되면 공격자가 연결을 시작하거나 받을 때 나를 가장할 수 있음. 키를 잃어버리면 피어들에게 내 신원을 증명할 수 없게 됨. 내가 이해하기로는 일반적인 비밀번호나 개인 키를 잃어버리거나 탈취당했을 때와 비슷한 위험임

  • 비슷한 대안으로는 뭐가 있을까? Host Identity Protocol? https://mkomu.kapsi.fi/hipl/index.php?index=how

  • 프로젝트를 이해하려고 하는데 키와 IP의 차이가 잘 와닿지 않음. 결국 어느 시점에는 IP 라우팅을 쓰기 위해 키가 IP 주소로 매핑되는 것 아닌가?
    키는 오래 유지되는 식별자를 IP 주소에 붙이는 방식으로서 URL이나 DNS를 대체하는 건가?

    • 맞음, “키”는 URL/DNS를 대체하지만 특정 IP에 할당되는 건 아님. Iroh는 P2P 홀 펀칭과 릴레이를 수행하고, 키는 Iroh 릴레이 서버에 게시됨. 직접 운영할 수도 있음
      한 노드를 다른 노드에 키로 연결하려 하면, 릴레이 서버 중 하나에서 그 키를 조회한 뒤 직접 IP 연결부터 홀 펀칭, 최종적으로 릴레이 서버를 통한 릴레이 연결까지 여러 방법을 시도함
      또한 키는 QUIC을 통한 종단 간 암호화에도 사용됨

  • 특정 애플리케이션용으로 자체 릴레이 서버를 호스팅할 방법이 있나? 가능해 보이긴 함. 다만 전용 릴레이 가격 페이지가 있는 걸 보면 조금 이상해 보임

    • 링크한 코드만으로도 유료 관리형 릴레이와 별개로 자체 호스팅이 가능하다고 봄
    • 맞음, 자체 릴레이 서버를 운영할 수 있고 링크한 코드가 맞음. 예를 들어 DeltaChat은 chatmail 릴레이의 일부로 이를 실행함. 기존 웹 서버 안에 릴레이를 임베드하는 사람들도 있음
      호스팅 릴레이는 직접 서버를 관리하는 번거로움 없이 이를 제공하고, 네트워크에 대한 더 많은 가시성을 주려는 목적임

  • 이건 Yggdrasil이나 Netbird보다는 Reticulum에 더 가까운 느낌임

  • 이게 뭔지 이해하기가 어렵다. Yggdrasil이 떠오르긴 하는데, 둘이 어떻게 비교되는지 잘 모르겠음

답변달기