WebRTC 文件传输让两个浏览器无需把文件上传到云存储，就能互相发送文件。听起来很简单，但互联网本来并不是为两台家用电脑直接互联而设计的。 本指南以 StrongFolder 为例，用通俗的语言讲解实际发生了什么——信令、NAT、STUN、ICE、TURN、DTLS 和数据通道。
什么是 WebRTC？
WebRTC（Web 实时通信）是一组由 W3C 和 IETF 标准化的浏览器 API 和网络协议，用于浏览器之间的实时连接。 Chrome、Edge、Firefox、Safari 和 Opera 都支持它。它原本是为视频和语音通话打造的，但它还有可承载任意二进制数据的数据通道——而文件恰恰就是二进制数据。
关键特性在于：WebRTC 连接一旦建立，数据就在两个端点之间传输，而不是存入服务器。这正是 浏览器中的 P2P 文件传输得以实现的原因。
为什么两个浏览器不能直接互连？
因为几乎没有设备拥有自己的公网地址。您的笔记本电脑位于家用路由器、办公室防火墙或移动运营商网络之后。路由器执行 NAT（网络地址转换）：许多内网设备共用一个公网 IP 地址，而路由器只放行那些回应内部发出请求的流量。
因此，在任何文件数据能够流动之前，两个浏览器面临三个问题：
- 它们不知道如何找到对方——谁都不知道对方的存在。
- 它们不知道自己的公网地址——只知道像 192.168.1.20 这样的内网地址。
- 它们的路由器可能会阻止主动传入的流量。
WebRTC 用不同的机制分别解决这些问题。
WebRTC 文件传输是如何一步步进行的？
以下是从点击“分享”到最后一个字节的完整流程：
Sender browser Servers Recipient browser
────────────── ─────── ─────────────────
1. Choose files ──── metadata ──▶ Signaling server
◀──────── 2. Open link ────────
3. Offer (SDP) ─────────────────▶ Signaling ──────────────────▶ Answer (SDP)
4. Ask STUN "how do I look?" ─▶ STUN servers ◀─ Ask STUN "how do I look?"
5. ICE candidates ◀─────────────▶ Signaling ◀──────────────────▶ ICE candidates
6. ICE checks: try LAN → direct internet → TURN relay
7. DTLS handshake ◀════════════ encrypted ═════════════════▶ DTLS handshake
8. Data channel: file chunks ═══(direct or via TURN relay)══▶ written to disk
**第 1–2 步——信令。**发送方选择文件；服务记录生成链接所需的元数据。接收方打开链接时，两个浏览器都连接到 信令服务器。WebRTC 并没有规定信令如何实现；StrongFolder 使用 PeerJS 和自己的信令服务器。
第 3 步——提议与应答。一个浏览器用 SDP（会话描述协议）创建一个提议（offer）：“我想要一条数据通道，这是我的加密指纹和能力。” 另一个浏览器回复一个应答（answer）。两者都经由信令服务器传递。
**第 4 步——STUN。**每个浏览器询问 STUN 服务器：“你看到我是从哪个地址和端口来的？” 得到的答案就是路由器映射后的公网地址。STUN 服务器只处理一个极小的请求，不处理任何文件数据；StrongFolder 使用公共 STUN 服务器（包括 Google 的）以及自己的服务器。
第 5 步——ICE 候选地址。每个浏览器收集候选地址——别人可能联系到它的各种方式：本地网络地址（host）、通过 STUN 得到的公网地址（server-reflexive） 以及 TURN 中继上的地址（relayed）。它们通过信令交换候选地址。
第 6 步——连通性检查。ICE（交互式连接建立）测试候选地址对，选出可用的最佳一对。如果两台设备在同一 Wi-Fi 下，本地路径胜出。 如果路由器允许，直接的互联网路径（“打洞”）胜出。如果所有直连方式都不可用，就使用中继路径。
**第 7 步——DTLS。**在任何数据流动之前，浏览器先进行 DTLS 握手（适用于 UDP 的 TLS），并检查证书指纹是否与提议和应答中的一致。 从此一切都是加密的。
**第 8 步——数据通道。**DTLS 之上运行 SCTP，为数据通道提供可靠、有序的传输。在 StrongFolder 中，接收方的浏览器请求一个文件，发送方的浏览器从硬盘分块读取并发送， 接收方在每个数据块到达时把它写入硬盘——因此即使是非常大的文件，也无需全部装进内存。
STUN、TURN、ICE 等术语分别是什么意思？
| 术语 | 作用 | 能看到文件数据吗？ | 标准 |
|---|---|---|---|
| 信令 | 在浏览器之间传递提议、应答和候选地址 | 否 | 未标准化（由应用自定） |
| NAT | 让多台设备共用一个公网 IP 的路由器功能 | — | — |
| STUN | 告诉浏览器它的公网地址和端口 | 否 | IETF RFC 8489 |
| ICE | 收集候选地址并选出可用路径 | 否 | IETF RFC 8445 |
| TURN | 在没有可用直连路径时中继流量 | 只能看到加密数据包 | IETF RFC 8656 |
| DTLS | 加密连接（用于 UDP 的 TLS） | 对其加密 | IETF RFC 9147（1.3）、RFC 6347（1.2） |
| SCTP 数据通道 | 可靠、有序地传输数据块 | 承载它（已加密） | IETF RFC 8831 |
术语表中对这些术语都有简要解释。
什么时候会使用 TURN 中继？它能看到什么？
中继是备用方案，而不是默认方案。只有当没有任何直连候选地址对能连通时，ICE 才会使用它——通常出现在采用对称 NAT 的网络（部分移动运营商）、 阻止出站 UDP 的企业防火墙或某些 VPN 中。
如果无法建立直连（严格的企业防火墙、部分移动网络），加密的数据流会经过 StrongFolder 的中继（TURN）服务器。中继只转发数据，不会存储数据。
中继接收经 DTLS 加密的数据包并将其转发。它能看到有流量在传输、数据量多少以及时间——看不到里面的内容。经中继的传输可能比直连慢， 因为每个字节都要多绕一趟中继。如果传输异常缓慢，请换一个网络试试：在办公网络无法直连的地方，手机热点或家庭 Wi-Fi 往往可以。
免费 · 在浏览器中使用 · 无需注册
WebRTC 加密有多安全？
WebRTC 强制加密：无法打开未加密的数据通道。DTLS 使用由两个浏览器协商的现代加密算法，并且每次连接都会生成新的密钥。
有一个坦诚的提醒，适用于所有 WebRTC 服务。两个浏览器通过证书指纹互相验证，而指纹是经由信令服务器交换的。 因此，您需要信任该服务的信令不会篡改它们。这就是为什么 StrongFolder 把它的保护描述为传输加密——而不是由您持有密钥的端到端加密， 也不是“零知识”。想更全面地了解“安全”意味着什么，请阅读安全的文件分享和安全与隐私。
为什么发送方的浏览器必须保持打开？
因为发送方的浏览器就是数据源。没有服务器副本可以兜底：只有在标签页打开且设备处于唤醒状态时，数据通道才能从发送方的硬盘读取数据块。 在接收方下载完成之前，发送方的浏览器标签页必须保持打开并在线——文件来自发送方的设备，而不是服务器。 如何为此做好安排，请参阅为什么发送方必须保持在线。
WebRTC 文件传输有多快？
没有固定的速度。上限取决于路径上最慢的一环：通常是发送方的上行速度。粗略估算，1 GB 在 50 Mbit/s 下约需 2.7 分钟， 在 100 Mbit/s 下约 80 秒，在快速局域网中远不到一分钟。由于协议开销、硬盘速度以及（使用中继时）多出的一跳，实际传输会比这些数字稍慢。 一个链接可以被多位接收方打开；每个人都直接从发送方下载。 多个同时进行的下载会共享发送方的上行带宽。
总结
一次 WebRTC 文件传输就是一段简短的协商，加上一段长时间的加密数据流：信令为浏览器牵线，STUN 和 ICE 找到穿过 NAT 的路径，TURN 作为最后手段进行中继， 而 DTLS 加密的数据通道则把文件从一块硬盘送到另一块硬盘。至于实际层面——这对作为发送方的您意味着什么——请从 浏览器中的 P2P 文件传输和 StrongFolder 的工作原理开始阅读。