网易云信流媒体服务端架构设计与实现( 四 ) _架构设计

发布订阅机制发布的内容是：以stream为发布单位，以编码能力为基本内容。其中编码能力包括：codec、分辨率、帧率、码率。
订阅分为两个部分：客户端订阅和服务器订阅。客户端订阅以stream为订阅单位，并携带订阅优先级，也就是流在下行接收中的重要性会反馈在订阅优先级上。另外，当所有的客户发布订阅消息后是交由服务器订阅，它汇聚所有端的订阅消息，向发布源端发送订阅消息，同时将订阅码率反馈给源端。
右图显示的是多流的发布机制是弹性码率大小流机制，上行发布的大小流并不是固定的分辨率，而是一个可伸展的码率空间，小流的码率范围和大流的码率范围都是很大的，这样的设计是以弹性的码率针对上行的带宽，并动态的调整码率，以进行最佳的上行发布,针对下行所有的接收端来调整码率，做到最大程度提高用户体验。
3.3 传输层上下行QoS策略
3.3.1 传输层上行QoS策略

文章插图

对于上行QoS服务器策略主要设计了四种：一是FEC/RED；二是NACK重传请求；三是PLI/FIR；四是接受信息反馈。
在这里我区分了FEC/RED，因为使用RED是为了增强音频的保障性。对于视频，使用矩阵运算的方式生成额外的冗余包去对抗丢包。NACK重传请求是服务器作为接收端在上行传授过程中，如果数据有丢失的话会主动作为接收端发送重传请求进行对抗丢包。
PLI/FIR主要是首帧问题，在偏大量的丢包场景下，也会进行关键帧请求去替代NACK请求。
接受信息反馈是记录上行接受信息，并反馈给源端，源端基于接收信息计算带宽、网络指标等进行一个上行的把控。

文章插图

FEC/RED和NACK重传请求这两种设计都是比较普通的对抗丢包的手段。
FEC/RED机制是基于预测丢包，提前产生冗余，对抗丢包。它的优势是低时延；劣势是抗丢包效果依赖于丢包预测准确性。NACK/RTX机制是如果丢包已经发生，则基于测量的RTT做重传请求的控制。它的优势是不用预测，低时延恢复率高，产生额外流量小；劣势是产生时延，高时延场景恢复效果差，设计不好容易产生NACK风暴。

文章插图

针对前两个设计对抗丢包的特点，网易云信分三个步骤来进行传输质量控制：一是建立网络状态的观测器，评估网络相关指标。二是ARQ手段先行，FEC手段做兜底，也就是尽量利用ARQ对抗丢包，再利用FEC兜底，这样可以减少带宽的浪费，做到较好的抗丢包效果，图中的式子是FEC需要做兜底的丢包率。三是基于接受端反馈以及模块自检的策略调整，这一模块会统计NACK成功率、NACK响应时长和FEC恢复率。

文章插图

具体做法是：ARQ和FEC并不是割裂的两个模块，它们的统筹由抗丢包综合控制器进行管控，抗丢包综合控制器最核心的地方是FEC兜底的丢包率的计算公式，它的计算来源于网络观测器基于对它的观测，计算出来的网络的指标，去生成公式。而且基于服务器端FEC模块数据统计反馈、服务器端ARQ请求响应模块数据统计反馈和拥塞控制模块数据反馈统筹的告知抗丢包综合控制器。
此外，ARQ模块和FEC模块产生的，流量也会统筹的告知抗丢包综合控制器，最终由抗丢包综合控制器进行公式的参数调整，最终做到在不影响网络质量的场景下做到最大的丢包场景。
3.3.2 传输层下行QoS策略

文章插图

下行QoS服务器策略在复用了上行QoS服务器策略的基础上增加了一些其他的QoS手段，主要有四个模块：一是设计出下行接收端可弹性接收流组合的方案；二是准确的探测出用户真实的下行宽带；三是制定合理的宽带分配方案；四是进行流量的平滑发送以及拥塞控制。

文章插图

这张图展示了四个模块相互作用的关系。用户在上行发布了两天流，要做到下行的最佳体验，实际接收到的流要匹配用户的真实带宽。如果上行发布的都是大流，而用户的带宽不足，无法支撑所有大流的支撑，可能就会将某些大流切成小流。
智能订阅
总体就是首先是发布订阅管理模块，基于多流的发布订阅管理，进行下行的一个可智能选取的方案。其次是带宽分配模块，探测出用户真实的带宽之后告知带宽分配器，再结合用户实际订阅以及上行流的码率等数据后，帮助用户选取最佳的接受组合。最后是总体把控拥塞控制模块，它的工作是进行下行流量的平滑，另外，它基于其他的设计能够避免让网络产生拥塞，最终让下行产生最佳的效果。