把一份文件从电脑发送到手机，看起来只是“选文件、点发送”两个动作，背后却要经过设备发现、身份确认、网络协商、传输、校验和异常恢复等多个阶段。传统网盘通常先把文件上传到服务器，再由另一台设备下载；WebRTC P2P 文件传输则优先让两端浏览器建立加密通道，数据尽可能直接在设备之间流动。
这篇指南不要求你熟悉网络协议。我们会沿着一次真实传输的完整路径，解释直连、STUN、TURN、DataChannel、断点续传和安全校验各自解决什么问题，也说明哪些宣传口号容易造成误解。读完后，你应该能够判断一个浏览器传输工具是否真正可靠，以及遇到连接慢、速度低或刷新断线时该从哪里排查。
WebRTC P2P 文件传输是什么
WebRTC 是现代浏览器提供的一组实时通信能力。它最常用于音视频通话，也能通过 RTCDataChannel 发送文本和二进制数据。文件会被切成一系列数据块，经由浏览器维护的加密连接发往另一端，再按顺序组合成原文件。
“P2P”描述的是通信关系，不等于任何情况下都不经过第三方网络设施。能够直连时，数据包直接在两台设备之间传递；受企业防火墙、运营商级 NAT 或严格网络策略影响而无法直连时，可以通过 TURN 中继转发加密的数据包。TURN 看得到连接的流量规模和网络地址，却不应该能够读取由 WebRTC 保护的正文内容。
一次连接从开始到可传输经历什么
两台浏览器不能凭空找到彼此。首先需要一个信令服务交换连接意图和 WebRTC 协商信息。信令负责“介绍双方认识”，并不承担文件正文传输。一个完整且对用户友好的连接流程通常包含以下步骤：
- 产生本地身份：设备在本地生成长期身份密钥和可识别名称，私钥不上传。
- 发现或指定对方：可以通过临时连接码、同公网出口发现或可信邀请链接找到另一台设备。
- 明确授权：首次连接由接收方确认，防止附近或共享网络中的陌生设备直接接入。
- 交换候选地址：浏览器收集局域网地址、公网映射地址和可用中继地址，再尝试建立连接。
- 验证身份：连接建立后仍要进行应用层身份验证，确认当前通道中的远端确实是刚才授权的设备。
- 开启功能通道：聊天、剪贴板、文件和屏幕共享各自进入可用状态，并反馈清晰的成功或失败结果。
成熟的协议还要处理双方同时发起连接、页面刷新、网络从 Wi-Fi 切换到蜂窝网络、信令暂时断开、旧连接延迟到达等边界。仅在理想环境中“连上一次”并不代表连接系统完整。
STUN、TURN 和直连分别做什么
家庭和办公网络通常通过 NAT 共享一个公网地址。设备知道自己的局域网地址，却未必知道互联网中的另一端应该怎样访问自己。STUN 服务器会告诉浏览器“你从公网看起来是什么地址和端口”，帮助两端尝试穿透 NAT。STUN 只参与地址发现，不转发后续文件内容，因此成本和带宽消耗通常很低。
如果双方网络策略不允许可用的直连路径，TURN 才作为后备路径。两端都连接到 TURN，由它转发已经加密的数据包。由于每个字节都要经过中继服务器，TURN 会消耗真实出口流量，其容量、地域、权限控制和滥用防护都会直接影响速度与成本。
| 路径 | 主要用途 | 正文是否经过该服务 | 常见体验 |
|---|---|---|---|
| 局域网或公网直连 | 设备间直接通信 | 否 | 延迟低，速度受两端网络和设备影响 |
| STUN | 发现公网映射，协助穿透 | 否 | 用户通常无感，不能保证一定直连 |
| TURN | 直连失败时中继加密数据 | 是，但应保持加密 | 成功率更高，速度受中继地域和容量影响 |
因此，页面上显示“TURN 无限制”并不是一个严谨承诺。中继一定存在带宽和成本上限，专业产品应提供合理配额、速率保护和可理解的状态提示，同时避免把用户网络问题伪装成无限资源。
文件不是塞进 DataChannel 就结束了
WebRTC 提供的是可靠或部分可靠的数据通道，但应用仍要设计自己的文件传输协议。最基础的实现会不断调用 send()，直到所有数据块写完。这在小文件和直连环境中可能看不出问题，在高延迟 TURN 链路或大文件中却容易造成发送缓冲区堆积、内存增长，甚至长时间卡在 0%。
更稳妥的传输实现需要同时考虑：
- 元数据握手：先发送文件 ID、大小、类型、分块参数和摘要，等待接收方接受。
- 背压控制：根据
bufferedAmount和接收确认调节发送窗口，避免一次塞入过多数据。 - 选择性重传：接收方报告缺失区间，只补发没有收到的数据块，而不是整份重来。
- 进度语义：区分“已写入本地缓冲”“远端已确认”和“完整性校验通过”，不能提前显示完成。
- 取消传播：任意一方取消后立即发送带传输 ID 的控制消息，另一方停止读写并释放临时数据。
- 公平调度：多个文件与聊天控制消息共享连接时，不能让一个大文件阻塞所有交互。
断点续传必须和完整性校验一起设计
“支持断点续传”不能只是在界面里保留一条进度记录。接收端需要持久化已经完成的分块区间、文件总大小、摘要和来源身份；重连后，双方通过新的会话交换缺失区间，从最后一个可信位置继续。发送端刷新页面后，浏览器通常无法继续读取原本由用户选择的本地文件，所以需要用户重新选择，并先验证它与原文件一致。
传输结束后，应对完整文件计算 SHA-256 等加密摘要并与发送端声明值比较。只有摘要一致，状态才能从“接收完成”进入“校验通过”。如果摘要不一致，应明确告诉用户文件不可用，并允许补传缺失或损坏的区间。
需要注意的是，摘要校验解决的是传输过程中损坏或选错文件的问题，不自动证明发送者可信。发送者身份仍应由连接授权和密钥验证负责，这两类保证不能互相替代。
刷新、断网和双端重启如何自动恢复
用户通常希望已经授权的设备“尽可能自动恢复”，但自动恢复不能重新弹出首次授权，也不能忽略用户主动停止。应用应把长期信任关系、一次 WebRTC 会话和某个功能任务分开保存：设备仍然可信，不代表旧通道仍然有效；文件任务可以续传，也不代表屏幕共享应该在刷新后悄悄重新开始。
一个稳健的恢复协调器可以遵循这些规则：
- 双方为每次连接生成新的会话编号，旧会话中的迟到消息直接丢弃。
- 同时发起时通过确定性的角色选择合并为一个握手，避免两条连接互相覆盖。
- 浏览器恢复在线、页面重新可见或收到对方上线通知时，唤醒已有授权关系。
- 失败后使用带抖动的退避重试，网络状态变化时立即重试，避免固定频率轰炸服务。
- 用户点击“停止重连”后持久化这一意图，后续页面刷新也不应自动恢复，直到用户主动连接。
- 连接恢复后，各功能根据自己的任务状态决定恢复、结束或询问用户，不能只看底层通道是否在线。
例如，A 正在把屏幕共享给 B，B 刷新后底层连接可以自动恢复，但屏幕共享任务应先确认远端观看会话是否仍存在。如果远端已离开，A 必须及时结束“正在共享”状态；反过来，也不能在没有明确用户动作的情况下自动重新授予屏幕捕获权限。
从用户角度检查安全与隐私
WebRTC 默认加密传输链路，但产品安全还取决于身份验证、权限和界面。选择工具时，可以沿着下面的清单逐项检查：
- 首次连接是否需要对方明确同意，已经信任的自动恢复是否避免重复骚扰。
- 设备私钥是否只保存在本地，服务端是否只持有必要的公开身份信息。
- 页面是否明确展示直连或 TURN 中继，而不是用模糊的“在线”掩盖连接路径。
- TURN 凭据是否短期有效并与用户或会话绑定，是否有限额、速率和异常使用检测。
- 文件名、聊天正文、剪贴板内容、局域网地址等敏感字段是否不会进入行为分析。
- 屏幕共享是否有持续可见的状态、明确的停止入口，并在远端离开时正确结束。
- 每项失败是否给出可操作原因，而不是只显示“连接错误”或无限重试。
用 uCopy 完成一次跨设备传输
在两台设备上打开 uCopy 连接页面。如果两台设备共享同一个公网出口，可以扫描并选择发现的设备；跨网络时，在另一台设备输入临时连接码。首次连接由对方确认，之后进入协作工作区选择聊天、P2P 剪贴板、文件传输或屏幕共享。
连接状态会区分直连和 TURN 中继。发送大文件时保持页面开启，并关注发送、接收和校验三个阶段。如果临时断网，等待可信设备自动恢复；若发送端页面已经刷新，则重新选择原文件完成摘要验证后续传。任何一方不再希望恢复连接时，应使用停止重连或解除设备信任，而不仅仅关闭一个提示框。
遇到问题时，先判断是“找不到设备”“握手失败”“通道已连接但功能不可用”还是“只在中继路径速度低”。这四类问题的排查方向不同。uCopy 的帮助与反馈页面提供了连接和传输说明；提交反馈时描述操作步骤、连接路径和发生阶段，比只提供一张“失败”截图更容易定位根因。
总结：可靠比一句“P2P”更重要
WebRTC 让浏览器具备了无需安装客户端的实时传输能力。STUN 帮助发现可直连路径，TURN 在受限网络中保证可达性，DataChannel 承载加密数据，而真正的产品体验来自上层协议：明确授权、身份验证、背压、续传、校验、取消传播和跨刷新恢复缺一不可。
对用户来说，理想工具应该在网络条件允许时快速直连，在不允许时可靠中继；该自动恢复时安静恢复，该征求许可时绝不越权；发生问题时给出真实状态。只有把这些边界都做成闭环，P2P 文件传输才不只是一个演示，而是可以日常依赖的工具。