做 P2P 应用有一个绕不过去的问题。

两台设备想直连，但都在 NAT 后面。你不知道对方的公网 IP，就算知道，IP 地址随时会变。把数据传到对方，要么依赖中间服务器，要么费很大力气自己做 NAT 穿透。

大多数应用选了依赖服务器——这省事，但不优雅：服务器挂了连接断，服务器在地球另一端延迟高，服务商倒闭数据丢失。

iroh 的答案是换一个标识符：不用 IP 地址，用公钥。

你告诉 iroh"连接到那个公钥对应的设备"，iroh 负责找到它，打通 NAT，建立加密连接，如果网络切换了自动修复——你不需要关心对方的 IP 是多少。

先看连接建立的过程

iroh 的连接流程分三步：

两端各自连接 relay 服务器
        ↓
relay 协调：双方交换各自的公网地址和本地地址
        ↓
双方同时向对方发 UDP 包（hole-punch）
NAT 把对方发来的包识别为"响应"，放行
        ↓
直连建立——relay 退出，数据点对点传输
        
直连失败（严格 NAT / 企业防火墙）→ 继续走 relay，端到端加密

Relay 服务器只负责协调和兜底，不能读取传输内容，因为数据始终是用对方公钥加密的。

v1.0 刚发布，但已经跑在 2 亿台设备上了

iroh 于 2026 年 6 月 11 日发布 v1.0 正式版，经历了 65 个版本、4 年多的迭代。

不是没跑过生产的实验项目：

• • 公共 relay 服务器已见过超过 2 亿个 endpoint 创建
• • 最近 30 天仍在高速增长
• • 开发者用它做：视频流传输、LLM 分布式训练、Agent 通信、加密聊天、游戏联机、文件传输

还在 ESP32 这样的 MCU 上跑通了——4MB Flash，4MB SPIRAM，iroh 核心能在嵌入式设备上工作。

用公钥拨号，三十行代码建 P2P 连接

核心 API 设计很简洁。发起端：

use iroh::{Endpoint, NodeAddr};

const ALPN: &[u8] = b"my-app/echo/0";

// 绑定本地 endpoint，得到一个公钥标识的节点
let endpoint = Endpoint::bind().await?;

// 用对方的 NodeAddr（公钥 + 已知地址）拨号
let conn = endpoint.connect(peer_addr, ALPN).await?;

// 开一个双向 QUIC stream
let (mut send, mut recv) = conn.open_bi().await?;

send.write_all(b"hello").await?;
send.finish()?;

let response = recv.read_to_end(1000).await?;
println!("{}", String::from_utf8(response)?);

conn.close(0u32.into(), b"bye");
endpoint.close().await;

接收端注册协议处理器：

let endpoint = Endpoint::bind().await?;

let router = Router::builder(endpoint)
    .accept(ALPN.to_vec(), Arc::new(EchoProtocol))
    .spawn()
    .await?;

// 拿到本地的 NodeAddr，把它分享给对方
let node_addr = router.endpoint().node_addr().await?;
println!("我的地址: {:?}", node_addr);

对方拿到 NodeAddr（包含公钥和当前已知的地址列表），就能拨过来。就算你的 IP 变了，只要公钥不变，连接就能恢复。

切网络不断线

这是 iroh 里少有人注意但很实用的特性。

你在用 Wi-Fi 和另一台机器建了 iroh 连接，这时手机切到 4G，或者切换了 VPN。

普通 TCP 连接断了。iroh 的连接还在。

原因：iroh 的连接绑定在公钥（NodeId）上，不绑在 IP 上。网络变化时，iroh 检测到新的网络接口，重新做 netcheck 探测公网地址，通过 relay 发送新地址给对方，重新做一次 hole-punch——整个过程对上层应用透明，数据不断流。

这对移动设备场景特别有用：用户从 Wi-Fi 走到地铁，切换到 4G，连接自动修复，用户感知不到中断。

QUIC Multipath：relay 和直连是同级的路径

iroh v1.0 的一个重要技术升级：自研了 QUIC 实现 noq，完整支持 QUIC Multipath 草案标准。

