云游戏扫盲—2

作者: 传输技术控 | 来源:发表于2021-07-02 17:44 被阅读0次
    (图片出自网络,版权归原作者所有)

            在这里我做一个小广告,如果大家觉得这篇文章对你们有作用的话,请收藏。或者关注我的公众号哈!

            上一篇我们交流了云游戏中采集部分一些内容。这篇我们继续来聊聊云游戏中耗时最多、可变程度最大的实时传输部分。

            云游戏对于网络的要求近乎苛刻,端到端延迟需要控制在120毫秒以内。大于120毫秒用户在玩车枪球类游戏时会有延迟感。而运行1080P云游戏,在高清码率、60FPS的情况下需要22.5mbps的带宽。4K则需要67.5mbps的带宽要求。

            5G的发展为低延迟、大带宽的云游戏的运营创造了条件,也让云游戏成为了5G下运行的典型代表。

            数据传输是云游戏中最核心的内容,它是判定一个云游戏厂商实力高低的最重要标准。

            以下是我制作的一页ppt,在这张ppt中说明了传输模块所采用的技术,以及每种技术的优缺点。

    (原创图片,可进行转载)

    从ppt中可以看出,云游戏主流传输方案有两种——自研和开源!

    首先来看自研方案:

            自研,顾名思义就是传输模块由自己开发。自研时理论基础不是特别麻烦,使用书籍中现成的理论和方法就可以了(有兴趣的可以看《差错控制编码》)。

    (图片出自网络,版权归原作者所有)

    自研传输模块又会分为两种方式——ARQ方式和HARQ方式。

    ARQ:自动重传请求

            HARQ:混合自动重传请求(Hybrid Automatic Repeat reQuest,HARQ),是一种将前向纠错编码(FEC)和自动重传请求(ARQ)相结合而形成的技术。

            这两种方式的区别在于HARQ是具有FEC(向前纠错)能力的,而ARQ则完全使用自动重传来实现数据的可靠性的。

            这里简单做一下扩展。网络中丢包的原因是这样的:数据在网络中传输时,中间的硬件设备(路由器或者交换机等等)的缓存不足。在这种情况下,路由器或者交换机只能将数据丢弃。TCP的协议中,TCP会对被丢弃的数据根据一定策略重新进行发送。在UDP协议中,是没有数据重新发送的功能的。这部分的功能需要自己去开发。

            虽然知道了UDP丢包的原理,但是至于什么时候发生?发生的频繁程度是多少?没有人知道的。HARQ会有一定数量的冗余包和真实数据一起发送。当真实数据丢失后接收端可以根据冗余包来还原出真实数据包,这样就可以避免重传的时间消耗了。但是HARQ的算法要比ARQ复杂很多,同时也需要CPU(需要计算冗余包)消耗和带宽消耗(需要发送冗余包)。

    熊掌和鱼不可兼得

    其次是开源方案:

    开源方案目前业界最流行是WebRtc和Quic两种。

    WebRtc在百度百科上的解释是:

    WebRtc:名称源自网页即时通信(英语:Web Real-Time Communication)的缩写,是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。

            WebRtc的优点是:免费、社区成熟、以及强大的打洞能力。

            WebRtc的缺点则是:缺乏服务器的设计和部署方案,传输质量难以保证,还有就是结构复杂,代码太重。

            WebRtc有很多现成的优秀服务器,例如:Janus、Kurento等等。使用这些服务器搭建一个基于WebRtc的Demo演示环境非常简单。以下这个地址就是我自己使用Janus搭建的一个演示环境,它支持视频会议、桌面分享等基础功能。

    https://61.160.212.59/

            搭建这么一套环境总共就只用了一个上午的时间就搭建好了,大家可以使用Chrome浏览器进入,进入的时候会提示证书的问题,这个时候可以不用理会,点击高级进去就可以了。Janus的效果还是很不错的。

            当然WebRtc也有它不怎么优秀的地方,就拿JetterBuffer的处理方式来说。WebRtc就修改了好几个版本,从丢包算法到-》卡尔曼滤波算法-》斜率滤波算法。

            WebRtc注重的并不是简单的传输能力,他是集采集、传输、展现于一身的庞大集合体。

    另一个开源传输的就是QUIC了。

    QUIC在百度百科上的解释是:

    QUIC:是谷歌制定的一种基于UDP的低时延的互联网传输层协议。在2016年11月国际互联网工程任务组(IETF)召开了第一次QUIC工作组会议,受到了业界的广泛关注。这也意味着QUIC开始了它的标准化过程,成为新一代传输层协议。

    QUIC目前发展也是非常不错,这里就过多的做介绍了。

    知名的开源项目就是这两个了。

    从实现逻辑来看,自研的、开源的传输无非就是解决了两件事情:

    1:数据包在传输过程中丢失后如何解决。

    2:传输的带宽控制逻辑。

            对于第一种情况来说,无非就是采用FEC进行找回,或者采用ARQ直接进行重传,没有别的办法。

    而对于第二种情况就完全不同了,第二种的处理方法有很多种,例如采用WebRTC的卡尔曼滤波算法/斜率算法 以及类似BBR的探索算法等等,无非就是想得到当前的带宽是多少,如何能够更加有效的使用当前的带宽来进行数据发送。

         这里就不在做展开了,这里要是再展开的话,那估计需要在写好多篇才能完成呢。而且带宽控制是整个Harq中最核心的内容,这里面各家做法都完全不同。

            传输完毕后,数据就到了用户的终端了。到了终端的数据需要进行展现,下一篇我来和大家交流一下关于终端(展现)部分的内容。

    相关文章

      网友评论

        本文标题:云游戏扫盲—2

        本文链接:https://www.haomeiwen.com/subject/zkfyultx.html