冯迅：YY多媒体实时传输系统演进
本文来自YY基础架构部负责人冯迅在LiveVideoStackCon 2017上的分享，并由LiveVideoStack社区整理而成。冯迅重点介绍了，YY直播平台的架构演进，包括技术栈选择权衡，自建网络与采购CDN协作等。
文 / 冯迅
整理 / LiveVideoStack
大家好，我是冯迅，目前在欢聚时代（YY）主要负责音视频传输系统和音视频直播后端系统。今天想与大家分享的是YY的媒体实时传输系统与优化实践。YY是一家专注于打造专业直播平台与直播内容的互联网公司，业务主要涵盖了BGC、UGC与其背后的多样性玩法等领域。
本次分享内容主要分为以下几个方面：
1、实时可靠传输的重要性
2、不实时、不可靠的影响因素
3、直播传输网络架构演变
4、实时、可靠性优化
5、与CDN结合案例
1、实时可靠传输的重要性
想必大家都看过《新闻联播》，其中可以明显注意到的现象是直播间主播与现场记者连线交流时会出现不同程度的延迟；随着互联网技术的飞速发展，对于手机视频直播而言，消费者不再满足于单纯的直播视频观看，而是追求更多新鲜、有趣的玩法。包括YY一直在尝试的“欢乐篮球”或“陪你玩儿”、“一起玩儿”在内，随着直播场景的不断延伸，这些衍生直播玩法越来越强调互动性，其对网络实时传输的可靠性也提出了更高的要求。
2、不实时、不可靠的影响因素
对于实时性传输的探索，通常我们会关注以下三个关键指标：时延、丢包和时延抖动。由于所处网络环境的复杂多样，实时性传输受到不稳定网络干扰的可能性非常大，甚至于在某个时刻也许会出现连续丢包导致时延骤增，持续一两秒后恢复正常的现象；在生活中，Wi-Fi可以说是无处不在，但当我们在覆盖Wi-Fi的房间中走动或有强雷干扰时，Wi-Fi信号就会变得非常不稳定；除此之外，无论是在核心网还是接入网都需要面对的问题是：网络拥塞——由于链路的带宽或路由节点的性能无法满足要求导致的网络拥塞会逐渐增大RDT的时延，最终导致丢包。在YY的实际运营中我们经常会发现，即使某两个机房之间的传输质量很好，但在某两个服务器或某些IP段间却会出现不定时的丢包。其实这并不代表两个机房间的传输质量变差或者带宽下降，而是由于运营商或中间的路由结点施行的一些如防火墙或流控等策略，这些策略会将部分重要的数据包随机丢掉。这种随机性丢包对业务逻辑处理造成的影响主要体现在有效媒体流的接收延时增大，而时延的不确定增长与缩短的情况如果经常出现，就可将其称为时延抖动。
上图展示的是YY网络的传输架构图。我们可以看到，从客户端APP通过有线与无线网络选择就近的运营商，之后接入到YY的分发系统再到最终的观众端，整体的网络路径比较长并且在包括无线链路、运营商接入节点等核心骨干网的整条路径任何地方都有可能出现丢包。面对更加复杂的广域网环境，我们该如何解决这种不实时性和不可靠性？我认为从端到端的思想出发，不能完全依赖某个算法或重传机制，而是需要一个系统性的解决方法。
3、直播传输网络架构演变
3.1 演进前
首先，了解一下YY传输网络的演变过程。最初YY的核心网是基于广域网自建的一层虚拟网络，其中包括对A端到B端的可行路由进行探测的智能路由探测系统。数据从主播端接入的边缘节点，传递到中间的转发节点再到观众端的边缘节点，这整个过程需要考虑两个关键点：1、边缘节点对包括主播和观众在内所有用户的处理策略是相同的，并不存在任何的区别。2、在业务逻辑上系统认为观众和主播的用户属性是相同的，因而在传输上也有一套统一的传输策略与机制。得益于我们在其中进行的许多优化，这套系统直到一两年前也能稳定运行。当然随着2016年直播行业的火热，直播被赋予了更多创新玩法，特别是像刚刚说的欢乐斗、欢乐篮球等，都是以一个互动性非常强的业务场景为基础。如果不升级传输网络，那么就意味着能够承载这种强互动直播的网络，其复杂性会非常之高，现有网络已无法从容应对直播消费升级与用户对直播产品的需求。结合由产品痛点作出的必要分析，我们对传输网络的架构进行了演进与升级。
3.2 演进后
上图为演进后的YY传输网络架构图，主要由主播分发网络、观众分发网络、内容云处理三部分组成。我们可以根据上行流判断谁是主播，并将包括主播间互动在内的所有活动都集中于主播分发系统，而观众则是一个纯粹的观看视角；即使有与主播互动的需求，观众端对时延性的要求也并不苛刻，因此数据可通过内容云进行一些必要处理，然后再分发给观众。从这里我们可以看出，演进后的网络架构相对于演进前，更加简洁清晰。
这里需要强调的是主播系统与观众系统的差别：
对于主播系统而言，从业务逻辑上来说，如果是针对类似于视频会议的直播需求，我们的方案是将所有支撑功能的组件集中在主播分发系统当中，使其仅专注解决传输问题，不需要在关键组件上进行调整即可应对多种直播情景；从传输层面上来看，主播对互动性的要求很高，那么在传输策略上，不仅需要保证传输流的质量符合要求，更需要控制时延在一个可以接受的范围中。
对于观众而言，如果观看的视频画面出现了几百毫秒至一秒的延时，观众感知到的体验折扣会小于主播感知到的。因为观众观看直播只是单向的数据传输，对于时延的要求相对于主播系统而言更加宽松，因此在传输策略上观众端与主播端存在一定差别，观众更需要的是，在保证视频播放基本流畅的前提下音频与画面是否清晰等等。
4、 实时、可靠优化
YY在实时、可靠优化上的工作主要有以下四个方面：
接入选择
传输策略
多路聚合
网络加速
4.1 接入选择
YY在后台有一套庞大的数据统计系统，对从用户数据接入到最终输出质量的整体传输过程进行统计与评价。
例如北京的用户接入北京的服务器往往会比接到广州效果更高，我们根据一系列统计数据判断用户每一种接入方式的质量并择优分配；即使我们会对用户优先采用就近接入的方式，但当出现类似于覆盖能力较弱的小型运营商未接入某地或接入质量不佳的情况，我们也会考虑让用户从异地接入；除此之外，针对就近接入的服务器出现故障进而影响服务稳定的情况，除了就近接入策略，我们也会在一个分区中为用户分配多个接入节点并提供一种自动链路质量勘测的监测机制，在用户端判断多个接入点的质量并进行动态选择；除了以上优化，为用户分配链路节点时我们也会参考大数据库，例如同一个区域的用户在某个时间段集中选择哪种接入方式，根据大数据反映的结果随时调整分配策略，在充分考虑接入点选择性的前提下尽可能优化接入效果。
4.2 传输策略
1）ARQ&FEC&带宽估计三者结合
传输上的优化主要是前向纠错（FEC）与后向纠错也就是重传（ARQ）。前向纠错类似于我们常用的FEC在控制时延上占有一定优势，而重传（ARQ）应该属于后向纠错的一种，本身意味着加大时延。在实际应用中我们会结合自己的一些要求采取不同的传输策略，但仅有这两种策略还远远不够，有时出现丢包意味着数据量超过了带宽的最大限制，而一味地重传会明显增大带宽压力使得链路环境变得更差，单纯地使用ARQ或FEC都是不可取的，正确的方案是在结合二者时根据对带宽的预估结果确定比重从而避免不断改变传输策略令网络环境持续恶化。在实际实践中时我们需要根据业务属性、音视频流量、音频冗余情况等作出最优调整。随着对音视频信息量的要求越来越高，视频的码率也会越来越大，我们会通过一些编码技术上的优化在保证视频清晰度的前提下降低码率，从而在提升传输效果与用户体验的同时控制成本。
2）码率自适应
使用带宽估计算法估计网络两端的带宽范围，再根据估计值指导后续视频码率的调整，保证发送的流量不会超过带宽，尽可能避免丢包和拥塞的发生。有时即使降低带宽也无法完全避免丢包的发生，或是在调整码率时需要考虑是否进行重传与冗余处理等，我们应该预留出足够的数据空间，从而在发生特殊情况时能够从容应对。
4.3 多路聚合
1）接入侧聚合
接下来我将详细介绍多路聚合过程。多路聚合主要用于接入端与核心网之间。有时大家会看到一些在山区或洞穴等无法获得传统有线或无线网络的环境中进行的直播，我们该如何应对这种苛刻的直播环境？在主播端我们集成了一套可提供多路无线接入功能的聚合YY MiFi方案，提供Wi-Fi与以太网两种接入接口。整套系统的原理类似于一个IP层下的多路UDP隧道，当一个TCP连接时,系统可通过多条不同网络传输路径提升带宽，当某个时间段出现传输质量不佳的情况时,可以在多个传输网络间实时切换保证传输稳定，数据传输至聚合网关后再被提取出TCP的原始内容。我们知道平时手机连接Wi-Fi时看到的IP是Wi-FI分配的内网IP，数据传输至运营商则使用公网IP，而聚合网关在数据的两个方向上分别使用SNAT/DNAT进行不同IP转换.。从客户端发出若干个数据包，这些数据包的传输并不只是在一个通道上，而是根据不同通道质量好坏遵循多路选择的策略，这套策略基于我们自主研发的一套算法构建,目前在申请该算法专利。经过实践检验我们发现，采取上述措施可大大提高从主播或观众到接入服务器之间数据传输的质量。
2）智能分发网络
同样，在智能分发网络上我们也实现了多路路由机制。之前我提到YY在广域网的基础之上自建了一层虚拟网络也就是我们平时说的Overlay，这套网络的连接架构图基于我们自主研发的一套由智能路由监控系统。在接入节点侧我们有一套选路算法用于核心网不同节点之间的数据传输，假设我们为北京联通到广州电信两个节点之间分配多条网络路径，那么数据传输时系统可能会择优选择一条链路传输数据，另外几条则不传输或仅传输部分数据,也有很多人问为什么不多条路径一起传输冗余数据更能保证质量？多路径同时传输存在以下两点问题：第一是随着数据流的增多，节点的性能压力会大大增加，性能压力迫使服务器的数量上升，继而节点的分散程度就会增大，节点分散程度增大带来的直接影响便是流量的加大，假设以前需要2个节点那么现在则需要增加到4个才可满足数据传输要求,当然,多路传输时,数据乱序导致的节点处理和延迟也需要考虑；第二是我们希望实现的是在保证传输质量不变的情况下尽可能降低传输成本，而在直播当中最昂贵的便是流量，流量增加一倍意味着成本的大幅提高。在智能分发网络里面，当面对类似于横跨小运营商的情况，为其选择一条质量比较高的链路即可解决不同运营商之间的跨网质量问题。
4.4 网络加速
1）TCP加速
首先介绍的是网络加速里的TCP加速，想必大家不会对TCP加速感到陌生。我们从2015年开始探索TCP加速，因为类似于RTMP、HLS、FLV等都是基于TCP协议；由于TCP协议本身的一些拥塞算法，在网络环境不佳时其对网络的退让策略比较急进，这让我们不得不寻找合适的解决方案。想要实现非常通用的TCP加速则需采用单向加速，双向加速意味着对端的修改，这在TCP还未被人们所熟知的2015年是不现实并且难度较大的。基于当时的背景我们始终致力于TCP单向加速，主要运用在主播到分发网之间、边缘节点到观众之间、核心网之间以及各个机房之间的加速。特别是在应对首屏秒开的情况，拉取上一个GOP数据流时，我们会通过使用TCP加速算法对下行FLV或RTMP进行加速。YY基于Linux开发了上述一系列配套组件，我们知道在开发TCP加速时要么与Google BBR相似，通过直接修改内核TCP协议机制代码，从而实现TCP加速，要么就是在不修改内核的情况下通过拥塞算法结合其他思路实现类似功能。对YY来说，修改内核涉及到的风险非常大，因而我们主要考虑的还是在内核模块中集成拥塞算法等优化来实现TCP加速的效果，实践的结果可以说符合大家的期待与需求。
2）报文发送加速
接下来介绍的网络加速是报文发送加速。因为网络直播本身是一个多窝的系统，这就意味着主播上传的数据可能会发给成千上万用户，甚至发到某一端的一千、两千个甚至更多的海量节点。报文发送加速是一种常规的加速手段，如果通过UDP传统的socket方式将数据发送给一千人就需要调用系统至少上千次，每调用一次就意味着用户态至内核态的切换。即使相对于TCP协议而言UDP协议的性能较高，但整个过程对性能的消耗依旧非常大。通过实验我们发现，如果不经过加速就通过一个节点将数据转发给几百个用户，那么CPU将会严重超负荷运转。我们该如何实现加速呢？首先需要做的是将内核态和用户态通过内存共享方式打通，把数据包直接送至内核态中并随之进行一次的系统调用，而此数据包在发给多端的过程中其内容是不改变的，改变的只是接收者。系统在把数据包送至内核态后，由内核进行多路转发即可迅速成倍地提升性能。这里是以发送加速为例，而发生丢包或是网络拥塞除了链路带宽以外还有一个很重要的因素就是中间节点的吞吐量性能处理，吞吐量也是决定一条链路带宽能否提升的一个重要原因。
5、与CDN结合案例
大家可能会有一种感觉：YY的传输网络都是自己搭建的，为什么不直接使用CDN呢？我们希望实现的是与CDN的深度融合，首先在布点方面，我们会考虑在部分边远地区或国外等布点成本比较高而CDN的覆盖比较好的地区结合CDN解决一系列问题；其次在面对小运营商时，如果小运营商的问题可以用CDN妥善解决那么我们也会采用；第三是我们会根据不同地区的CDN质量对布网策略进行适当调整，如果某个区域CDN的质量具备明显优势，可以选择让其在质量上与我们布网形成互补，最终呈现给用户满意的体验。
我们期待通过YY在传输网络上的诸多改进与创新满足互联网直播的业务需求，为用户带来非凡的直播观看体验。
Q&A
Q1：MIFI多路聚合部分在IP层下实现的TCP加速具体是指什么？
A：具体是指MiFi将整个TCP层封装到IP层之上，MiFi决定使用运营商的哪条链路发送数据至聚合网关，
通过多条传输路径选择提升TCP速度，这里用到了“隧道”的技术。
Q2：在传输协议的选择上是UDP还是TCP或是二者都有？
A：刚才没有提到的是，我们的整个传输网络主要是基于UDP协议，TCP主要用于首屏秒开等需要快速拉取一定量数据的情景。例如当我们需要快速拉取视频数据时可能刚好取到的是GOP帧中间的数据导致无法正常播放，这时往往需要获取一个完整的GOP帧。最开始的这部分数据我们使用TCP进行快速拉取，后面整体依然采用的是UDP协议处理；另外TCP加速也可用于用户使用FLV或RTMP观看的单边直播或主播使用RTMP推流的直播，都可以达到不错的加速效果。
Q3:在网络加速部分是否考虑修改Linux内核?
A：不会，通信行业在2010年左右提到一个用户态驱动的方案，也就是打通用户态和内核态直接通信方式，把数据包直接丢进内核，需要做的只是在内核中添加一个模块而无需修改内核。修改内核意味着我们自己需要承担内核变动背后的风险，这并不符合目前的要求。
