在受限的网络环境中测试WebRTC客户端

评估视频会议和直播服务的音频/视频质量是一个重要的话题，因为它可以对用户体验产生重大影响。低质量的音频或视频可能会导致挫败感，难以理解他人，并降低参与度。另一方面，高质量的音频和视频可以加强沟通，并为用户创造一个更加身临其境和参与的体验。

有几个因素可以影响这些服务的音频和视频质量，包括互联网带宽、网络延迟、设备硬件和软件，以及用于会议或流媒体的平台或软件。评估这些因素并确定优化它们的方法有助于提高服务质量。

测试和测量

通过这篇文章，我们将看到如何使用 webrtcperf 工具对一些流行的视频会议服务进行测试和测量。利用该工具的配置选项，可以运行多个WebRTC客户端，应用一些网络限制（带宽、延迟、丢包），并测量工具输出所提供的一些性能指标（发送/接收比特率、丢包、视频分辨率、抖动等）。

前提条件

安装了 Docker 的 Linux 机器；
良好的互联网连接以避免影响测试结果；
与我们要运行的客户端数量成正比的 CPU/内存量。

测试 Jitsi 服务

运行 3 名参与者连接到 Jitsi 视频会议服务的测试（在开始前设置有效的ROOM_NAME环境变量）：

# Start the two participants without network limitations.
docker run -it --rm \
    -v /dev/shm:/dev/shm \
    -v $PWD/.webrtcperf:/root/.webrtcperf \
    ghcr.io/vpalmisano/webrtcperf \
    --url=https://meet.jit.si/${ROOM_NAME} \
    --url-query='#config.prejoinPageEnabled=false' \
    --sessions=2 \
    --stats-interval=5

# Start the third participant with limited downstream networking at 500 Kbps, 50ms RTT
sudo modprobe ifb numifbs=1 # Required only on first run.
docker run -it --rm \
    -v /dev/shm:/dev/shm \
    -v $PWD/.webrtcperf:/root/.webrtcperf \
    --cap-add=NET_ADMIN \
    ghcr.io/vpalmisano/webrtcperf \
    --url=https://meet.jit.si/${ROOM_NAME} \
    --url-query='#config.prejoinPageEnabled=false' \
    --sessions=1 \
    --stats-interval=5 \
    --throttle-config='{down:[{protocol:"udp",rate:500,rtt:50,loss:"0%",queue:50}]}'

前两名参与者的输出示例：

以 1280×720、25 fps、1060 Kbps 发送 2 个视频流

                          name    count      sum     mean   stddev       5p      95p      min      max
  -- Outbound video ----------------------------------------------------------------------------------
                          sent        2    10.16     5.08     0.04     5.04     5.12     5.04     5.12 MB
                          rate        2  2120.52  1060.26    88.03   972.23  1148.29   972.23  1148.29 Kbps
                          lost        2              0.00     0.00     0.00     0.00     0.00     0.00 %
                 roundTripTime        2             0.040    0.001    0.038    0.041    0.038    0.041 s
 qualityLimitResolutionChanges        2        5        2        0        2        3        2        3
          qualityLimitationCpu        2        0        0        0        0        0        0        0 %
    qualityLimitationBandwidth        2        0        0        0        0        0        0        0 %
                sentMaxBitrate        2     0.00     0.00     0.00     0.00     0.00     0.00     0.00 Kbps
                         width        2              1280        0     1280     1280     1280     1280 px
                        height        2               720        0      720      720      720      720 px
                           fps        2                25        0       25       25       25       25 fps
              pliCountReceived        2                11        1       10       13       10       13

第三个参与者的示例输出（下游有限）：

以 320×180、13–20 fps、33–102 Kbps 接收 2 个视频流

                  name    count      sum     mean   stddev       5p      95p      min      max
  -- Inbound video -----------------------------------------------------------------------------------
                      received        3     0.57     0.19     0.13     0.00     0.31     0.00     0.31 MB
                          rate        3   223.46    74.49    29.80    33.17   102.37    33.17   102.37 Kbps
                          lost        3              0.11     0.15     0.00     0.32     0.00     0.32 %
                        jitter        3              0.02     0.00     0.01     0.02     0.01     0.02 s
          avgJitterBufferDelay        2            115.19    10.11   105.09   125.30   105.09   125.30 ms
                         width        2               320        0      320      320      320      320 px
                        height        2               180        0      180      180      180      180 px
                           fps        2                16        3       13       20       13       20 fps

我们可以使用“–prometheus-pushgateway”命令行选项将指标发送到外部Prometheus Pushgateway服务。让我们更改第三个参与者命令行：

docker run -it --rm \
    -v /dev/shm:/dev/shm \
    -v $PWD/.webrtcperf:/root/.webrtcperf \
    --cap-add=NET_ADMIN \
    ghcr.io/vpalmisano/webrtcperf \
    --url=https://meet.jit.si/${ROOM_NAME} \
    --url-query='#config.prejoinPageEnabled=false' \
    --sessions=1 \
    --stats-interval=5 \
    --prometheus-pushgateway=http://${PUSHGATEWAY_HOST} \
    --throttle-config='{down:[{protocol:"udp",rate:1000,rtt:50,loss:"0%",queue:50},{protocol:"udp",rate:500,rtt:50,loss:"0%",queue:50,at:180},{protocol:"udp",rate:1000,rtt:50,loss:"0%",queue:50,at:240}]}'

我们开始将下行带宽限制在 1000 Kbps，我们在 2 分钟后将其降低到 500 Kbps，并在 2 分钟后再次将其增加到 1000 Kbps。使用 Grafana，我们可以获得所收集指标的图形可视化：