UDPspeeder：用前向纠错把高丢包链路改造成可用链路

它解决什么问题：高延迟链路上的丢包不是靠重传能解决的

普通 TCP 遇到丢包就重传，延迟越高，重传的代价越大。在 100ms 延迟、10% 丢包的链路上，TCP 单线程下载速度会急剧下降，因为每个丢失的包都要等一个往返时间才能被发现并重发。UDPspeeder 的思路不是重传，而是发送冗余数据。它在发送端把原始数据分块，每 20 个包额外生成 10 个冗余包，接收端只要收到足够多的包就能恢复出全部原始数据，不需要等待重传。这个机制对延迟不敏感，因为纠错是即时完成的。它的目标用户很明确：在跨国线路、卫星链路、或者无线环境里，延迟和丢包同时高，而你又不想换 ISP 的人。

Reed-Solomon 纠错：数学上怎么把丢包补回来

UDPspeeder 使用的 FEC 算法是 Reed-Solomon 码。这是一种非二进制的循环纠错码，基于有限域上的多项式。简单说，发送端把原始数据看作多项式的系数，然后计算额外的校验符号。接收端只要收到足够多的符号，就能通过解方程恢复出缺失的部分。在 UDPspeeder 的语境里，`-f20:10` 表示每 20 个原始包生成 10 个冗余包，总共发送 30 个包。接收端只要收到其中任意 20 个，就能还原出全部 20 个原始包。这意味着它能容忍最多 10 个包的丢失，也就是 33% 的丢包率。但代价是带宽开销增加了 50%，因为 20 个包变成了 30 个。这个比率是可调的，你可以用 `-f10:2` 减少开销，但容错能力也下降。文档里说，调好参数后可以把丢包率降到 0.01% 以下，但具体数字取决于你的链路质量和参数选择。

单独用只能救 UDP，想救 TCP 必须套一层 VPN

UDPspeeder 的 README 说得很直白：单独使用时，它只改善 UDP 连接。因为它的隧道本身是 UDP 封装的，TCP 流量如果直接走这个隧道，TCP 的重传机制和 FEC 的冗余机制会互相干扰，效果反而更差。要让 TCP 和 ICMP 也受益，你需要先建立一个基于 UDP 的 VPN，比如 OpenVPN、L2TP 或 ShadowVPN，然后把 VPN 的 UDP 流量塞进 UDPspeeder。这样，VPN 内部的 TCP 流被封装成 UDP，UDPspeeder 对这部分 UDP 做 FEC，接收端还原后再交给 VPN 解封装。文档确认 OpenVPN、L2TP、ShadowVPN 都支持，并且提供了 OpenVPN 的配置指南链接。这个设计很巧妙，但也意味着部署复杂度翻倍：你要同时维护 VPN 和 UDPspeeder 两个隧道，任何一个出问题都会断连。

跑起来很简单：两条命令，但参数必须两侧一致

从 README 给的例子看，部署只需两个进程。假设服务器 IP 是 44.55.66.77，服务器上有个 UDP 服务监听 7777 端口。服务端运行 `./speederv2 -s -l0.0.0.0:4096 -r 127.0.0.1:7777 -f20:10 -k "passwd"`，客户端运行 `./speederv2 -c -l0.0.0.0:3333 -r44.55.66.77:4096 -f20:10 -k "passwd"`。这样客户端本地的 UDP 3333 端口就等价于服务器端的 7777 端口，而且经过了 FEC 增强。关键点是 `-f` 和 `-k` 参数必须两侧一致，否则无法通信。`-k` 是简单的 XOR 加密，不设置就完全明文。这只是一个最简示例，实际部署中你可能需要调整 MTU、超时时间等参数，这些在完整选项列表里都有。

动态调参：用 FIFO 管道在不重启的情况下改配置

一个值得注意的细节是 `--fifo` 选项。你可以用一个命名管道向运行中的进程发送命令，比如 `echo fec 19:9 > fifo.file` 就能把冗余比率从 20:10 改成 19:9，`echo mtu 1100` 调整 MTU，`echo timeout 5` 改超时，`echo queue-len 100` 改队列长度，`echo mode 0` 切换模式。这在实际运维中很有用，因为你不必为了调整参数而中断正在进行的 VPN 连接。但这也意味着你需要一个能写入命名管道的 shell 环境，而且命令格式必须严格匹配，写错一个空格可能就无效。这个功能的设计思路是好的，但文档没有详细说明错误处理，实际使用时需要自己实验。

