26、WebRTC调试工具：chrome://webrtc-internals使用、Wireshark抓包分析RTP/RTCP、日志分析与问题定位

做WebRTC开发，最怕什么？

不是写不出代码，而是出了问题不知道去哪找线索。视频卡了、音频断了、连接失败了——这些现象背后，到底是谁的锅？

我个人习惯，先打开三个东西：chrome://webrtc-internals、Wireshark、还有WebRTC内部日志。这三板斧下去，90%的问题都能定位到根因。

一、chrome://webrtc-internals：实时状态监控

这个工具，说白了就是WebRTC的“仪表盘”。你打开Chrome，地址栏输入chrome://webrtc-internals，就能看到当前所有PeerConnection的实时数据。

核心看板：

  • Stats Graphs：实时曲线图，看比特率、丢包率、延迟
  • SSRC信息：每个音视频流的同步源标识
  • ICE候选对：当前使用的传输路径
  • RTCInboundRtpStreamStats：接收端统计
  • RTCOutboundRtpStreamStats：发送端统计

我记得有一次线上反馈视频模糊，我第一反应是编码参数问题。打开webrtc-internals一看，framesPerSecond只有12，qpSum高得离谱——原来是CPU过载导致编码器降级了。嗯，这里要注意：不要只看表象，要看统计字段的趋势。

二、Wireshark抓包分析RTP/RTCP

浏览器工具能看到应用层数据，但网络层的问题，还得靠Wireshark。

我曾经遇到一个诡异问题：视频偶尔黑屏，但音频正常。用Wireshark抓包后发现，RTP包的序列号有大量跳变，而且RTCP的fractionLost在某个时间点突然飙升到0.8。说白了，就是网络中间设备在丢包。

抓包过滤技巧：

# 只抓RTP/RTCP包（假设端口范围是10000-20000）
udp.port >= 10000 && udp.port <= 20000

# 或者按SSRC过滤
rtp.ssrc == 0x12345678

# 查看RTCP的丢包率
rtcp.fraction

Wireshark里我最常用的几个分析点：

  • RTP序列号连续性：跳变说明丢包或乱序
  • RTCP的jitter值：超过50ms就要警惕
  • NACK请求频率：每秒超过10次说明网络很差
  • SR（Sender Report）时间戳：检查时钟同步问题

注意：Wireshark默认不解析RTP，需要先启用RTP解析器。在「编辑 → 首选项 → Protocols → RTP」里勾上「Try to decode RTP」。不然你看到的全是乱码。

三、日志分析与问题定位

WebRTC的日志分三级：

  • INFO：常规流程，比如连接建立、ICE状态变化
  • WARNING：异常但不致命，比如丢包率过高
  • ERROR：致命错误，比如连接超时、编码失败

开启日志的方法很简单：

// 在Chrome启动时加参数
chrome --enable-logging --v=1 --vmodule="*/webrtc/*=2"

// 或者运行时设置
chrome://webrtc-logs

我个人习惯，先搜[ERROR]，再看[WARNING]。如果ERROR很多，基本就是配置或网络问题。如果只有WARNING，那可能是偶发抖动。

举个例子，我曾经遇到一个bug：视频通话10分钟后必断。日志里反复出现：

[ERROR:webrtc_session.cc:123] ICE restart timeout

查了半天，发现是NAT设备把UDP会话超时设成了5分钟。解决方案？要么改NAT配置，要么在应用层加心跳保活。

四、知识体系总览

下面这张图，是我自己总结的调试流程。你按这个顺序排查，基本不会漏。

WebRTC调试三板斧 问题现象 chrome://webrtc-internals Wireshark抓包 WebRTC日志 看什么？ 比特率、丢包率、帧率 ICE状态、SSRC统计 看什么？ RTP序列号、时间戳 RTCP丢包率、jitter 看什么？ ERROR/WARNING级别 ICE restart、编码失败 定位根因 → 修复

五、实战：一个完整的排查案例

假设用户反馈：视频通话卡顿，画面马赛克严重。

第一步：打开webrtc-internals

我看到packetsLost在持续增长，googFrameRateReceived从30掉到了8。嗯，网络丢包导致帧率下降。

第二步：Wireshark抓包确认

过滤出该流的RTP包，发现序列号有连续3个包丢失，RTCP的fractionLost显示0.15（15%丢包）。

第三步：看日志

日志里出现[WARNING:video_receive_stream.cc:456] High packet loss on video stream。确认是网络问题。

解决方案：开启FEC（前向纠错）和NACK（重传请求）。配置如下：

// 在SDP中启用FEC
a=rtpmap:126 red/90000
a=rtpmap:127 ulpfec/90000
a=fmtp:126 127/126

// 或者通过API设置
const rtpParameters = sender.getParameters();
rtpParameters.encodings[0].fec = {
  mechanism: 'red+ulpfec',
  redundancy: 0.2
};
sender.setParameters(rtpParameters);

我的经验：丢包率在5%以下，NACK就够了。超过10%，必须上FEC。超过20%？建议先修网络，别指望应用层能扛。

六、避坑指南

我曾经踩过几个坑，分享给你：

  • 坑1：webrtc-internals的数据是实时刷新的，但页面刷新后数据就没了。记得在出问题前先打开这个页面，或者用chrome://webrtc-internals/?tab=0&preserve=true保留数据。
  • 坑2：Wireshark抓RTP包时，如果端口不固定，可以用rtp作为过滤条件。但注意，Wireshark只解析标准RTP，如果用了自定义扩展头，可能解析失败。
  • 坑3：日志级别不要开太高（比如--v=3），否则日志文件会暴涨，反而掩盖关键信息。我一般用--v=1，然后针对特定模块开--vmodule。

调试WebRTC，说白了就是“看数据说话”。工具给你了，剩下的就是经验积累。多抓几次包，多翻几次日志，你慢慢就能一眼看出问题在哪。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →