1、WebRTC 调试基础：认识 Chrome 的 webrtc-internals 工具
做 WebRTC 开发，最怕什么？
不是写不出代码，而是出了问题不知道去哪看。视频卡了、音频断了、连接失败了——你总不能靠猜吧？
我个人习惯，第一件事就是打开 Chrome 自带的 webrtc-internals。这玩意儿，说白了就是 WebRTC 的「黑匣子」。所有底层细节，都记在里面。
1.1 怎么打开？
很简单。在 Chrome 地址栏输入：
chrome://webrtc-internals回车，就能看到一个空白的调试面板。这时候还没数据，因为你还没建立任何 WebRTC 连接。
等你的页面开始通话或推流，面板会自动刷新，所有实时数据就涌进来了。
1.2 界面布局长什么样？
打开之后，你会看到几个主要区域。别慌，咱们一个一个说。
- 顶部状态栏：显示当前页面 URL、连接状态、是否正在采集音视频。
- 左侧统计列表：按时间顺序列出所有 PeerConnection 实例。每个实例都有一个唯一的 ID。
- 右侧详情面板：点击左侧某个连接，右侧会展示该连接的所有统计数据。
- 底部日志区：记录 ICE 状态变化、SDP 协商过程等关键事件。
嗯，这里要注意：如果你同时打开了多个页面，左侧列表会堆很多条目。记得先确认你选的是哪个连接。
1.3 关键指标解读
这才是重点。数据那么多，到底看哪些？
1.3.1 连接状态（Connection State）
这个指标告诉你连接是否正常。常见状态有：
| 状态 | 含义 | 常见原因 |
|---|---|---|
| new | 刚创建，还没开始连接 | 正常初始状态 |
| connecting | 正在尝试建立连接 | ICE 协商中 |
| connected | 连接成功建立 | 正常 |
| disconnected | 连接断开，但可能重连 | 网络波动、对方离开 |
| failed | 连接彻底失败 | STUN/TURN 配置错误、防火墙拦截 |
| closed | 连接已关闭 | 主动调用 close() |
我在项目中遇到过好几次，状态一直在 connecting 和 disconnected 之间来回跳。后来发现是 TURN 服务器地址写错了。你想想看，这种问题不看 internals，光靠猜得猜到什么时候？
1.3.2 ICE 候选者（ICE Candidates）
ICE 是 WebRTC 的「探路者」。它负责找到一条能通的路。
在 internals 里，你会看到类似这样的信息：
candidate: 1 1 UDP 2122252543 192.168.1.100 54321 typ host
candidate: 1 1 UDP 1686052607 10.0.0.5 54322 typ srflx raddr 0.0.0.0 rport 0
candidate: 1 1 TCP 1010822143 203.0.113.50 3478 typ relay raddr 10.0.0.5 rport 54322关键看 typ 字段：
- host：本地内网地址，速度最快
- srflx：公网映射地址，NAT 穿透成功
- relay：通过 TURN 中继，速度最慢但最可靠
如果列表里只有 host 类型，说明你的用户可能都在同一个局域网。如果只有 relay，那就要检查 STUN 服务器是不是挂了。
1.3.3 收发统计（Inbound / Outbound RTP Stats）
这里能看到音视频流的真实传输情况。我最常看这几个：
- bytesReceived / bytesSent：收发的数据量。如果一直不增长，说明流断了。
- packetsLost：丢包数。这个值持续增加，说明网络质量差。
- jitter：抖动值。单位是毫秒。抖动越大，音视频越卡。
- framesPerSecond：帧率。视频通话一般 15-30 fps 算正常。
举个例子：
Inbound Video:
bytesReceived: 12345678
packetsLost: 0
jitter: 0.02
framesPerSecond: 30这个数据说明接收端网络很好，没有丢包，帧率稳定。
再看另一个：
Inbound Video:
bytesReceived: 9876543
packetsLost: 150
jitter: 0.45
framesPerSecond: 12丢包 150，抖动 0.45 秒，帧率掉到 12。嗯，用户肯定在骂娘了。
1.3.4 往返时间（RTT）
RTT 就是数据从发送到收到确认的时间。单位是毫秒。
在 candidate-pair 里可以看到。一般来说：
- RTT < 50ms：网络非常好
- RTT 50-150ms：正常范围
- RTT > 300ms：明显卡顿，需要优化
我个人的经验是，如果 RTT 超过 500ms，基本就没法正常通话了。这时候要么换网络，要么降码率。
1.4 一张图看懂 webrtc-internals
下面这张图，帮你把整个工具的逻辑串起来：
1.5 实战小技巧
最后分享几个我常用的调试习惯：
- 先看连接状态：如果状态不是
connected，后面都不用看了。 - 再看 ICE 候选者：确认有没有 relay 类型。如果没有，说明 TURN 可能没配置。
- 然后看丢包和抖动：这两个指标直接决定用户体验。
- 最后看 RTT：如果 RTT 高，考虑降码率或换线路。
好了，这一章就到这里。工具认识了，指标也懂了。下一章咱们聊聊怎么用这些数据，去解决实际开发中遇到的坑。