WebRTC 中的网络拥塞控制

1. WebRTC网络传输控制李超音视跳动首席架构师

2. • Content Title 1

3. • 实时通信的目标 • 存在哪些困难，或存在哪些矛盾点？ • WebRTC是如何解决这些矛盾的

4. 一些思考问题一：开会时是喜欢在一个办公室里开呢，还是更喜欢在线上开？问题二：如果有一场演唱会，你愿意去现场呢？还是愿意在线上听？

5. 为什么线上沟通与线下不同？ • 网络延迟过大 • 摄像头与人眼看到的效果不一样，如采集的角度过小 • 采集设备的质量参差不齐 • 现场的气氛无法被摄像头采集到

6. 实时通信的目标尽可能逼近或达到面对面交流的效果

7. 主要矛盾

8. 主要矛盾音视频的服务质量与带宽大小、网络质量、实时性之间的矛盾

9. WebRTC解决矛盾的方法

10. 网络模块要解决的问题 • 实时性 • 抗丢包性 • 公平性 • 带宽评估的准确性和及时性

11. 如何能做到实时性？

12. 解决实时性的方法 • TCP/UDP？ • 通信双方是否可以走内网？ • P2P是否可以连通？ • 服务器中转 turn/sfu/mcu

13. 为什么极端网络下不能用TCP？ • 发送->接收->确认

14. 实时性的延时指标

15. 传输路径的选择

16. WebRTC抗丢包

17. 造成丢包的原因 • 链路质量差 • 带宽满 • 主动丢包 • 光纤被挖断 • …

18. WebRTC抗丢包的方法 • 丢包重传（NACK），可以容忍10%的丢包 • FEC

19. 50%以上丢包靠谱吗？

20. 丢包重传

21. 什么时候适合丢包重传？ • 重传用时为: 1.5RTT+10ms • 时延比较小的丢包适用于丢包重传

22. FEC异或操作 • A ^ • C ^ • C ^ • A ^ • … B = C A = B B = A B ^ C = D

23. ULPFEC • 1-9是正常的数据包 • Rn 是冗余包

24. FlexFEC • 先横向进行纠错 • 再进行纵向纠错

25. 结论 • 丢包重传 NACK不适用于时延大的场景 • FEC不适用于连续丢包的场景 • 50%以上丢包是实验室环境，不是真实场景

26. 网络传输的公平性

27. 多个GCC连接的公平性 • 40ms加入第二个GCC连接 • 80ms加入第三个GCC连接

28. 与TCP共存时的公平性 • 20ms~100ms加入TCP • REMB-GCC和SCReAM 表现不佳

29. 带宽评估的准确性

30. 通常带宽的使用 2Mbps

31. 更好的带宽的利用率 2Mbps 1.5Mbps 1Mbps

32. 带宽评估的准确度 • 基于丢包的带宽评估 • 基于延时的带宽评估 • Goog-REMB • Goog-TCC

33. 基于丢包的评估方法

34. 基于延时的评估方法

35. WebRTC拥塞控制流程

36. 总结

37.

38.

39. • Content Title 1

40. WebRTC_中的网络拥塞控制扫描二维码提交议题反馈