QUIC 增强通道：可靠传输与端口映射

:::info 学习目标完成本篇后你能够：解释 rtx 模式”TCP 流搬进 QUIC”的原理；说出 QUIC 通道不叠加包加密的原因；理解端口映射的双向数据通路。前置：第 5、7 篇完成。预计时长：60 分钟。 :::

:::note 本章术语速查（新手建议先读）

QUIC：跑在 UDP 上的新一代传输协议——自带加密（TLS1.3）、可靠、多路复用、抗丢包。
quinn：Rust 最流行的 QUIC 实现。
拥塞控制：按网络状况调节发送速率的机制（BBR 是先进算法）。
用户态 IP 栈：在程序里实现 TCP/IP（normally 由内核做）——VNT 用它把 TCP 流“接”进 QUIC。
端口映射：把“本机的一个端口”转发到“远端的某个地址
”。 :::

UDP 直发的数据面（第 7 篇）不保证可靠——TCP 重传交给内核，但在丢包严重的链路上体验很差。rtx 开关启用 VNT 的”增强通道”：在虚拟网之上跑 QUIC，把 TCP 流改造成可靠、低延迟的 QUIC 流。

原理：用户态 IP 栈 + quinn

关键洞察：QUIC 本身就是”可靠的字节流”。VNT 用 tcp_ip crate 在用户态实现 IP/TCP 栈：rtx 开启时，符合条件的 IP 包（本端发起的 TCP 流、非分片）不再走通用通道，而是喂给用户态栈——栈对内核”扮演”远端主机完成握手，把应用层的 TCP 字节流装进 quinn 的 QUIC 流发出去。对端反向还原。应用完全无感：它以为自己在对端建立了 TCP，实际跑在 QUIC 上（BBR 拥塞控制、keep-alive 5s、idle 10s）。

为什么 QUIC 包不再叠加包加密

数据面加密（第 5 篇）对 QUIC 包跳过（MsgType=Quic 直通，p2p/inbound.rs 显式分支）：QUIC 的 TLS1.3 已经提供认证加密，叠加只是浪费 CPU。FEC 仍然可叠加（QUIC 也怕丢包）。证书互信沿用第 5 篇的确定性 Ed25519 证书 + 指纹验证——一个 socket 同时装着 server_config 与 client_config（quinn::Endpoint::new_with_abstract_socket），先拨号的一方成为 client。

端口映射：把虚拟网服务”长”在物理网卡上

port_mapping（需 allow_port_mapping）解决反向问题：物理网卡上暴露一个端口，流量经 QUIC 流转发给虚拟网内的某台设备——比如在无 TUN 权限的设备（no 模式）上，把家里的 NAS 的 445 端口映射出来。数据通路：

QUIC 流上第一条消息是 protobuf QuicProxyHandshake，声明三种代理类型（TCP 代理/IP 代理/端口映射）与目标地址——一条 QUIC 连接多路复用出任意多的转发流。

与其他模块的联系

第 5 篇：确定性证书让”陌生人之间直接建立 QUIC”成为可能——无需 CA；
第 7 篇：EnhancedOutbound 在通用通道与 QUIC 通道间分流；QUIC 包仍可叠加 FEC；
第 10 篇：no 模式设备（无网卡）正是靠端口映射参与组网价值。

常见踩坑

rtx 开了但没效果——只有本端发起的 TCP 流走 QUIC；UDP 与被动接受的连接仍走通用通道；
QUIC 被防火墙拦——节点间 QUIC 用 10000 端口，检查对端可达性；
端口映射失效——检查发起端 allow_port_mapping 与目标设备是否在线。

随堂练习（带验收标准）

A 开 rtx，B 不开，A 访问 B 的 SSH。验收：日志显示该 TCP 流走了 QUIC 通道且体验明显更稳（丢包网络下）；
在 B 上配置端口映射（A
→ B 的 80）。验收：物理网卡访问 A
能打开 B 的网页；
进阶：抓 QUIC 包，确认其内容与包加密通道的密文格式不同（TLS1.3 帧结构）。