统一 TUN I/O Engine 路线图

状态：已实现原型 + Linux netns 吞吐已验证；Windows 和真实协议路径仍待外部验证

最后核对：2026-06-22

目标

统一 TUN I/O Engine 是 NexusNet L3 runtime 的共享收发层，服务 QUIC L3 和 BoringTun userspace WireGuard。目标是把 TUN/Wintun 收发从单包 read/write 迁移到批处理、预分配 packet pool 和 GSO/GRO metadata 驱动的路径。

text

OS TUN / Wintun / future helper ring
  -> TunIoEngine::recv_batch(&mut PacketBatch)
  -> SR header processor / GSO-GRO fallback / memory pool
  -> protocol workers: QUIC DATAGRAM or BoringTun
  -> TunIoEngine::send_batch(&PacketBatch)

详细实现记录以英文主文档为准：Unified TUN I/O Engine。

当前状态

领域	状态	说明
Rust packet pool	完成	`PacketBatch` 使用预分配连续 buffer 和 packet metadata。
Linux VNET TUN	完成 + 规划	`LinuxVnetTunIo` 创建 `IFF_VNET_HDR` TUN，解析 10-byte `virtio_net_hdr`，并通过 read/writev 收发。sudo 下 Linux smoke 已通过；本机 netns release/offload/GSO 透传单 TCP 流已达 10.44 Gbps。默认只透传 TCP GSO，UDP GSO 拆分，避免本机队列 burst loss。
Userspace GSO/GRO fallback	完成 + 规划	TCP/UDP IPv4/IPv6 split/coalesce 已有本地测试；仍需更多 fuzz-derived 边界样例。
Wintun adapter	本地完成 + 规划	FFI adapter、DLL loader shape 和 synthetic ring tests 已存在；真实 Windows driver/ring 验证仍未完成。
QUIC L3 batch path	完成 + 规划	QUIC L3 transport 已接入 `PacketBatch`；Quinn TLS DATAGRAM + 自签证书 + CONNECT-IP worker 已完成 loopback release 吞吐验证；allocation instrumentation 仍待补。
BoringTun batch path	完成 + 规划	raw-IP WireGuard 路径已接入 `PacketBatch`；Linux 下 batch send 使用预分配 strided slab + `sendmmsg`；真实 BoringTun 加解密 loopback release 吞吐已验证。
SR header processor	Prototype complete	in-place hop advance/strip 已实现；生产 HMAC、过期 hop 和 loop counter 待最终 wire policy。

验证

2026-06-22 已完成本机 sudo smoke：

text

sudo -n env PATH="$PATH" cargo run --manifest-path nexus-agent/Cargo.toml --bin perf-test -- tunio-real nntio-smoke 1500 8 10
  Linux VNET TUN smoke PASSED.

同一轮已有本地检查覆盖 tun_io、fallback_、Windows target cargo check --target x86_64-pc-windows-gnu、perf-test tunio 10 零分配热路径、 QUIC TLS L3 和 BoringTun WG L3 全协议链路吞吐。

2026-06-22 已完成本机 Linux netns 吞吐压测：

kernel：6.12.90+deb13.1-cloud-amd64
路径：netns A -> VNET TUN -> perf-test Rust relay -> VNET TUN -> netns B
MTU：1500
batch size：128
说明：这轮只隔离 TUN movement 成本，没有经过 QUIC 或 BoringTun 加密。

场景	TCP P1	TCP P4	UDP	结论
kernel veth baseline，无用户态 relay	16.85 Gbps	66.16 Gbps	10 Gbps 目标下 2.17 Gbps，0.46% loss	本机 netns/veth 上限参考。
debug build，TUN offload 关闭	0.26 Gbps	0.25 Gbps	1 Gbps 目标下高丢包	不是架构上限，只说明 debug + 无 offload 很慢。
release build，TUN offload 关闭	4.38 Gbps	未重跑	1 Gbps 目标下 1.00 Gbps，0.00% loss	TCP retransmit 很多，plain MTU path 很早 CPU-bound。
release build，offload 开启，split/GRO relay	6.86 Gbps	6.35 Gbps	2 Gbps 目标下 1.99 Gbps，0.12% loss	正确使用 VNET，但 split 后再 GRO 浪费 CPU。
release build，offload 开启，GSO metadata 透传	10.44 Gbps	8.13 Gbps	2 Gbps 目标下 2.00 Gbps，5.21% loss	当前本机 TUN relay 最好结果；TCP retransmit 为 0。

数据结论：

之前的 0.26 Gbps 是错误参考点：debug binary、offload 关闭、临时 relay 都让它偏低。
Linux VNET 到 VNET 的高吞吐路径应该保留内核给出的 GSO metadata；拆成 MTU 小包再合并会消耗不必要 CPU。
已修复 GSO 超包落在 batch 尾部时的 packet batch is full 问题：现在会暂存 pending GSO，下次 recv 继续吐出。
10.44 Gbps 证明本机 TUN movement 层单 TCP 流可以到 10G 级别，但不代表 QUIC REALITY 或 BoringTun end-to-end 已达标。
TCP P4 低于 P1，说明当前单 relay loop 还有调度或队列争用。
UDP 2 Gbps 下曾有 5.21% loss；当前修复策略是默认只保留 TCP GSO，UDP GSO/USO 进入用户态后拆成普通包，除非显式开启 UDP offload。相关 send/recv 行为已有回归测试。

2026-06-22 已完成 QUIC 和 BoringTun 全协议链路 release 吞吐压测：

说明：这轮不测试 REALITY。QUIC 使用 Quinn + rustls 自签证书 + DATAGRAM + CONNECT-IP frame；BoringTun 使用 userspace WireGuard、X25519 key、PSK、UDP loopback。
命令：cargo run --release --manifest-path nexus-agent/Cargo.toml --bin perf-test -- <quic-tls-l3|boringtun-l3> 1000000 1200 128
参数：1,000,000 包，内层 IP payload 1200 bytes，batch size 128。

路径	Run 1	Run 2	Run 3	中位数	丢包
QUIC TLS L3，Quinn DATAGRAM，CONNECT-IP worker	1.43 Gbps	1.51 Gbps	1.48 Gbps	1.48 Gbps / 0.15 Mpps	0.00%
BoringTun WG L3，raw-IP worker，Linux `sendmmsg` batch send	1.77 Gbps	1.70 Gbps	1.58 Gbps	1.70 Gbps / 0.17 Mpps	0.00%

结论：

这些数字包含 TLS/WireGuard 加解密、L3 frame encode/decode、socket I/O 和 protocol worker batch path，不等同于 10.44 Gbps 的纯 TUN movement ceiling。
当前协议链路瓶颈仍在逐 DATAGRAM crypto、Quinn pacing/congestion、BoringTun 每包 WireGuard 状态机和 UDP socket I/O。
BoringTun batch send 切到预分配 slab + Linux sendmmsg 后，减少了 UDP syscall 和 per-packet copy。

剩余工作

UDP USO 不可用 kernel 的兼容性测试。
真实 Windows Wintun driver/ring 验证。
多流 TCP 和 UDP loss 的 profiling，包括 CPU pinning、multiqueue 和更大 socket/TUN queue。
多流协议链路 benchmark，避免单 sender/receiver task 串行化，并同时记录 CPU 使用率。

统一 TUN I/O Engine 路线图 ​

目标 ​

当前状态 ​

验证 ​

剩余工作 ​

统一 TUN I/O Engine 路线图

目标

当前状态

验证

剩余工作