点对点加密文件传输:技术指南
构建点对点加密文件传输系统。NAT穿透、信令服务器和端到端加密实现。
《网络安全法》（CSL）第二十一条要求网络运营者采取技术措施防止网络数据泄露。点对点文件传输将字节直接在两个浏览器或设备间发送，文件永远不触及服务器——这是满足"数据最小化接触"原则的架构实践。WebRTC（由 RFC 8825 至 8837 标准化）提供传输层：基于 UDP 的 DTLS 1.3 加密数据通道，通过 ICE、STUN 和 TURN 进行 NAT 穿透，通过 WebSocket 或 HTTP 进行信令交换。
为何选择 P2P 文件传输
吸引力显而易见：服务器不存储文件，传输服务无带宽账单，发送方的上传即是接收方的下载，无中间副本。同一千兆局域网内的两个用户传输 10 GB 文件，P2P 可在 80 秒内完成；云中继方案则需先上传至远端服务器再下载，带宽用量翻倍，延迟也更高。隐私也是卖点——文件字节仅存在于发送方和接收方的设备上。代价是：双方必须同时在线，NAT 穿透有时失败，连接速度受制于较慢一方的上行带宽。
WebRTC 数据通道作为传输层
WebRTC 最初是视音频协议，但 RTCDataChannel 提供了任意二进制消息传输，支持可靠有序（类 TCP）或不可靠无序（类 UDP）两种投递模式。底层数据通道运行在 SCTP over DTLS 1.3 over UDP 之上。DTLS 层通过 AES-128-GCM 或 ChaCha20-Poly1305 在握手期间协商，提供机密性和经过验证的完整性。文件传输时，创建可靠有序通道，将文件分为 16 KB 或 64 KB 的消息块（Chrome 历史上限制消息大小为 256 KB），通过 bufferedAmount 阈值实现流量控制后依次发送。
信令服务器的角色
WebRTC 需要信令服务器在对等方之间交换连接信息（SDP offer/answer、ICE 候选项）。信令服务器不中继文件字节，只传输约 5 KB 的连接元数据。基于 WebSocket 的信令服务用 Node.js、Python 或 Go 几百行代码即可实现。Firebase Realtime Database、Supabase Realtime 和 Pusher 都可作为信令后端。信令服务器知道谁在和谁通信以及何时通信，但永远看不到文件内容。大多数 P2P 文件传输服务免费运行信令，因为带宽消耗微不足道。
NAT 穿透：STUN、TURN 与 ICE
大多数设备位于 NAT 后面，直接 IP 连接不可能。ICE（交互式连接建立，RFC 8445）尝试多条连接路径。STUN（RFC 8489）让对等方通过公共 STUN 服务器发现其公网 IP 和端口，Google 免费运行 stun.l.google.com。若双方都有合理的 NAT（全锥型或受限锥型），直接 UDP 连接成功率约 70%。对于对称 NAT、企业防火墙和 CGNAT，TURN（RFC 8656）通过服务器中继流量。TURN 服务器代价高昂，因为它们承载实际文件字节。自托管的 coturn 或 Cloudflare Calls 提供了选择。实际中约 10–30% 的 P2P 传输会回退到 TURN。
DTLS 上层的加密
DTLS 已加密 WebRTC 数据，在此之上添加应用层加密是双重保险。DTLS 握手验证对等方证书，但 WebRTC 通常使用自签名证书——它验证连接到签署 SDP 的同一对等方，但不验证身份。使用从信令会合派生的共享密钥进行 AES-256-GCM 应用层加密，可增加身份确认。Magic Wormhole 的 SPAKE2 PAKE（密码认证密钥交换）从简短的人类可读短语派生强密钥，即使信令服务器被攻破也无法解密。
P2P 文件传输的分块策略
WebRTC 数据通道有消息大小限制（大多数浏览器为 256 KB，更大消息分片可行但不可靠）。每条消息按 16 KB 至 64 KB 分块以保证兼容性。通过 bufferedAmount 和 bufferedAmountLowThreshold 实现背压控制：缓冲区超过 1 MB 时暂停发送，降至 256 KB 以下时恢复。为确保完整性，对每个块计算 SHA-256 哈希，并将哈希包含在首先发送的清单中。接收方重组、验证哈希，并通过 File System Access API 或 Blob 下载写入磁盘。
安全威胁：P2P 特有的风险
P2P 引入了云中继没有的威胁。IP 地址泄露：直接连接将每个对等方的公网 IP 暴露给对方，在隐私敏感场景（举报人、维权人士）中可能造成人身风险。部分 P2P 服务强制使用 TURN 中继来隐藏 IP，但会牺牲性能。恶意软件分发因服务运营方永远看不到文件内容而难以审核。信令服务器的 DoS 连接耗尽需要速率限制。对于极度敏感的传输，Tor 洋葱服务可在信令前端隐藏双方 IP，但延迟代价沉重。
云中继仍然胜出的场景
对于发送方和接收方不同时在线的异步传输，P2P 完全失效——没有对等方可以接收。对于超出会话窗口的大型传输（移动浏览器标签页关闭，笔记本电脑进入睡眠），云中继的"上传并分享链接"模式实际上更实用。对于一对多分发，单次上传加 CDN 分发优于同时运行 N 个 P2P 会话。HexaTransfer 采用云中继模式配合客户端 AES-256-GCM 加密，以更好的异步支持和多接收方支持，获得了 P2P 的大部分隐私优势。
立即体验：https://hexatransfer.com——免费，无需注册，最大支持 10 GB。