答案：构建WebRTC点对点通信需实现信令交换、RTCPeerConnection连接与NAT穿透。首先通过WebSocket服务器中转SDP和ICE候选完成信令，再创建RTCPeerConnection并交换offer/answer，最后借助STUN/TURN解决NAT穿透，确保连接稳定。
要构建一个基于WebRTC的点对点实时通信应用，核心是建立浏览器之间的直接连接，实现音视频或数据的实时传输。关键在于理解信令机制、连接协商和网络穿透过程。下面从几个关键步骤展开说明。
1. 理解WebRTC的基本组件
WebRTC本身不负责发现对方或交换连接信息，这些需要开发者自行实现。主要依赖以下三个接口：
- RTCPeerConnection：用于建立点对点连接，传输音视频流或数据。
- RTCDataChannel：可在连接中传输任意数据，如文本、文件等。
- MediaDevices.getUserMedia：获取本地摄像头和麦克风的媒体流。
这些API在现代浏览器中已原生支持，无需插件。
2. 实现信令服务器
虽然WebRTC是点对点通信，但初始阶段需要一个中间服务器来交换“连接信息”，这个过程称为信令。信令服务器的作用是传递以下内容：
你可以使用WebSocket搭建一个简单的信令服务。例如，两个用户A和B通过WebSocket连接到服务器，A发起呼叫时发送offer，服务器转发给B；B收到后回复answer，再由服务器传回A。整个过程只是“消息中转”，不涉及媒体流传输。
3. 建立RTCPeerConnection连接
连接建立流程如下：
- 创建RTCPeerConnection实例，并添加本地媒体流或数据通道。
- 调用createOffer()生成offer，设置为本地描述，然后通过信令发送给对方。
- 对方收到offer后，调用setRemoteDescription()保存，并调用createAnswer()生成answer，返回给发起方。
- 双方通过onicecandidate事件收集ICE候选，并通过信令交换。
当双方都设置了远程描述并交换完ICE候选后，连接自动建立。
4. 处理NAT穿透和STUN/TURN服务器
大多数设备位于路由器后，无法直接访问公网IP。WebRTC依赖STUN和TURN服务器解决这个问题：
- STUN服务器：帮助客户端发现自己的公网地址和端口，适用于多数情况。
- TURN服务器：当P2P直连失败时，作为中继转发媒体流，保证连接可达。
你可以使用Google提供的免费STUN服务器（如stun:stun.l.google.com:19302），生产环境建议部署自己的coturn服务器。
基本上就这些。只要信令通了，连接建立起来，剩下的交给WebRTC处理。难点通常在信令逻辑设计和网络环境适配上，而不是API本身。多测试不同网络场景，确保TURN兜底可用，体验才稳定。
