问题背景
srs部署在云服务器上，32核cpu，64G内存，带宽300M.
客户端从srs拉流，发现外网客户端拉流，cpu和带宽都正常。然而内网客户端拉流，拉流人数超过5人以上，带宽就会迅速飙升。
排查
用srs-bench进行srs压测，vlc播放器srs拉流，以及客户端srs拉流
推流
推流选择ffmpeg推流
bash
ffmpeg -re -i C:\Users\w\Desktop\test.mp4 -vcodec copy -acodec copy -f flv -y rtmp://27.128.236.38/live/livestreamA.srs-bench拉流
bash
./objs/srs_bench -sr webrtc://27.128.236.38/live/livestream -nn 10srs-bench编译及部署参考文章:SRS压测--SRS-Bench
B.vlc拉流
bash
媒体->打开网络串流
输入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服务器的配置，部分关键配置包括：
bash
enabled：是否开启RTC服务器，默认是off。
listen：侦听的RTC端口，注意是UDP协议。
candidate：服务器提供服务的IP地址，由于RTC的特殊性，必须配置这个地址。详细参考Config: Candidate
tcp.listen: 使用TCP传输WebRTC媒体数据，侦听的TCP端口。详细参考WebRTC over TCP第二部分，每个vhost中的RTC配置，部分关键配置包括：
bash
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不进行丢包重传，此时会出现马赛克，卡顿等问题