追寻最快的 P2P 文件传输 CLI：Thruflux（公开 Alpha）

Source: Dev.to

点击此处查看 Github 仓库

我的目标

有一天，我醒来时心中燃起了一个唯一的愿望：我想打造有史以来最快的文件传输工具。
由于之前有一些自学的网页开发项目经验，我立刻转向网络，想了解现有的基于浏览器的解决方案有哪些。

人们今天使用的方式

大多数人使用流行的商业工具，例如 Dropbox、Google Drive，或是 Discord、Email 等消息媒介。
对于开发者——以及令人惊讶的许多非开发者——这些工具根本不够用。它们的局限性众所周知：

• 文件大小限制。
• 它们依赖 客户端‑服务器模型，必须先完成上传，其他人才能下载文件。
• 虽然非常适合在云端安全存储文件，但这种模型对一次性文件共享来说糟透了。
• 由于文件必须存放在服务器上，总会存在固有的安全隐患。

为什么现有的 P2P 工具不够

于是我转向了 P2P 文件传输的世界。一些流行的零配置方案包括 Blip、Magic‑wormhole、croc、scp 和 rsync。遗憾的是，它们都没有满足我的需求：

上述所有工具都依赖 TCP 连接。我最近对 QUIC 和 UDP 产生了兴趣，于是决定利用它们来超越现有工具。

核心关注点

利用 QUIC 构建最快的 CLI 传输工具，使用极其简单且速度惊人。

我定义了七条需求：

1. QUIC + ICE 实现零配置点对点传输（UDP 打洞成功率高于 TCP 打洞；QUIC 还能受益于现代拥塞控制算法如 BBR）。
2. 一流的多文件支持——传输多个文件的速度应与（或快于）同等总大小的单个文件相当。
3. 多接收者——单个会话可以随时接受新的接收者，无需重新启动传输。
4. 跨平台——支持 Windows、Linux 和 macOS。
5. 自动续传——对大文件至关重要，且必须快速。
6. 开源。
7. 速度至上——安全性保持在可接受的最低水平，性能是唯一卖点。

语言选择

虽然 Rust 和 Go 也是强有力的候选，但我最终选择 C++，原因是：

• 成熟的 QUIC/ICE 库。
• 低层可配置性。
• 零垃圾回收开销，能够最大化性能提取。

经验教训

1. 多线程 vs. 单线程——我最初认为多线程和多 QUIC 连接/流会最大化吞吐量。实际情况是，单线程配单一连接就能饱和网络，并大幅简化应用逻辑。
2. CPU 扩展——QUIC 对 CPU 性能和核心数的依赖很大。在合理的 CPU（过去 10 年内发布，≥ 2 核）上，QUIC 的表现优于 TCP；在低端设备上则表现不佳。
3. 拥塞控制与缓冲区——使用 BBR 能带来约 4 倍的吞吐提升……

相较于 CUBIC 的吞吐量。将操作系统的 UDP 缓冲区大小提升至至少 8 MiB，又带来了约 1.3× 的速度提升。

基准测试

真相时刻：将我的工具与现有工具进行基准测试。

硬件 / 环境

• Vultur 专用 CPU – 2 vCPU（AMD EPYC Genoa），4 GB RAM，NVMe SSD，Ubuntu 22.04。
• 在公共互联网环境下测试：发送方位于 芝加哥，接收方位于 新泽西。
• 方法：取 3 次运行的中位数；时间包括完整的端到端实时时间（设置 + 传输 + 拆除）。
• 仅报告 “接收阶段” 的时间。

基准测试命令（使用 time 测量实时时间）

# scp — single file
time scp test_10GiB.bin root@207.246.86.142:/root/

# scp — many files
time scp -r bench/

(此处将继续提供自定义 QUIC 工具的进一步基准测试结果。)

基准命令

# Mark files on the remote host
mark_files root@207.246.86.142:/root/

# rsync — single file
time rsync -a --info=progress2 --no-compress --whole-file --inplace \
  test_10GiB.bin root@207.246.86.142:/root/

# rsync — many files
time rsync -a --info=progress2 --no-compress --whole-file --inplace \
  benchmark_files root@207.246.86.142:/root/

# croc — single file
time CROC_SECRET="code" croc --yes

# croc — many files
time CROC_SECRET="code" croc --yes

# Thruflux — direct (single + many files)
time ./thru join --overwrite 

# Thruflux — forced TURN relay
time ./thru join --overwrite --force-turn 

# wormhole — single / many files
time wormhole receive  --accept-file

功能矩阵

即使在 6 秒的初始 P2P 握手（scp 和 rsync 没有）下，Thruflux 仍在实际耗时上击败它们。与其他 P2P 工具相比，它表现出明显优势，尤其是在 1000 文件传输时。

观察与权衡

1. CPU 受限 – Thruflux 需要更多的 CPU 资源。在低端、单核设备上，它的速度可能略慢于 rsync/scp。
2. TURN 中继回退 – 自托管的 TURN 服务器规模有限且位置不佳，因此通过 TURN（例如对称 NAT）进行的传输速度会慢于其他工具。
3. UDP 限制 – 某些网络会完全阻止出站 UDP，使得 QUIC 无法使用。
4. 连接阶段更长 – 完整的 ICE 交换会增加延迟；切换到 trickle ICE 可以降低此延迟。
5. 缺乏校验 – Thruflux 依赖 QUIC 内置的完整性检查（比 TCP 更强），但不对磁盘层面的损坏进行校验，这种情况极少但仍有可能发生。
6. 加入码熵值 – 由于没有 PAKE，加入码必须具备高熵以弥补安全性；用户通常会直接复制粘贴它。

尽管存在这些注意事项，Thruflux 在传统工具难以应对的多文件场景中表现出色。早期结果令人鼓舞，并且仍有大量改进空间。

项目状态

• Alpha阶段 – 核心功能已完成；已进行基本测试。预计会有粗糙之处，尤其是在跨平台和网络边缘情况方面。
• 欢迎反馈 – 非常重视错误报告、性能比较、边缘案例以及建设性批评。

快速入门 🚀

安装

使用

# 托管文件
thru host ./photos ./videos

# 与多个对等方共享加入代码
thru join ABCDEFGH --out ./downloads

欲了解更多详情，请参阅仓库的 README。