无服务端的化学反应：xSend 浏览器端 P2P 直连技术揭秘

在当今的云时代，绝大多数网盘和文件传输工具的做法非常粗暴：A 把文件传到服务器，B 再从服务器下载。这种设计的缺陷显而易见：速度受限、隐私缺乏保障、以及高昂的服务器带宽成本。

xSend 的核心理念是：网络条件允许时，直接点对点（P2P）连接设备。

在桌面客户端中，我们拥有操作系统的最高权限，可以通过原生的 TCP 或 QUIC 协议直接建立高速通道。但是，如果我们只使用纯浏览器（不安装任何应用），能否实现同样的效果呢？

答案是肯定的。这篇技术博客将带你深入了解，xSend 是如何通过 WebRTC 打破浏览器沙盒，让两台素昧平生的设备直接“握手”的。

1. 茫茫人海中找到你：信令服务器 (Signaling)

浏览器出于安全考虑，无法像原生程序那样在局域网内广播 UDP 包（mDNS 或 SSO）去寻找附近的设备。

因此，我们需要一个超级轻量级的“红娘”——信令服务器 (Signaling Server)。

在 xSend 的架构中，这个重任交给了 Cloudflare Worker 上的 SignalAutoDO 节点。当你在两台设备的浏览器里输入相同的 6 位提取码（或扫描 QR 码）时：

双方浏览器同时通过 WebSocket 连接到同一个 Cloudflare 节点。
节点将你们分配到同一个虚拟“房间”。
双方开始交换 SDP（Session Description Protocol，描述我支持什么编码格式）和 ICE 候选者（Interactive Connectivity Establishment，包含我的内网 IP 和外网 IP 列表）。

隐私保护声明：信令服务器只负责交换上述用来建连的元数据，绝不接触文件本身的任何内容。

拿到对方的 IP 列表后，浏览器开始尝试真正的底层连接。由于 IPv4 的匮乏，我们通常都躲在路由器的 NAT（网络地址转换）后面。

如果你们连在同一个 Wi-Fi（局域网）下，交换的 ICE 候选者中会包含类似 192.168.1.10 的内网 IP。浏览器的底层引擎会优先尝试通过这些内网 IP 直接通信。一旦连通，后续的所有流量绝不离开你的路由器，安全且极速。

如果两台设备不在同一个 Wi-Fi，比如一台在家里，一台连着 5G 蜂窝网络：

浏览器会向 xSend 部署的 STUN 服务器 发送请求，问：“我在公网长什么样？”
STUN 服务器返回你路由器的公网 IP 和映射端口。
随后，两边各自向对方路由器的公网端口强行发送 UDP 数据包。如果路由器的策略不是严格的对称 NAT，这几个数据包一旦“交汇”，打洞 (Hole Punching) 就成功了！真正的广域网 P2P 隧道就此建立。

连接一旦打通，数据该如何传输？

WebRTC 为音视频设计，默认走不可靠的 UDP。但是为了保证文件传输的完整性，xSend 启用了 WebRTC 的核心组件：RTCDataChannel。

这是一种运行在 UDP 上的特殊传输层（SCTP），它能像 TCP 一样保证数据的有序、可靠到达。

更重要的是，RTCDataChannel 原生自带 DTLS (Datagram Transport Layer Security)。这意味着你在浏览器端传输的每一字节文件，都是经过极高强度的非对称协商和对称算法加密的。哪怕流量在中途被黑客截获，看到的也只是一堆乱码。

在极端糟糕的网络环境下（比如严苛的企业内网、复杂的对称 NAT），打洞注定会失败。此时，传输就会转入次优方案——TURN (Traversal Using Relays around NAT)。

浏览器自动退后一步，通过 Cloudflare 分布在全球边缘节点的 TURN 服务器中转流量。
不要担心隐私问题，由于底层的 DTLS 端到端加密机制依然生效，哪怕是 Cloudflare 充当中转站，也绝对无法解密正在传输的文件内容（Cloudflare 只能看到一坨加密的二进制流路过）。

我们在最新一版的架构中，用极简的二进制帧协议 (Binary Chunk Framing) 彻底重写了传输管道，削减了早期 Base64 方案近 33% 协议开销，让每一次极速穿梭畅通无阻。

坦率地说，纯浏览器的 P2P 传输并不是没有代价。JavaScript 的内存拷贝、Blob 与 ArrayBuffer 的转换开销、以及复杂协议在沙盒内的运行损耗，往往会让千兆局域网的极限吞吐量卡在 30-50MB/s 之间。这对于单核 CPU 的压力远超桌面端程序。

不过，xSend 的桌面客户端完全克服了这一点。如果你有转移上百 GB 文件的极致性能需求，请随时下载原生版本——它会直接绕过沙箱，直接和网卡面对面交谈。