rtc-probe

English | 简体中文

rtc-probe 是一个基于 Go 和 Pion WebRTC 的两点间视频网络质量探测工具。它建立真实的 ICE → DTLS-SRTP → RTP 视频链路，使用 30 fps 合成 H.264 视频流分档测量双向吞吐和丢包；DataChannel 只负责测试阶段协调。

能测什么

• WebRTC 建链耗时与最终连接状态
• 测试开始时间、结束时间和总耗时
• 被选中的 ICE candidate pair（host/srflx/relay、UDP/TCP、两端地址）
• H.264 RTP/SRTP 往返探测的 RTT min/mean/max/p50/p95/p99、RTT 抖动和往返丢失率
• 空载基线、每个码率阶段及全部负载阶段汇总的视频 RTT、抖动和往返丢失率
• 视频 RTP 上行和下行在多个目标码率下的实际接收吞吐、包数、丢包率
• Pion GetStats() 接收指标和原生 RTCP RR/NACK/PLI/FIR 反馈
• 在指定丢包门限下的估算可用码率
• JSON 报告，便于接入监控或批量采集

这里的“估算可用码率”是所有测试档位中，实际接收吞吐达到目标的 90%、且 WebRTC 原生 RTP 丢包不超过门限的最高实测值；原生 stats 不可用时才回退到交付丢包率。它受配置的最高档位限制，不等同于理论带宽。

构建

要求 Go 1.24+：

go mod download
make test
make

默认构建 Linux AMD64 静态二进制。也可以明确选择架构：

make amd64  # bin/rtc-probe-linux-amd64
make arm64  # bin/rtc-probe-linux-arm64
make mac-arm64  # bin/rtc-probe-darwin-arm64（Apple Silicon）

快速开始

在被测 B 点启动服务：

./bin/rtc-probe-linux-amd64 server --listen :8080

确保 A 点能访问 B 点的 TCP 8080 信令端口，同时允许 WebRTC UDP 流量。然后在 A 点运行：

./bin/rtc-probe-linux-amd64 probe --url http://B点地址:8080/offer

默认依次按 1、2、5、10、20 Mbps 测量上下行，每档每方向 5 秒；空载基线发送 100 个视频 RTP 探测包。默认测试约需一分钟。更短的自检示例：

探测过程中，终端会以英文动态显示建链、RTT 和各码率上下行阶段的进度。进度写入标准错误流，不会污染 --json 的标准输出；自动化脚本可使用 --quiet 关闭进度。在非交互式终端中会自动切换为不含颜色和控制符的英文日志。

./bin/rtc-probe-linux-amd64 probe \
  --url http://B点地址:8080/offer \
  --rates 2,5,10 \
  --duration 2s \
  --pings 20 \
  --json > report.json

生产测试建议把最高档位设置到预期链路上限以上，并将每档时间提高到 5–10 秒：

./bin/rtc-probe-linux-amd64 probe --url http://B点地址:8080/offer \
  --rates 1,2,5,10,20,50,100 --duration 8s --loss-threshold 2

NAT、STUN 与 TURN

两端默认使用公共 STUN。公网主机通常还需要在安全组中允许 UDP 入站；严格 NAT、防火墙或只允许中继的环境应配置 TURN。两端的 ICE 配置可以不同，但一般保持一致：

# B 点
./bin/rtc-probe-linux-amd64 server --listen :8080 \
  --stun stun:stun.example.com:3478 \
  --turn turn:turn.example.com:3478 \
  --turn-user probe --turn-pass 'secret'

# A 点
./bin/rtc-probe-linux-amd64 probe --url https://probe.example.com/offer \
  --stun stun:stun.example.com:3478 \
  --turn turn:turn.example.com:3478 \
  --turn-user probe --turn-pass 'secret'

可用 --stun '' 禁用 STUN。注意 TURN 中继质量会成为测量链路的一部分，报告中的 candidate 类型会显示 relay。

指标口径与限制

• RTT 探测包使用 H.264 Single NAL RTP 格式，经客户端 SRTP 上行、服务端 RTP 回显、服务端 SRTP 下行返回。RTT、抖动和丢失率均来自真实视频 RTP transport；丢失率是往返丢失率，不能单独区分上行或下行。
• 每个上行和下行码率阶段都会并行发送 H.264 RTP 往返探测包，报告会分别输出空载基线、负载期汇总和逐阶段延迟指标，用于观察负载排队和 bufferbloat。
• 每个阶段开始和结束时分别采集原生指标，并以阶段增量输出。接收端 Pion inbound-rtp stats 提供标准 RTP 丢包和 RFC 3550 jitter；两端持续读取接收端 RTCP Sender Report 和发送端 RTCP Receiver Report、NACK、PLI、FIR，并根据有效的 LSR/DLSR 计算 RTCP RTT。短阶段内如果没有完成 SR→RR 周期，RTT sample 数可能为零。合成流没有真实解码器，PLI/FIR 通常为零。
• 视频负载和主动 RTT 探测使用同一 ICE/DTLS-SRTP transport 上的两个独立 H.264 RTP SSRC。原生 WebRTC stats 只筛选负载 SSRC，因此探测包不会增加负载接收数，也不会干扰负载流的 RFC 3550 jitter。
• Delivered Loss 对 RTP extended sequence number 去重，表示经过 NACK 恢复后仍未交付的负载包；Native Loss 是 WebRTC 原生 RTP 丢包统计。主动探测表中的方向仅表示并发负载方向，探测包始终走客户端→服务端→客户端；Final Loss 表示重传后仍未完成的往返探测比例。
• 吞吐探测通过 DTLS-SRTP 发送 30 fps、按帧突发的合成 H.264 RTP 包。协商使用 Constrained Baseline Profile 和 packetization-mode=1，载荷按 Single NAL/FU-A 封装；丢包率按发送和接收到的 RTP 包数计算，不使用 SCTP 重传。
• 抖动是相邻 RTT 样本差的平均绝对值，不是 RTP RFC 3550 的媒体包到达抖动。
• 合成 H.264 载荷用于测量视频 RTP transport，不执行真实摄像头采集、编码或解码；因此结果排除了编解码器性能影响，适合评估两点间视频传输链路，但不代表最终画面主观质量。
• 信令当前是 HTTP POST；公网部署应在前面使用 HTTPS 反向代理，并对 /offer 做鉴权和限流。

命令帮助

./bin/rtc-probe-linux-amd64 server -h
./bin/rtc-probe-linux-amd64 probe -h