# WebRTC 文件传输的工作原理

Source: https://help.strongfolder.com/zh/guides/how-webrtc-file-transfer-works/
Updated: 2026-11-05

> WebRTC 文件传输分为三个阶段。信令服务器为两个浏览器牵线；STUN 和 ICE 找到一条穿过家用路由器（NAT）的网络路径，如果没有直连路径，就退而使用 TURN 中继；随后浏览器打开 DTLS 加密的数据通道，把文件分块传输，直连或经由中继，全程不存储文件。

WebRTC 文件传输让两个浏览器无需把文件上传到云存储，就能互相发送文件。听起来很简单，但互联网本来并不是为两台家用电脑直接互联而设计的。
本指南以 StrongFolder 为例，用通俗的语言讲解实际发生了什么——信令、NAT、STUN、ICE、TURN、DTLS 和数据通道。

**Key facts**

- **WebRTC** 是一项浏览器标准，用于在两台设备之间建立直接、加密的连接；文件工具使用的是它的**数据通道**。
- **信令**为浏览器牵线；**STUN** 和 **ICE** 找到穿过路由器（**NAT**）的路径；没有直连路径时由 **TURN 中继**转发流量。
- **加密：**每条数据通道都使用 **DTLS**——WebRTC 没有不加密的模式。
- StrongFolder 在 WebRTC 之上使用 PeerJS、StrongFolder 信令服务器、公共 STUN 服务器（包括 Google 的）以及自己的 TURN 中继。文件从不上传或存储到 StrongFolder 的服务器。
- 文件被分块从发送方的硬盘传到接收方的硬盘；发送方需保持在线。

## 什么是 WebRTC？

[WebRTC](https://help.strongfolder.com/en/glossary/#webrtc)（Web 实时通信）是一组由 W3C 和 IETF 标准化的浏览器 API 和网络协议，用于浏览器之间的实时连接。
Chrome、Edge、Firefox、Safari 和 Opera 都支持它。它原本是为视频和语音通话打造的，但它还有可承载任意二进制数据的**数据通道**——而文件恰恰就是二进制数据。

关键特性在于：WebRTC 连接一旦建立，数据就在**两个端点之间**传输，而不是存入服务器。这正是
[浏览器中的 P2P 文件传输](https://help.strongfolder.com/en/guides/p2p-file-transfer/)得以实现的原因。

## 为什么两个浏览器不能直接互连？

因为几乎没有设备拥有自己的公网地址。您的笔记本电脑位于家用路由器、办公室防火墙或移动运营商网络之后。路由器执行
[NAT](https://help.strongfolder.com/en/glossary/#nat)（网络地址转换）：许多内网设备共用一个公网 IP 地址，而路由器只放行那些回应内部发出请求的流量。

因此，在任何文件数据能够流动之前，两个浏览器面临三个问题：

1. 它们不知道**如何找到对方**——谁都不知道对方的存在。
2. 它们不知道**自己的公网地址**——只知道像 192.168.1.20 这样的内网地址。
3. 它们的路由器可能会**阻止主动传入的流量**。

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 步——信令。**发送方选择文件；服务记录生成链接所需的元数据。接收方打开链接时，两个浏览器都连接到
[信令](https://help.strongfolder.com/en/glossary/#signaling)服务器。WebRTC 并没有规定信令如何实现；StrongFolder 使用 PeerJS 和自己的信令服务器。

**第 3 步——提议与应答。**一个浏览器用 SDP（会话描述协议）创建一个**提议**（offer）：“我想要一条数据通道，这是我的加密指纹和能力。”
另一个浏览器回复一个**应答**（answer）。两者都经由信令服务器传递。

**第 4 步——STUN。**每个浏览器询问 [STUN](https://help.strongfolder.com/en/glossary/#stun) 服务器：“你看到我是从哪个地址和端口来的？”
得到的答案就是路由器映射后的公网地址。STUN 服务器只处理一个极小的请求，不处理任何文件数据；StrongFolder 使用公共 STUN 服务器（包括 Google 的）以及自己的服务器。

**第 5 步——ICE 候选地址。**每个浏览器收集**候选地址**——别人可能联系到它的各种方式：本地网络地址（host）、通过 STUN 得到的公网地址（server-reflexive）
以及 TURN 中继上的地址（relayed）。它们通过信令交换候选地址。

**第 6 步——连通性检查。**[ICE](https://help.strongfolder.com/en/glossary/#ice)（交互式连接建立）测试候选地址对，选出可用的最佳一对。如果两台设备在同一 Wi-Fi 下，本地路径胜出。
如果路由器允许，直接的互联网路径（“打洞”）胜出。如果所有直连方式都不可用，就使用中继路径。

**第 7 步——DTLS。**在任何数据流动之前，浏览器先进行 [DTLS](https://help.strongfolder.com/en/glossary/#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 |

[术语表](https://help.strongfolder.com/en/glossary/)中对这些术语都有简要解释。

## 什么时候会使用 TURN 中继？它能看到什么？

中继是备用方案，而不是默认方案。只有当没有任何直连候选地址对能连通时，ICE 才会使用它——通常出现在采用**对称 NAT** 的网络（部分移动运营商）、
阻止出站 UDP 的**企业防火墙**或某些 VPN 中。

如果无法建立直连（严格的企业防火墙、部分移动网络），加密的数据流会经过 StrongFolder 的中继（TURN）服务器。中继只转发数据，不会存储数据。

中继接收经 DTLS 加密的数据包并将其转发。它能看到有流量在传输、数据量多少以及时间——看不到里面的内容。经中继的传输可能比直连慢，
因为每个字节都要多绕一趟中继。如果传输异常缓慢，请换一个网络试试：在办公网络无法直连的地方，手机热点或家庭 Wi-Fi 往往可以。

[立即发送文件](https://strongfolder.com)
## WebRTC 加密有多安全？

WebRTC 强制加密：无法打开未加密的数据通道。DTLS 使用由两个浏览器协商的现代加密算法，并且每次连接都会生成新的密钥。

有一个坦诚的提醒，适用于所有 WebRTC 服务。两个浏览器通过证书**指纹**互相验证，而指纹是经由信令服务器交换的。
因此，您需要信任该服务的信令不会篡改它们。这就是为什么 StrongFolder 把它的保护描述为**传输加密**——而不是由您持有密钥的端到端加密，
也不是“零知识”。想更全面地了解“安全”意味着什么，请阅读[安全的文件分享](https://help.strongfolder.com/en/guides/secure-file-sharing/)和[安全与隐私](https://help.strongfolder.com/en/security/)。

## 为什么发送方的浏览器必须保持打开？

因为发送方的浏览器*就是*数据源。没有服务器副本可以兜底：只有在标签页打开且设备处于唤醒状态时，数据通道才能从发送方的硬盘读取数据块。
在接收方下载完成之前，发送方的浏览器标签页必须保持打开并在线——文件来自发送方的设备，而不是服务器。 如何为此做好安排，请参阅[为什么发送方必须保持在线](https://help.strongfolder.com/en/guides/why-sender-stays-online/)。

## WebRTC 文件传输有多快？

没有固定的速度。上限取决于路径上最慢的一环：通常是发送方的**上行**速度。粗略估算，1 GB 在 50 Mbit/s 下约需 2.7 分钟，
在 100 Mbit/s 下约 80 秒，在快速局域网中远不到一分钟。由于协议开销、硬盘速度以及（使用中继时）多出的一跳，实际传输会比这些数字稍慢。
一个链接可以被多位接收方打开；每个人都直接从发送方下载。 多个同时进行的下载会共享发送方的上行带宽。

## 总结

一次 WebRTC 文件传输就是一段简短的协商，加上一段长时间的加密数据流：信令为浏览器牵线，STUN 和 ICE 找到穿过 NAT 的路径，TURN 作为最后手段进行中继，
而 DTLS 加密的数据通道则把文件从一块硬盘送到另一块硬盘。至于实际层面——这对作为发送方的您意味着什么——请从
[浏览器中的 P2P 文件传输](https://help.strongfolder.com/en/guides/p2p-file-transfer/)和 [StrongFolder 的工作原理](https://help.strongfolder.com/en/how-it-works/)开始阅读。

## FAQ

### 什么是 WebRTC 数据通道？

数据通道是 WebRTC 中在两个浏览器之间传输任意字节（而不是音频或视频）的部分。它基于 UDP 之上的 DTLS 再运行 SCTP，因此是加密的，并且可以配置为可靠、有序——这正是文件传输所需要的。

### STUN 和 TURN 有什么区别？

STUN 服务器只告诉浏览器它的公网地址是什么样的，以便两个浏览器尝试直连；任何文件数据都不经过它。TURN 服务器是中继：当没有可用的直连路径时，加密的数据流会经过它。StrongFolder 运行自己的 TURN 中继，只转发数据，不存储数据。

### 信令服务器能看到我的文件吗？

不能。信令服务器只在浏览器之间传递连接消息——会话描述和网络候选地址。文件数据通过数据通道传输，要么直连，要么经由 TURN 中继。

### WebRTC 文件传输是加密的吗？

WebRTC 使用 DTLS 加密每一条数据通道，因此在每一次连接中，文件数据流在传输过程中都是加密的。 WebRTC 不允许未加密的数据通道。密钥由两个浏览器协商；它们的指纹通过信令传递，因此这属于传输加密，而不是由您自己管理密钥的端到端加密。

### 为什么 WebRTC 传输有时会失败或一直很慢？

通常是网络路径的问题：严格的防火墙或 VPN 阻断了直接的 UDP，于是连接退回到基于 TCP 的 TURN 中继，或者根本无法连接。请换一个网络（例如手机热点）、关闭 VPN，或请 IT 部门放行 WebRTC。

### TURN 中继能读取我的文件吗？

中继在两个浏览器之间转发经 DTLS 加密的数据包。它能看到加密流量、数据量和时间，看不到文件内容，而且 StrongFolder 的中继不会存储它转发的内容。