即构科技的连麦互动直播技术，连麦方的延迟1秒左右

雷锋网（公众号：雷锋网）出版社：卡森，本文作者，集购科技资深直播技术及音视频云服务后端工程师。

让子弹飞一会儿。

某名人抱怨道：“你一会儿要飞到哪里去？” 这颗子弹的延迟太大了。

那个名人就是你。

为什么低延迟很重要？

低延迟子弹可以杀死千里之外的敌人，低延迟的直播技术可以杀死千里之外的粉丝。

互动直播技术已经成为直播平台的标配。一个没有互动直播技术的直播平台，是无法跻身直播行业第一梯队的。为了获得互动直播技术，需要实现低延迟。

所以低延迟很重要。

那么，直播技术是如何做到低时延的呢？

请允许我根据即时技术直播技术的经验与大家分享如何实现低延迟。

Instant Technology的连麦互动直播技术，对于连麦端有400毫秒的延迟，对于观众来说有1秒左右的延迟。目前，影客直播、花椒直播、易直播、栗子直播均采用了即兴科技的连麦互动直播技术。因此，这种直播技术经验是经过市场验证的，是从实际操作中获得的，而不是单纯的理论分析。

一般来说，只有在延迟小于800毫秒的情况下，你才能在直播过程中连接麦克风，做一些相对高频的交互，比如相声或脱口秀。如果延迟高于 800 毫秒，则直播中连接麦克风的效果无法被观众接受。因此，延迟400毫秒的直播技术，有足够的空间来实现连麦互动直播业务。

要在直播技术中实现低延迟，有一个简单而务实的理念：

1）选择最优路径；

2） 在这条路上做到最好；

3）保持所有路径的高质量。

下面我将按照这个思路来讨论如何实现低延迟。

选择最优路径

有很多方法可以选择最佳路径。目前采用网速测量、用户个人连接数据分析、用户组连接数据分析等几种方法来选择最优网络路径。

网速测试

在推流之前，推流端先向每条路径发送简单的数据包，然后根据数据包的响应时间推断出哪条路径最快。这种方法比较简单，有效但有限：选择的路径只有在测试时间点最快，网络情况随时间变化；另外，简单数据包的速度比较快，并不代表流媒体传输的数据速度也比较快。因此，这种方法得到的结果只能作为参考指标。

大数据分析

为了避免单次采样时间点测速造成的偏差，可以通过分析历史大数据来预测哪条网络路径是最优的。历史大数据分析分为用户个人联系数据分析和用户群体联系数据分析两个维度。

1. 用户个人连接数据分析

每个主播用户的使用历史数据都有规律可循。通过分析这些历史数据，可以了解锚点用户从哪里访问、何时访问、访问哪个服务器、走什么路径才能达到最佳效果。这些历史数据的积累越丰富，历史数据分析得出的结论就越可靠。这种方法可以找到个别锚定用户的周期性网络连接，并且大部分时间都可以找到连接效率最好的网络路径。但是这种方法的缺点是数据采样仅基于单个用户，采样点太少，并且没有全局考虑用户所在区域的整体网络连接。

2. 用户组连接数据分析

为了弥补用户个人关系数据分析的不足，这里引入数据分析的另一个维度：对某个区域的用户群关系数据的分析。通过分析用户所在区域的用户群历史数据，可以发现该区域的网络连接随时间变化的规律，找出在不同接入点连接哪个服务器最好在不同的时间点。

可以结合单点网速测量、用户个人连接数据分析、用户组连接数据分析得出结论，可以有效预测哪条路径最好。这部分路由需要不断优化，积累丰富的用户数据，适应网络变化。

在这条路上尽力而为

在选择了最优路径之后，剩下的就是在那个路径上是最优的了。该路径包括以下步骤：采集、编码、流式传输、转码、分发、流式传输、解码和渲染。在实时音视频系统架构中，每个环节都会有一定的优化空间。业内小伙伴已经在这条路上进行了很多探索。这里不想重复别人探讨过的话题，只关注以下几个重点。

选择协议

传输协议的选择非常重要。传输协议在一定程度上决定了延迟的范围。在选择传输协议时，请考虑它是推端还是拉端。推流端的协议包括RTMP、WebRTC和基于UDP的专有协议。

1. RTMP是基于TCP的标准协议，CDN网络普遍支持，可以实现比较低的延迟。Instant Technology 的互动直播技术在推流端使用 RTMP 协议，推流端兼容 RTMP、HLS 和 FLV 三种协议。HLS协议的延迟比较大，在需要连接麦克风的场景下不应该使用HLS协议。

2. WebRTC的优点是用户体验好，不需要安装任何东西，分享一个链接即可观看。但它有一个缺点，那就是WebRTC是谷歌推动的技术。除了 Google Chrome 和 Opera 支持 WebRTC，其他大多数浏览器都不支持 WebRTC。

也就是说，40%的浏览器支持WebRTC，剩下的60%的浏览器不支持，所以应用范围相对有限。那么，在中国，WebRTC 在 Google Chrome 上的表现也大打折扣。最后，由于浏览器不具备开核能力，运行在浏览器上的协议很难实现更低的延迟。

3. 基于UDP的私有协议非常适合实时音视频系统。它是无连接的节点延迟是什么意思，避免了TCP对网络质量控制所需的开销，并且可以实现相对较低的延迟。

