用Key替换IP，Iroh 1.0重新定义互联网寻址
深夜两点，你正在修复一个生产环境故障。SSH 连不上服务器 — 上次重启后 DHCP 分配了新 IP，而你的配置文件和 CI/CD 流水线里还写着旧的地址。你一边骂骂咧咧地翻云控制台，一边想：都 2026 年了，为什么通信的基础还是这样一个脆弱、动态、随时可能失效的字符串？
这不是运维的锅。这是 IP 协议的先天缺陷。IP 地址同时承担了两种身份：你是谁（标识符）和你在哪（位置符）。在早期互联网，服务器不会频繁迁移，容器也没人听说过，这两个角色绑在一起没什么问题。但今天，Pod 在集群里漂移，设备在 WiFi 和蜂窝网之间切换，居家办公者的笔记本在咖啡店和会议室之间穿梭 — 身份和位置的耦合变成了诅咒。每次网络拓扑变化，你的”地址”就变了，上层连接全部断掉。
这就是 Iroh 想要解决的问题。它不是一个应用层的框架或中间件，而是一个用 Rust 写的网络库，核心思路很 radical：用密钥对替换 IP 地址。你在 Iroh 网络里不靠 192.168.x.x 或 10.x.x.x 寻址，而是靠一个公钥。你生成了一个 ed25519 密钥对，你的公钥就是你的”地址” — 无论你在哪个物理网络里，无论你的 IP 怎么变，这个地址永远不变。
经过四年多的打磨，Iroh 刚刚发布了 1.0 版本。公开 relay 上的端点数量已经超过两亿。这不再是实验项目，它正在成为现代网络基础设施的一块基石。
为什么是 Key，不是 DNS
有人会问：那用动态 DNS 不就行了吗？每次 IP 变了，更新一下 DNS 记录，上层还是用域名访问。表面上看，这解决了”地址变化”的问题。但 DDNS 只在应用层做了一次重定向，底层 socket 仍然是绑定在具体 IP 上的。当 IP 切换发生时（比如手机从 4G 切到 WiFi），现有 TCP 连接会立刻中断，应用层必须重新建立。
Iroh 的方式更底层。它把身份验证和连接路由完全解耦。你的公钥是一个全局唯一、密码学可验证的身份。任何人想连接你，手里只要有你的公钥就够了 — 不需要知道你的 IP，不需要 DNS 解析，不需要 CA 签发的证书。连接请求通过 relay 或直接路径到达，Iroh 在握手时验证对方是否确实持有对应的私钥。
这意味着连接是自认证的。传统 TLS 依赖证书链和根 CA 来验证”这个服务器的证书是可信的”，Iroh 在传输层就做了这件事：公钥本身就是身份，伪造一个公钥没有任何意义，因为你需要对应的私钥才能完成握手。
QUIC Multipath 下的连接魔法
Iroh 1.0 的核心传输层建立在 QUIC 之上。如果你不熟悉 QUIC，可以把它理解成一个”自带加密和多路复用的现代版 TCP” — 它解决了 TCP 的头端阻塞问题，握手更快，在丢包率高的场景下表现也好得多。
但 Iroh 做了一件 QUIC 标准里刚稳定下来的事情：multipath。传统 TCP 连接是一条路径走到黑。你的 MacBook 连着 WiFi，里面跑着一条 TCP 流。当你拔掉网线走到会议室，WiFi 切到另一个 AP，底层的路由变了，TCP 发现路径 MTU 变了、RTT 变了——然后就断了。QUIC multipath 允许在同一条连接里管理多条路径。Iroh 利用这一点，在你的设备和目标之间同时维护多条可能的路线：relay 中转、直连 UDP、甚至是 Tor 或 BLE 通道。当某条路径质量下降时，流量可以无缝切换到另一条——应用层完全无感。
NAT 穿越也是 Iroh 的强项。大多数设备躲在 NAT 后面，传统 P2P 连接依赖 STUN/TURN/ICE 那一套复杂的协商流程，而且经常失败。Iroh 内置了 QUIC NAT traversal 能力，加上全球部署的 relay 网络作为保底——能直连就直连，不能直连就走 relay 中转，延迟只有一跳。
从 Rust 到浏览器：语言边界消失了
Iroh 最初是纯 Rust 项目，这在系统编程层面是正确的选择 — Rust 的内存安全和零成本抽象非常适合网络库的场景。但 1.0 版本的真正里程碑是语言绑定的稳定。现在除了 Rust 原生 API，你可以在 Python、Node.js、Swift、Kotlin 里用同样的 wire protocol 接入 Iroh 网络。
这意味着什么？一个 Swift 写的 iOS 应用，可以和 Node.js 运行的后端通过 Iroh 直接 P2P 通信，不经过云服务器中转。一个 Python 训练的 LLM 模型，可以用 Iroh 把参数分发到多个训练节点，连接自动容错。
更激进的是 WASM 支持。Iroh 可以编译成 WebAssembly 在浏览器里运行。浏览器里的 JS 代码通过 Iroh 直接与其他节点建立加密连接 — 不再需要 WebSocket 代理，不再需要 Server-Sent Events 轮询。浏览器变成了一个一等公民的 P2P 节点。
自定义传输：BLE、LoRa、WiFi Aware
这是 Iroh 1.0 里最让我兴奋的特性：可插拔传输层。Iroh 定义了一套抽象的传输接口，开发者可以实现出 BLE（蓝牙低功耗）、LoRa（远距离低功耗无线）、WiFi Aware（邻近感知网络）甚至 Tor 作为底层传输通道。
这对 IoT 场景是颠覆性的。想象一个部署在偏远农田里的传感器，没有蜂窝信号，没有 WiFi。它通过 LoRa 发送数据。传统做法是写死 LoRa 协议栈，数据格式耦合在应用逻辑里。用 Iroh，你的传感器跑一个 LoRa 传输适配器，上层逻辑完全感知不到底层是 LoRa 还是以太网。公钥身份验证和端到端加密天然可用，不需要额外实现。
Tor 适配器也很有意思。这意味着你可以让 Iroh 流量走 Tor 网络，获得匿名性。传输层是抽象的，安全模型是叠加的——在 Iroh 的端到端加密之上再走 Tor，而不是用 Tor 替换加密。
IP 会彻底消失吗
Iroh 没有试图替代整个 IP 协议栈。在大多数场景里，Iroh 运行在 IP 之上——它用 UDP 承载 QUIC，QUIC 再承载 Iroh 的密钥寻址逻辑。它更像是在 IP 层之上盖了一层”身份层”，把 IP 降级为纯粹的”路由辅助”，而不是身份标识。
但 Iroh 的方向让我开始思考一个问题：如果有一天，所有设备都用密码学身份通信，不再关心对方的 IP 地址，网络架构会变成什么样子？防火墙规则会变成”允许公钥 X 访问端口 Y”而不是”允许 192.168.1.0/24”？DDoS 防护会变成”拒绝来自公钥 Z 的流量”？运营商的 NAT 会不会彻底消失，因为每个人都是通过 relay 或直连通信，不需要 IPv4 地址的伪装？
也许十年后，“你的 IP 是什么”会变成一个像”你的调制解调器速率是多少”一样过时的问题。Iroh 告诉我们，通往那个世界的路，已经铺好了第一条轨道。
来源：Iroh Blog | Hacker News