平台与生态：Linux 为主，Windows 和 macOS 要靠虚拟机

UDPspeeder 官方支持的平台是 Linux 主机，包括桌面版、Android 手机或平板、OpenWRT 路由器、树莓派。对于 Windows 和 macOS，官方给出的方案是运行一个 7.5MB 的虚拟机镜像，这个镜像是从 udp2raw-tunnel 项目发布的链接里下载的。这显然不是一个原生体验，但至少提供了可行的路径。如果你在 OpenWRT 路由器上跑，可以直接用二进制包，资源占用应该很低，因为代码是 C++ 写的，没有运行时依赖。另外，项目还提到两个相关项目：tinyfecVPN 把 UDPspeeder 的功能内建到 VPN 里，udp2raw-tunnel 可以把 UDP 伪装成 TCP 来绕过某些 ISP 对 UDP 的 QoS 限速。如果你遇到 ISP 对 UDP 限速，UDPspeeder 单独用可能效果不佳，需要配合 udp2raw。

局限与替代方案：带宽代价和适用边界

UDPspeeder 最大的局限是带宽开销。冗余包不是免费的，`-f20:10` 意味着 50% 的额外流量。如果你的链路带宽本来就紧张，FEC 可能会让情况更糟，因为冗余包会挤占有效数据的带宽。另一个问题是它只针对丢包，不处理抖动和乱序。如果链路是拥塞导致的丢包，FEC 只是掩盖症状，不会缓解拥塞。文档里测试的链路是 100ms 延迟和 10% 双向丢包，这是一个理想化的场景。在真实互联网上，丢包往往不是均匀分布的，Reed-Solomon 对突发丢包的容忍度取决于块大小，块越大越能应对突发，但延迟也越高。替代方案是 tinyfecVPN，它把 FEC 直接内建在 VPN 层，省掉了单独跑 UDPspeeder 的步骤，但你需要放弃对隧道参数的独立控制。另一个方向是使用 KCP 这类基于 UDP 的可靠传输协议，它用重传而不是 FEC，延迟更低但带宽消耗可能更高。

维护状态与许可证：MIT 但停更两年

UDPspeeder 的代码采用 MIT 许可证，这意味着你可以自由使用、修改和商用，只要保留版权声明。但要注意，仓库最后一次推送是 2023 年 2 月 7 日，最近一次发布是 20230206.0，之后就没有新提交了。这不是一个活跃维护的项目，意味着新内核、新编译器或新平台上的兼容性问题可能没人修。如果你打算在生产环境使用，你需要自己承担编译和调试的风险。不过，MIT 许可证允许你 fork 并自行维护，社区里也可能有第三方分支。从版本号看，2023 年的版本相比 2021 年有更新，说明项目在停止前仍在迭代。升级成本方面，如果你从旧版本升级，需要重新编译并测试参数兼容性，因为 `-f` 的语法没有变化，但内部算法可能调整过。

编辑结论

UDPspeeder 适合那些链路丢包率在 5% 到 20% 之间、带宽有余量、且你愿意折腾配置的 Linux 用户，尤其是 OpenWRT 路由器或树莓派上的远程访问场景。它不适合丢包率极低或带宽本身就紧张的环境，因为冗余包会直接吃掉额外带宽。如果你需要同时改善 TCP，必须搭配 OpenVPN 或 L2TP 这类 UDP 型 VPN，单独跑 UDPspeeder 对 TCP 无效。动手前先确认你的服务端和客户端都使用同一版本的二进制，并且仔细阅读 Wiki 中的 OpenVPN 配置指南，因为参数 `-f` 的比值（如 20:10）直接决定冗余度和有效吞吐，调错会让链路更慢。另外，MIT 许可证允许商用和修改，但代码自 2023 年 2 月后没有新提交，遇到问题需要自己读 C++ 源码或依赖社区旧帖。

官方来源

1. Official README
2. Project repository
3. Release notes