SRS WebRTC黑屏排查实战：从日志分析到源码调试的深度解构

去年冬天接手公司内部直播系统升级项目时，我遇到了职业生涯中最顽固的WebRTC黑屏问题。整整三周时间，每天盯着SRS日志里那些看似毫无规律的DTLS状态码和source_id变化，就像在破译摩尔斯电码。这段经历让我深刻体会到——真正的技术排障不是对照检查清单打勾，而是培养从噪声中识别信号的能力。

1. 建立系统化的排障思维框架

遇到黑屏问题时，大多数工程师的第一反应是疯狂Google解决方案。但真正有效的排障需要建立系统化的分析框架。我把WebRTC播放链路分解为五个关键阶段：

网络层 → 信令层 → 媒体协商 → 传输层 → 渲染层

每个阶段都有独特的故障特征。例如网络层问题通常伴随ICE协商失败，而渲染层问题可能表现为收到数据包但无法解码。通过分段隔离法，可以快速缩小排查范围。

1.1 从日志中提取关键信号

SRS的日志输出看似杂乱，实则包含黄金信息。这是我总结的关键日志模式匹配表：

日志特征	可能的问题领域	典型解决方案
"waiting DTLS handshake"	UDP端口不通/防火墙拦截	检查UDP 8000端口可达性
"Use candidates"缺失	ICE候选地址配置错误	验证candidate参数
"source_id=/"	流映射失败	检查推拉流URL一致性
"RTC bridge from RTMP"	转码配置未启用	确认rtmp_to_rtc开关状态

1.2 网络拓扑的可视化分析

在内网测试正常但公网部署失败的情况下，我绘制了网络流量路径图：

[推流端] → (NAT) → [公网SRS] ← (防火墙) ← [播放端]

这个简单的拓扑图帮助我意识到：两端可能处于不同的NAT类型下，需要特殊处理STUN/TURN服务器配置。通过Wireshark抓包发现，某些企业网络会过滤UDP大包，导致DTLS握手失败。

2. 深入传输层：DTLS握手的艺术

WebRTC的安全基石是DTLS-SRTP，而90%的黑屏问题都发生在这个环节。通过修改SRS日志级别，我捕获到完整的握手过程：

[DTLS] State Passive RECV, done=0, arq=0/0 (ClientHello)
[DTLS] State Passive SEND, done=0, arq=0/0 (ServerHello)
[DTLS] State Passive RECV, done=0, arq=0/0 (Certificate)
...

当发现握手停滞在某阶段时，可以精确锁定问题。例如卡在ClientHello通常表示UDP不通，而反复重传Certificate则可能暗示MTU问题。

2.1 实战MTU问题排查

在某次公有云部署中，抓包显示DTLS握手总是中断在512字节附近。通过以下命令确认MTU限制：

ping -M do -s 1472 -c 1 example.com  # 测试路径MTU
ifconfig | grep mtu                  # 检查本地MTU设置

最终解决方案是在SRS启动脚本中添加：

sysctl -w net.inet.udp.maxdgram=1200

3. 源码级调试：当日志不够用时

当所有常规手段用尽后，我不得不深入SRS源码。关键突破点是发现source_id的生成逻辑位于rtc_source.cpp：

// 流URL映射的核心逻辑
std::string source_id = generate_source_id(stream_url);
if (source_map_.find(source_id) == source_map_.end()) {
    LOG_WARN("No source found for %s", source_id.c_str());
    return nullptr;
}

这段代码解释了为什么带域名的推流会导致播放失败——URL规范化处理时保留了域名信息。通过修改推流客户端，统一使用IP地址格式，问题最终解决。

4. 环境差异下的特殊案例

不同部署环境会引入意想不到的问题。在某次金融行业部署中，我们遇到了这样的特殊场景：

• 现象：内网正常，VPN接入后黑屏
• 根因：企业防火墙对UDP包实施QoS限速
• 解决方案：
  1. 调整SRS的timeout和arq参数
  2. 启用TCP候选地址作为fallback
  3. 添加带宽探测和自适应码率逻辑

这个案例教会我：生产环境的问题往往需要综合解决方案，而非简单的配置调整。真正的技术价值不在于记住多少参数，而在于构建系统化的排障思维。每次解决黑屏问题，都是对WebRTC协议栈理解的一次深化。