WebRTC 诊断与点对点传输工具
检查 WebRTC 支持、ICE 候选与 STUN / TURN 服务，然后在两个浏览器之间传输文件、文件夹与文字。
选择一个工具
先诊断连接。ICE 通不了的地方，传输也不会通。
两个应当按顺序使用的工具。检测工具告诉你这个浏览器、这个网络能不能建立点对点连接；传输工具则利用这条连接，在两个浏览器之间直接搬运文件、文件夹和文字。当传输连不上时，检测工具能把「浏览器做不到」和「网络不放行」分开。
先跑检测，再做传输
WebRTC、ICE、STUN 与 TURN 检测会确认浏览器是否暴露 RTCPeerConnection 与 RTCDataChannel，收集本机可见的 ICE 候选，并逐个测试你填入的 STUN 或 TURN 服务。只有出现服务器反射候选（srflx），才算 STUN 真的应答了；单独一个 host 候选，关于 NAT 穿透什么也证明不了。
随后由浏览器点对点文件传输连接两个浏览器，把载荷通过它们之间的加密数据通道流式传输。配对可以用房间码、邀请链接或二维码；如果你根本不想经过信令信箱，也可以切到手动码，自己把 offer 和 answer 复制过去。
字节走哪条路，不走哪条路
文件和消息内容只走直连的数据通道，并由 DTLS 加密，不经过本站。房间模式下服务器只中转会话描述和 ICE 候选，在内存中最多保留十分钟，通道一建立就释放；手动码则完全绕开这个信箱。
STUN 与 TURN 的凭据留在浏览器里，只发送给你自己配置的那些服务器。请自备 TURN 而不是借用别人的：当两侧都在受限 NAT 之后时，TURN 服务器会中转整条加密流，运营它的人虽然读不到内容，却实实在在承载着你的流量。
依赖它之前该知道的限制
这是一条实时通道，不是信箱。两端必须同时在线，也没有存储转发，所以不能今天发起、明天再取。体积上限由接收端决定：选一个接收文件夹让数据直接落盘，否则就会缓冲在浏览器内存里。
一次成功的诊断，描述的是某一时刻、某个网络上的某个浏览器。屏蔽 UDP 的企业防火墙、强制门户、对称型 NAT 都会改变结果，所以请在传输将要使用的那个网络上重新跑一遍检测，而不是在你当初测试的网络上。
在采信结果之前
- 在把失败归咎于 STUN 或 TURN 之前，先确认 RTCPeerConnection 与 RTCDataChannel 确实存在。
- 只有返回了服务器反射候选才算 STUN 检测通过，只有返回了中继候选才算 TURN 检测通过。
- 一次只测一个 STUN 或 TURN 服务，并使用该服务签发的凭据，这样失败才指向具体的东西。
- 大文件传输前先选好接收文件夹，让字节直接落盘，而不是堆在浏览器内存里。
- 在传输真正要用的网络上重新跑一遍检测，并通过另一条渠道和对方核对配对码。
常见问题
我的文件会经过你们的服务器吗？
不会。文件、文件夹和文字通过 WebRTC 数据通道在两个浏览器之间直接传输，并由 DTLS 加密。房间模式下服务器只中转很短的会话建立消息，手动码连这一步也省了。
STUN 已经通了，为什么还需要 TURN？
STUN 只负责发现你的公网地址映射，在至少一侧可以穿透 NAT 时就够用了。当两侧网络都封死了直连路径时，没有中继就无法连接，而 TURN 提供的正是中继。这也是 TURN 需要凭据的原因。
对方不在线时能先把文件发出去吗？
不能。这条通道是点对点的，两个浏览器必须同时打开并保持连接。没有队列，也没有服务端副本，任何一边关闭标签页，传输就中断。
传输真的是加密的吗？
WebRTC 数据通道由 DTLS 加密，且无法关闭。但它保护的是链路而不是对端：加密只保证中间人读不到字节，所以发送敏感内容之前，请通过另一条渠道确认对面的人确实是你以为的那个人。