问题背景

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不进行丢包重传，此时会出现马赛克，卡顿等问题