云游戏扫盲—2

（图片出自网络，版权归原作者所有）

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

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

        云游戏对于网络的要求近乎苛刻，端到端延迟需要控制在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中最核心的内容，这里面各家做法都完全不同。

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