问题背景
srs部署在云服务器上,32核cpu,64G内存,带宽300M.
客户端从srs拉流,发现外网客户端拉流,cpu和带宽都正常。然而内网客户端拉流,拉流人数超过5人以上,带宽就会迅速飙升。
排查
用srs-bench进行srs压测,vlc播放器srs拉流,以及客户端srs拉流
推流
推流选择ffmpeg推流
ffmpeg -re -i C:\Users\w\Desktop\test.mp4 -vcodec copy -acodec copy -f flv -y rtmp://27.128.236.38/live/livestream
A.srs-bench拉流
./objs/srs_bench -sr webrtc://27.128.236.38/live/livestream -nn 10
srs-bench编译及部署参考文章:SRS压测–SRS-Bench
B.vlc拉流
媒体->打开网络串流
输入url:https://ip:8088/live/livestream.flv
分别在西安,南京,北京三地进行srs-bench,客户端及vlc压测
测试记录如下:
环境 | 1人 | 5人 | 6人 | 10人 | 30人 |
---|---|---|---|---|---|
西安服务器压测A网段 | 正常 | 正常 | 异常 | 异常 | 异常 |
西安服务器压测B网段 | 正常 | 正常 | 正常 | 不稳定 | 不稳定 |
西安真实客户端 | 正常 | 正常 | 正常 | 异常 | 异常 |
西安客户端压测 | 正常 | 正常 | 正常 | 异常 | 异常 |
南京服务器 | 正常 | 正常 | 正常 | 正常 | 正常 |
南京真实客户端 | 正常 | 正常 | 正常 | 正常 | / |
南京客户端压测 | 正常 | 正常 | 正常 | 正常 | / |
北京服务器 | 正常 | 正常 | 异常 | 异常 | 异常 |
北京真实客户端 | 正常 | 正常 | 正常 | 正常 | / |
外网压测 | 正常 | 正常 | 正常 | 正常 | 正常 |
vlc压测 | 正常 | 正常 | 正常 | 正常 | / |
验证结果
外网环境压测,带宽正常,cpu正常
内网环境压测,5人以上带宽就会飙升至10倍
抓包对比
分析
异常环境延迟率比正常环境的延迟率高,并且有丢包重传现象
查询srs官网srs官网
核心协议–webrtc中config对于webrtc部分的配置
第一部分,rtc_server是全局的RTC服务器的配置,部分关键配置包括:
enabled:是否开启RTC服务器,默认是off。
listen:侦听的RTC端口,注意是UDP协议。
candidate:服务器提供服务的IP地址,由于RTC的特殊性,必须配置这个地址。详细参考Config: Candidate
tcp.listen: 使用TCP传输WebRTC媒体数据,侦听的TCP端口。详细参考WebRTC over TCP
第二部分,每个vhost中的RTC配置,部分关键配置包括:
rtc.enabled:是否开启RTC能力,默认是off。
rtc.rtmp_to_rtc:是否开启RTMP转RTC。
rtc.rtc_to_rtmp:是否开启RTC转RTMP。
rtc.stun_timeout:会话超时时间,单位秒。
rtc.nack:是否开启NACK的支持,即丢包重传,默认on。
rtc.twcc:是否开启TWCC的支持,即拥塞控制的反馈机制,默认on。
rtc.dtls_role:DTLS角色,active就是DTLS Client(主动发起),passive是DTLS Server(被动接受)。
发现rtc.nack配置默认为on,也就是说如果srs发现有丢包,就会不断的重传数据
结论
经过排查公司内网环境,发现内网环境做了带宽限制,当客户端拉流带宽超过一定大小后,就限制拉流。
此时srs视为网络异常,丢包重传,因此带宽不断飙升
解决
方案1:内网环境放开带宽限制
优势:保证直播拉流的稳定性
缺陷:公司无法监控客户端带宽,成本增加
方案2:
优势:内网及外网的网络正常情况下,直播拉流正常,带宽消耗少
缺陷:网络异常,srs不进行丢包重传,此时会出现马赛克,卡顿等问题