浅谈音视频网络传输

瞎扯

谈到音视频方向的不可避免的谈到采集、前处理，编码、传输、存储、解码、后处理、显示；作为一个整体向用户提供时，性能、服务质量是最重要的标准，但是这里不谈论整体的性能、服务质量，我们谈论下传输相关的常见的问题和解决方案。其他步骤如何衡量都有专门的标准，不是这里要谈论的。

这里的传输是泛指不单单指网络传输，但是我们这里确单单只谈论公网传输，因为公网传输是最复杂的场景，其他传输可以参考网络传输。

网络传输现在最出名的应该是QUIC了，这个协议已经被纳入了http3标准；但是这些文章有很多，我们还不谈。

网络传输本质

图1表明数据产生速度和网速相等，这个时候是最佳状态，尽可能完整的发送更多的数据。

图2表明数据产生的速度大于网络速度，这个时候会出现网络拥塞，出现丢包、乱序；都是无法及时、可靠的传给对端的（这个时候有同学说TCP可以可靠传输，但是无法及时；UDP可以快速但是无法可靠）

图3表明数据产生的速度小于网络速度，这个时候网络不会拥塞，我们大部分都是要解决的是这种场景下的丢包、乱序问题。

结论

分析上面三个图可以得出这个结论，如果网络小于数据产生/消耗速度；生产侧出现数据积攒，数据无法及时发出；播放侧会出现卡顿；这个是必然，但是我们怎么知道网速是多少啊，老板一问傻眼了！？下面谈论是如何合理的怼老板的方法。

数据说话

先说定义，再说数字！

先说定义，再说数字！

先说定义，再说数字！

先说不好的，但是我经常看优爱腾天天说自己成功率99%以上，但是我一直是1%的人；他们定义的99%是对外的指标，但是实际指标只有自己清楚，举例说明：

一个不存在的资源播放了对于播放器团队肯定把这个当成噪点过滤，不算自己失败；但是对用户来说是个失败啊！

一个播放中间忽然网络卡顿了，没法继续播放了，原因未知，但是这种情况一般没有人统计，但是对于用户也是个失败！

如果老板问一些很傻的问题，上面人家这种统计方式忽悠老板完全没问题；他们可以很有理由的说我们统计是99%成功率，然后老板问那1%失败是啥原因啊，他们说CDN资源不存在占比20%，网络不好用户没有没有播放出来就停止了70%，还有10%的情况未知，就这么忽悠老板结束了；哎，没办法，互联网浮躁啊，没有真正对用户负责的太可怕了。（小公司的机会）

真正的数据埋点应该是从用户体验埋点，然后再分开埋各个模块的点，如果用户体验收到的影响可以追踪到那个模块出了问题；本着这个原则，网络如何埋点呢？! 

丢包：丢包的总数、最大连续丢包个数、最小连续丢包个数；分别统计1s 5s 10s

乱序：乱序总次数，最大的乱序次数，最小的乱序次数；分别统计1s 5s 10s

RTT：平均RTT，最大的RTT，最小的RTT，分别统计1s 5s 10s

我们在传输的时候也会加入NACK、FEC；这个时候还要统计FEC包数、恢复的包数、NACK包数，恢复的包数；丢包就要统计恢复后的丢白、恢复前的丢包。当我们把这些数据摆在面前的时候，老板还有什么话说呢！？但是如果这些没问题，但是用户还是反馈体验太差，这个时候就不是网络传输问题，要从自身查找问题了，

网络抖动一下你的系统都扛不住说不过去吧？

网络抖动你恢复的特别慢说不过去吧？

带宽大于数据但是还是卡成屎说不过去吧？

音视频不同步说不过去吧？

人家cpu20%，你非要30%说不过去吧？

渲染有锯齿说不过去吧？

没有美颜说不过去吧？long-fat网络咋办？

brust丢包咋办？

用你的音视频系统包太大说不过去吧？

问题一大堆，总之demo距离工程还有1w个webrtc。