但它也有一个缺点，就是私有协议的兼容性不好。CDN 支持标准的 RTMP 协议，但不支持基于 UDP 的专有协议。为吸收UDP的优点，规避UDP的缺点，高德互动直播技术采用基于UDP的私有协议作为补充。服务器使用 RTMP 协议将流转发到 CDN 网络。在这两个网段之间，将UDP私有协议转换为RTMP协议进行连接。这样一来，即兴科技的直播解决方案不仅具有超低延迟的优势，还保留了标准协议普遍支持CDN网络的优势。

前向纠错和丢包重传

Forward Error Correction（FEC），英文全称Forward Error Correction，是提前采取措施对抗网络破坏。丢包重传主要是为了在丢包的情况下高效地重传丢失的数据包。准确地说，它们的直接目的不是减少延迟，而是对抗网络损伤。在不可预知的网络环境中，能够很好地处理网络抖动带来的负面影响，间接降低时延，同时保证稳定性和流畅性。

一般来说，前向纠错和丢包重传是相辅相成的。前者属于先验方法，节省时间但占用过多带宽；后者属于后验方法，节省带宽但消耗更多带宽。时间。在网络较差、丢包率较高的情况下，可以采用前向纠错的方式来保证信息的完整传递。比较

例如，发送冗余信息可以保证接收方在一定的丢包率下，能够准确、完整地还原发送方要发送的信息。当网络比较好，丢包率比较低的时候，可以采用丢包重传的方式来保证信息的完整传递。例如，对于丢失的数据包，通过一种高效的机制进行重传，以保证接收方能够完整接收到发送方发送的消息。

缓冲适应

由于网络抖动的存在，数据包的到达是不均匀的。

减少延迟最直接的方法就是将缓冲队列的长度设置为零，无论接收到什么数据包都直接渲染。但是这样做的后果就是播放不流畅，还会出现卡顿。

因此，延迟和平滑度本身就是矛盾的因素。我们需要做的是在低延迟和平滑度之间找到一个平衡点，而找到平衡点的有效方法是建立一个缓冲队列。流端和流服务器都需要建立缓冲队列。对于实时系统来说，缓冲队列的长度一定不是固定的，而是自适应的：当网络非常好的时候，缓冲队列的长度会变得比较短，接近于零，甚至为零；当网络不好的情况下，缓冲队列的长度会变长，但不能超过可接受的上限。毕竟缓冲队列的长度本质上就是延迟时间。

此外，缓冲自适应技术可以与快播或慢播技术结合使用。当网络由坏转好时节点延迟是什么意思，可以适当加快广播速度，尽快缩短缓冲队列的长度。当网络由好转坏时，可以适当放慢广播速度，适当拉长缓冲队列，保持流畅。快放和慢放是结合观众的心理模型，在适合快放和慢放的条件下使用，让观众感觉不到回放速度的变化，整体感觉流畅低延迟。

比特率适配

由于网络环境复杂多变，码率必须能够自动适应网络条件的变化，这就是所谓的码率自适应。网络较差时，应降低码率，保持直播低延迟，流畅；网络好的时候，要提高码率，保持直播的高清画质。为了实现码率适配，协议选择也很优雅。RTMP对码率适配能做的比较有限，因为它是基于TCP的，TCP的下层已经做了网络质量控制。当网络拥塞时，不会及时通知上层应用。基于UDP的私有协议更适合码率适配，因为它是基于UDP的，

保持所有路径的高质量

那么，直播技术要实现低时延，就需要选择一条最优路径，并在这条路径上最优。故事结束了吗？不，我们忘记了一个前提：整体路网必须足够好。路网不好，再怎么选土路，选土路怎么跑得快？因此，要实现低延迟，网络基础设施必须足够好。可以通过三种方式提高网络基础设施的质量：

全网覆盖

一般来说，音视频云服务的机房分布在几个核心枢纽城市，偏远地区用户的访问质量得不到保障。此外，在中国，各个网络运营商的覆盖面参差不齐，一些网络运营商在一些偏远地区也缺乏覆盖。为了实现全网全覆盖，可以采用多节点代理和重定向，保证全网全覆盖，无盲区。这需要在实践中进行充分的测试，以验证各种网络可以完全连接。

QoE全面保障

网络接入点的覆盖范围对于 QoE（体验质量）非常重要。从开箱即用的经验来看，这可以通过在全球部署接入点来确保。另外，由于国内存在“两大网多小网”的情况，在这种情况下BGP是非常有必要的。BGP可以很好地解决不同网络之间的互通问题。也就是说，所有网络接入点都使用 BGP。

优质网络节点资源

音视频云服务运行在网络基础设施之上。底层网络基础设施的质量必须是高质量的，音视频云服务必须与底层网络基础设施深度融合。为了实现直播技术的低延迟，最好与一线网络运营商对接，这样部署的网络节点资源在数量和质量上都得到充分保证。这也是iConstruction团队在过去十年运营大量用户的过程中总结出来的经验。

综上所述，要实现直播技术的低时延，必须选择最优路径，进而达到最优路径。最后，必须保证所有路径的质量。道理很简单，却很难领悟，魔鬼藏在细节里。