导语 | 随着音视频应用的不断更新，对传输能力和体验的需求也日益增加，促进了传输技术的发展，也带了如何选择的难题。本文详解了音视频领域的几种主要传输协议,希望能够帮助大家解决实际需求和业务场景中的技术选型问题。
随着互联网的发展，Web及移动智能手机端的兴起，音视频应用也得到了蓬勃发展。同时伴随着4G/5G的商业化，人们在娱乐直播、购物、教育、医疗等领域，对于实时音视频通信的需求不断增长。直播、实时音视频等技术也开始崭露头角。
众多的音视频应用都避免不了一个问题就是，如何在现有的网络条件下，提供更稳定、体验更佳的传输特性。
不同的音视频应用场景对于质量和体验的需求往往各有偏重。
- 流媒体直播 流媒体直播往往要求较低的延迟，一般要求在1-5s的级别。另外，首帧，即用户点击播放到看到第一帧画面的时间，也是一个重要的体验点。除此之外，在不损伤画质和音质的情况下，流畅度的高要求，使得传输需要具备较好的抗抖动性。
- 点播、静态文件 与直播相反，对延迟没有要求，但是对播放流畅度要求较高。而且同样有秒开的需求。
- 实时音视频 交互性比较强，因此延迟需要控制在500ms以内的级别。与直播点播不同的是，实时音视频更注重实时性，并且在通话场景音频的优先级更高。
2.1 TCP
TCP目前是互联网中主要的传输协议，承载了互联网中大部分流量。其拥塞控制算法是非常重要的一环。早期的拥塞控制算法主要是基于慢启动与拥塞避免的思想，这些算法都是在发送方设置一个拥塞窗口来控制发包速率。如Tahoe/Reno/NewReno等。优化的方向更多是快恢复、快重传等减少丢包对窗口的影响。
CUBIC
前面的拥塞控制算法进入拥塞避免状态或快速恢复状态后，每经过一个RTT才会将窗口大小加1，在RTT很长的场景，需要很长时间才能达到最佳拥塞窗口。BIC算法利用二分查找，能够更快的逼近最佳拥塞窗口。CUBIC是BIC-TCP的下一代版本，用一个cubic 函数替换了BIC-TCP的窗口变化增长逻辑，而不是通过ACK到达后的处理行为来探测窗口。因此窗口的增长独立于RTT。在2006年，从2.6.18内核开始，CUBIC取代了BIC-TCP，成为了默认的TCP拥塞算法。
BBR
以上的拥塞控制算法均是基于丢包的，在一些场景特别是4G/5G/WiFi等移动端场景，由于链路层和物理层误码导致的随机丢包会时常出现，而并不意味着链路中出现了负载较高的路由器节点（拥塞）。BBR 不再使用丢包作为拥塞的信号，也不使用 “加性增，乘性减” 来维护发送窗口大小，而是分别估计极大BW带宽和极小RTT延迟，把它们的乘积BDP作为发送窗口大小。
BBR 解决了两个问题：在有一定丢包率的网络链路上充分利用带宽。降低网络链路上的 buffer 占用率，从而降低延迟。使得非常适合高延迟、高带宽的网络链路，同时又非常适合慢速接入网络的用户。
BBR的状态有四个，STARTUP是BBR的加速阶段，以指数的增益速度增加发送速率，希望快速探测到瓶颈带宽。DRAIN：在该阶段，BBR使用一个小的增益系数计算pacing rate和拥塞窗口cwnd，以使网络队列缓存迅速排空，使inflight大小等于BDP。PROBE_BW：当BBR测量到瓶颈带宽和最小rtt，并且inflight等于BDP后，便开始维持一个稳定的匀速状态，周期性提速探测是否有更大带宽，或降速公平的让出部分带宽。通过增益系数来控制幅度。
static const int BBR_pacing_gain[] = {
BBR_UNIT * 5 / 4, /* probe for more available bw */
BBR_UNIT * 3 / 4, /* drain queue and/or yield bw to other flows */
BBR_UNIT, BBR_UNIT, BBR_UNIT, /* cruise at 1.0*bw to utilize pipe, */
BBR_UNIT, BBR_UNIT, BBR_UNIT /* without creating excess queue... */
};PROBE_RTT：只要满足条件：在一个时间窗口内测的RTT没有比前一个周期的最小RTT更小，则认为网络发生了拥塞，重新进入PROBE_RTT状态计算RTT。
由于增益系数的存在，也限制了最大冗余带宽，因此，当丢包率超过这个限制时，会出现类似下图抗丢包的明显下降。
BBRv2
BBR存在一些问题。首先是失速，drain、probe_rtt状态的存在使得发送速率会受到影响。其次是收敛速度过慢。然后是公平性，在BBR和CUBIC共存时会挤占带宽。BBRv2做了一些修正，总体目标是更快更精准的去使inflight能逼近最佳带宽。主要修改包括调整probe_rtt进入的频率和时间，并缓和拥塞窗口的变化，probe_bw状态时加快收敛速度，还有引入丢包和ECN来控制startup阶段的退出以及inflight的范围，提高公平性等。
TCP常见调优方式
除了拥塞控制算法以外，影响传输效率的因素还有很多，譬如TFO（TCP Fast Open）、timewait回收机制、初始拥塞窗口、接收窗口、pacing、SACK/FACK等等。不过TCP因需要依赖操作系统内核、可控性差，而且有一定资源消耗，未来UDP的趋势会越来越明显。
腾讯云音视频，RT-ONE™音视频通信基础网络，也对TCP协议做过深入优化，如基于性能和成本的综合考虑，兼顾了BDP_based算法和Loss_based算法，完善快速重传机制，以及具备自适应的功能等。
2.2 通用低延迟抗抖动传输协议QUIC
基于TCP的HTTP1.1主要的问题包括高延迟 — 队头阻塞(Head-Of-Line Blocking)、无状态特性 — 阻碍交互、明文传输 — 不安全性以及不支持服务端推送等。
HTTP2基于SPDY，除了支持多路复用解决对头阻塞、加密传输、头部压缩和支持服务器推送等特性，还优化了压缩算法、可选择的http/https传输以及支持二进制传输。但HTTP2仍有TCP队头阻塞、连接耗时长等问题。
QUIC基于UDP，很好解决了上述问题，支持0rtt connect、多路复用和连接迁移，还支持热插拔的拥塞控制策略，同时，也支持FEC。
关于0rtt，传输层由于用的是UDP，这个好理解，另外QUIC支持加密，所以也需要支持加密层的0rtt。QUIC是通过客户端支持ServerConfig缓存（存储 Diffie-Hellman等加密算法的密钥信息）来实现0rtt。对于全新的连接来说，至少要1rtt才能完成握手，然后缓存ServerConfig信息。针对0rtt的安全性问题（缓存密钥信息有泄露风险），QUIC提供了密钥升级的方案，初始包使用不同的initial key进行加密。此外，在分布式环境下，后台server需要有共享client信息的能力，来提高0rtt成功率。
连接迁移也比较好理解，任何一条QUIC连接不再以IP及端口四元组标识，而是以一个64位的随机数作为ID来标识，这样IP或者端口发生变化时，只要ID不变，这条连接依然维持着，上层业务逻辑感知不到变化，不会中断，也就不需要重连。
解决队头阻塞上，QUIC最基本的传输单元是Packet，不会超过MTU的大小，整个加密和认证过程都是基于Packet的，不会跨越多个Packet。这样就能避免TLS协议存在的队头阻塞。同时，QUIC通过Stream之间相互独立做到多路复用，不存在TCP队头阻塞。
QUIC目前已作为HTTP3的传输协议，而且被广泛应用在各个领域。
2.3 流媒体直播领域的专业玩家SRT/RIST
SRT 是由Havision联合Wowza制定的一个开源、免版权费的基于UDP的传输协议，目的是安全和可靠的解决TCP在长距离链路传输中延迟高、抗抖动性差的问题，并针对直播流媒体场景特别是OTT行业的需求做了优化。
某用户推流端关于推流丢帧率的对比
在传输质量指标上，SRT 通过更精准和快速的重传控制，以及针对直播流媒体场景的 Pacing 机制，使得在相同丢包率下，应用层丢包较少。当丢包率在 50%时，SRT 相比 QUIC 仍能保证稳定的传输。SRT区别于QUIC主要做了以下几点：
- 通过支持 NACK, 丢包高优先级处理, 及时重传, 保证实时性。
- LIVE模式下弱化拥塞控制, SRT和QUIC相比，没有增益系数的限制，强调pacing发送, 根据输入速率(对于直播场景就是输入的音视频码率) 平滑发送, 同时预留一部分带宽(可以通过SRTO_OHEADBW设置)百分比用于做重传和突发发送(比如码率突然飙高)。
- SRT可以通过配置设置是否丢包。这个在一定场景很有帮助，如ott有些场景要求恒定延迟，但允许可选择的丢掉某些数据包。
SRT/QUIC传输性能对比
抗丢包：
和 QUIC 上行对比，在推流端相同链路同一直播文件的情况下，每5分钟提高了5%的丢包率，通过以下示图可以看出 SRT 的推流帧率更平稳。
以下在rtt 100ms的偏弱网环境下做的一些对比测试验证数据：
rtmp over SRT/QUIC的对比
场景: 相同链路同一直播文件，每5分钟提高5%丢包率
效果: RTMP over SRT推流帧率更平稳
从对比发现，SRT的抗随机丢包的能力远优于QUIC或TCP-BBR等方案。
SRT的这些特性和效果，使其更适合于直播流媒体场景，特别是OTT这种对音视频源数据的稳定性要求更高、远距离传输而且带宽足够的场景。
SRT的不足
SRT有pacing机制，通过控制发包间隔来实现，而发包间隔是通过bw来计算的。bw的取值取决于输入码率以及overhead（为弥补重传的额外补偿值，可设置）的大小，因此在传输文件的场景，拥塞控制的公平性并不是太精准，当重传率较高时，而带宽受限时，会造成SRT失速的现象（过度的重传挤占了有限的带宽，导致有效传输率下降，从而使得SRT判断的输入码率继续下降，恶性循环）。通常也可以通过设置max_bw来防止流量burst的行为，但是需要提前设置好。另外，为了提高安全性，SRT有较复杂的handshake交互，以及没有超时重传等等问题。
当限制bw时，由于重传包的积压会影响有效发送速率
TSRT
腾讯云音视频，RT-ONE™音视频通信基础网络，为了扩展SRT在直播领域的应用场景，做了一些优化，如支持1-rtt/0-rtt，优化重传间隔控制，增加超时重传等。
具体的，在优化时主要基于更精确的RTT测量并修改了重传间隔的控制。同时，带宽评估环节调整了测量的范围并采用组包发送以及针对测量值去噪滤波的策略。基于评估的带宽，调整SRT中最大带宽的数值，可以更好的控制重传率。同时在乱序容忍度上，引入了自适应调整的机制，弥补了固定值策略在rtt较小且高码率传输场景上的不足。
TSRT优化重传间隔控制后，相同场景重传率降低30-60%
基于多采样延时梯度的带宽估计
RIST
RIST是为解决在公共网络上的丢包问题，同时解决各厂商设备之间缺乏互操作性的问题的背景下，Video Services Forum (VSF) 于2017年初成立的可靠的互联网流传输协议（Reliable Internet Stream Transport，RIST）小组。RIST协议2017年提出，至今（2021年）发布了两个profile，2018年发布simple profile，2020年发布main profile。RIST的首选流传输协议是RTP配合RTCP。RIST也是可靠传输，但是因为限制了应用层封装格式、开源项目成熟度、多路复用的问题等与SRT的应用还是存在一定的差距。
2.4 实时音视频中的传输控制
WebRTC是应用在实时音视频场景的全系统的解决方案，包括传输、应用协议、媒体封装、系统以及API。
WebRTC的QoS机制较多，主要包括NACK、FEC、时域SVC、JitterBuffer、IDR Request、pacing、VFR（动态帧率调整策略）等等。
但是今天这里重点只谈一下传输，WebRTC最常用的拥塞控制算法是Google推出的GCC。GCC主要分两个部分，一个是发送端基于丢包率的码率控制，一个是接收端基于延迟的码率控制。
发送端基于丢包率的码率控制
GCC使用的丢包率根据接收端RTP接收统计信息计算得到，通过RTCP RR报文中返回给发送端。信息包含Packet Loss，Jitter，DLSR等等。在rtt较短的场景，基于丢包的码率控制就显得比较重要。
接收端基于延迟的码率控制
接收端基于数据包到达延迟估计发送码率Ar，然后通过RTCP REMB报文反馈到发送端，发送端把Ar作为最终目标码率的上限值。具体包括如下几个模块：
Arrival-time filter模块。目的是通过自适应滤波器（如Kalman滤波）过滤时延统计中的噪声，计算排队时延。Over-use detector模块以前面计算得到的网络排队延迟为输入，结合当前阈值判断当前网络是否出现了过载现象。Remote rate controller。目的是根据判断结果调整估算的接收速率Ar。REMB Processing模块。负责将上一个模块计算出的速率Ar通过REMB信息发给客户端。同时会根据变化幅度选择是周期性还是立即发送REMB信息以调整码率。
WebRTC越来越多的用在实时音视频领域，已经成为主流默认方案，并在低延迟直播领域中也得到了应用。
腾讯云音视频，RT-ONE™音视频通信基础网络，对WebRTC协议做过深入优化，包括通过0rtt、分级重传、I帧确认、音频fec等技术升级改造WebRTC原有技术首帧差、开播失败差、卡顿差等问题，同时在编码层面页新增了原版WebRTC不支持的部分，这里不再赘述。
随着音视频应用的不断更新，用户和开发者对传输质量和体验的要求也日益提高，从而也促进了传输技术的发展。RT-ONE™音视频通信基础网络针对各种音视频应用场景做了融合和优化，在音视频领域不断探索，结合用户业务场景不断创新，给广大用户带来全新的高质量观看体验。
腾讯云音视频在音视频领域已有超过21年的技术积累，持续支持国内90%的音视频客户实现云上创新，独家具备 RT-ONE™ 全球网络，在此基础上，构建了业界最完整的 PaaS 产品家族，并以 All in One SDK 的创新方式为客户服务。腾讯云音视频为全真互联网时代，提供坚实的数字化助力。
