問題背景

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不進行丟包重傳，此時會出現馬賽克，卡頓等問題