之前 iroh 是在 QUIC 层之下管理多条路径（relay 路径、直连 IPv4、直连 IPv6），QUIC 本身不知道有多条路径在用。这带来了一些复杂性，比如路径切换时要重置拥塞控制器。

现在 relay 路径和直连路径都是 QUIC 层的一等公民：

• • 每条路径有独立的拥塞控制状态
• • 路径切换由 QUIC 层自动管理，不需要 iroh 在下面做额外处理
• • 延迟改善更精确，不靠 hack

对用户来说感知不到，但这让 iroh 的多路径管理更可靠，特别是在网络抖动的场景下。

上面可以跑的协议层

iroh 是底层连接库，上面有几个可以直接用的协议：

iroh-blobs：基于 BLAKE3 哈希的内容寻址文件传输。文件用哈希标识，传输时自动校验，支持 KB 到 TB 级别，断点续传天然支持（内容寻址的特性）。

iroh-gossip：发布订阅覆盖网络，按 topic 广播消息。设计上只使用普通手机能承受的资源量，适合大规模设备间的消息分发。

iroh-docs：最终一致性的键值存储，值是 iroh-blobs 的 blob。多端协作编辑，冲突自动解决，适合需要跨设备同步状态的场景。

iroh-willow：Willow Protocol 的实现，还在开发中。

这几个协议可以单独用，也可以组合：比如用 iroh-gossip 广播"我有新文件"，然后用 iroh-blobs 传输文件本身。

和同类方案的实际差距

libp2p 生态更成熟，但配置复杂，上手成本高。WebRTC DataChannel 在浏览器里方便，但不适合服务端场景。iroh 的定位是"在任何环境下用公钥拨号，连接交给库来管"，接口足够简单，同时底层足够可靠。

接进项目——让 Agent 来做

在 Rust 项目里告诉你的 Claude Code：

帮我在这个 Rust 项目里集成 iroh，实现两个节点之间的双向通信。
需要：
1. 一个发起端，连接到给定的 NodeAddr，发送一条消息，等待回应
2. 一个接收端，监听连接，把收到的消息原样返回
3. 参考文档：https://docs.iroh.computer/quickstart

非 Rust 语言用 iroh-ffi：

帮我用 iroh-ffi 在这个 Python 项目里建立一个 iroh endpoint，
能接收其他 iroh 节点的连接。
参考：https://github.com/n0-computer/iroh-ffi

iroh-ffi 提供了 Swift、Kotlin、Python、Node.js 的绑定。

几件事值得提前知道

relay 服务器不是可选的，是必要基础设施

即使你想要 100% P2P，iroh 仍然需要 relay 服务器来协调 hole-punch 过程。N0 提供公共 relay，也可以自托管（relay 代码也是开源的）。对于企业用途，关键连接不应该只依赖公共 relay。

严格 NAT 和企业防火墙下 hole-punch 会失败

hole-punch 在大多数家用路由器和运营商 NAT 下有效，但对称型 NAT（Symmetric NAT）、企业防火墙通常打不通，会自动回退到 relay。这时延迟取决于你离 relay 节点的距离。

FFI 绑定还不够成熟

Rust 之外的语言绑定（Python、JS、Swift、Kotlin）功能覆盖不完整，文档相对薄，API 稳定性不如 Rust 侧。非 Rust 项目接入前建议先评估 FFI 覆盖的功能范围够不够用。

iroh-docs 和 iroh-willow 仍在变化

iroh 核心连接层 v1.0 已稳定，但上层协议（特别是 iroh-willow）还在开发，API 可能变。生产环境接入这部分要做好版本管控的准备。

总结

iroh 解决的问题很基础：让两台设备连上对方，不管它们在哪，不管 IP 怎么变。

这个问题以前的解法通常是"靠中间服务器"或者"用户自己解决 NAT"。iroh 把这件事做成了一个库——用公钥拨号，连接的事情交给 iroh，你专注写应用逻辑。

v1.0 正式版，2 亿个 endpoint 跑过，Rust 写的，QUIC 传输，端到端加密，relay 开源可自托管。如果你在做需要设备直连的应用，这个库值得认真看。

GitHub：https://github.com/n0-computer/iroh

阅读原文：点击这里​